add arrow-down arrow-left arrow-right arrow-up authorcheckmark clipboard combo comment delete discord dots drag-handle dropdown-arrow errorfacebook history inbox instagram issuelink lock markup-bbcode markup-html markup-pcpp markup-cyclingbuilder markup-plain-text markup-reddit menu pin radio-button save search settings share star-empty star-full star-half switch successtag twitch twitter user warningwattage weight youtube

What is SMT useful for

TheSingingCarrots

1 month ago

Gaming, workloads, etc?

Comments

  • 1 month ago
  • 2 points

Any workload able to saturate the input scheduling to a core but that doesn't fully utilize that core, when that happens the extra scheduling allows more of the cores resources to be used.

The issue is it doesn't actually allow anything more then what the total cores resources can be used for so actual performance scaling can vary.

Ryzen is an interesting example of this as its SMT implementation reserves a small portion of the core for each thread which limits per thread performance when enabled, and can limit performance faster when the CPU isn't actively using both threads.

So you can see a performance uplift from disabling SMT in some workloads.

Cores are always better then SMT in real world use because even with the same thread count you have an entire cores resources per thread instead of sharing a single cores resources between threads.

  • 1 month ago
  • 1 point

So, what you're saying is:

Workloads that can't fully utilize a single core (but still gives the core full input) will benefit, without actually increase total performance.

Ryzen(s) sometimes perform worse when SMT-enabled.

And what does the last one mean?

  • 1 month ago
  • 1 point

Workloads that can't fully utilize a single core (but still gives the core full input) will benefit, without actually increase total performance.

Correct because more can be scheduled to use the leftover resources.

And what does the last one mean?

Having two cores is better then having two threads on a single core.

  • 1 month ago
  • 1 point

OK. Understood.

  • 1 month ago
  • 1 point

To be fair, there are some workloads that benefit from disabling SMT on Intel CPU's as well. I've seen this with some database workloads. It's a tricky effect to pin down, since it depends on the OS scheduler almost as much as it depends on the core usage patterns of the workload.

Cores are always better then SMT in real world use...

Absolutely.

  • 1 month ago
  • 1 point

To be fair, there are some workloads that benefit from disabling SMT on Intel CPU's as well.

Yup the difference is more noticeable on Ryzen because of how it reserves core resources for each thread in case load increases on an unused thread and easier to see performance gains.

  • 1 month ago
  • 2 points

Think of a CPU core as a kitchen full of cooks. Each cook represents a separate instruction pipeline within the core.

Think of the scheduler as a kitchen manager, converting the incoming orders into a series of instructions for each chef to perform to get all the proper dishes made as fast as possible. The kitchen manager can only assign tasks 1 at a time, often having to wait for a cook to finish a task before ordering the next task. This results in a chef task saturation rate of ~70%.

Think of SMT as having 2 kitchen managers in the kitchen instead of one. If things go well, the additional oversight can keep more of the chefs saturated with work and maximizing their cooking throughput. If things go badly, the 2 kitchen managers wind up making it worse. Whether there is an improvement or drawback depends on the workload...

Modern X86 cores are designed with very wide out-of-order instruction pipelines. They are very wide in an effort to achieve the highest possible execution throughput to a single thread, but as a consequence of this design, will have under-utilization when only working on a single thread at a time. For software that can make use of more threads than there are cores in a CPU, SMT enables the scheduling of work from 2 separate threads on back-end execution resources in a core at the same time, thus, taking advantage of otherwise idle execution resources.


Any workload that can scale to more threads than there are CPU cores available, can typically scale up performance with SMT enabled.

The threshold for this, varies depending on what sort of CPU we're starting with vs what sort of workload.

For gaming, SMT is HEAVILY utilized on dual core CPU's. Most games completely saturate at least 1-2 threads and have plenty more work on a few additional threads to be performed. On the other hand, if we have a 6 core CPU, enabling SMT makes basically no difference, since the workload already has access to all the parallelism it can take advantage of with the 6 threads of the CPU.

Some software is "stupid" and will attempt to spawn as many threads as are available in the CPU, despite there being threshold where scaling to more threads is actually detrimental to performance for various reasons (takes more compute work to split and rejoin the output than the uplift provided by more cores or SMT). In these cases, we're often better off with CPU's without SMT, or disabling it.

Some software scales incredibly well with SMT. Almost any non-real-time workload that can be broken up into unique buckets of work, with a centralized low-overhead management system, works great with SMT and lots of cores. Rendering is a great example.

  • 1 month ago
  • 1 point

it helps with scheduling processes in multithreaded tasks. For example: rendering, games that scale with threads, multitasking

Sort

add arrow-down arrow-left arrow-right arrow-up authorcheckmark clipboard combo comment delete discord dots drag-handle dropdown-arrow errorfacebook history inbox instagram issuelink lock markup-bbcode markup-html markup-pcpp markup-cyclingbuilder markup-plain-text markup-reddit menu pin radio-button save search settings share star-empty star-full star-half switch successtag twitch twitter user warningwattage weight youtube