Schwarzgerät

Line 65:

''Aside regarding SMT:'' All the processors we consider support 2-way SMT aka HyperThreading. SMT will generally enhance throughput (i.e., make a core seem like two slightly weaker cores) for code with significant delays due to memory accesses, mispredicted branches, and data dependencies, provided of course that the virtual parallelism can be exploited. Code dominated by arithmetic intensity will not see much benefit from SMT, since the single physical core's execution units are not truly duplicated. If only one thread is available, SMT of course provides no benefit. In any of these cases, enabled SMT can actually degrade performance due to partitioning of microarchitectual resources. Machines primarily running tuned arithmetic code should probably disable SMT. For the case of compilation, it's usually going to be a win, hiding all manner of chaotic delays so long as the physical core's cache doesn't get blown out. We will calculate with physical cores, because fuck it.

''Aside regarding TurboBoost:'' All the processors we consider support TurboBoost 2.0 or 3.0. This allows automatic clock boosts when some cores are inactive. I provide both the base and turbo speed, but calculate using the base speed.

''Aside regarding TurboBoost:'' All the processors we consider support TurboBoost 2.0 or 3.0. This allows automatic clock boosts when some cores are inactive. TurboBoost range tends to shrink as the base clock increases. I provide both the base and turbo speed, but calculate using the base speed, again because fuck it.

{| class="wikitable"

Schwarzgerät: Difference between revisions

Dank (talk | contribs)

@@ Line 65: / Line 65: @@
 ''Aside regarding SMT:'' All the processors we consider support 2-way SMT aka HyperThreading. SMT will generally enhance throughput (i.e., make a core seem like two slightly weaker cores) for code with significant delays due to memory accesses, mispredicted branches, and data dependencies, provided of course that the virtual parallelism can be exploited. Code dominated by arithmetic intensity will not see much benefit from SMT, since the single physical core's execution units are not truly duplicated. If only one thread is available, SMT of course provides no benefit. In any of these cases, enabled SMT can actually degrade performance due to partitioning of microarchitectual resources. Machines primarily running tuned arithmetic code should probably disable SMT. For the case of compilation, it's usually going to be a win, hiding all manner of chaotic delays so long as the physical core's cache doesn't get blown out. We will calculate with physical cores, because fuck it.
-''Aside regarding TurboBoost:'' All the processors we consider support TurboBoost 2.0 or 3.0. This allows automatic clock boosts when some cores are inactive. I provide both the base and turbo speed, but calculate using the base speed.
+''Aside regarding TurboBoost:'' All the processors we consider support TurboBoost 2.0 or 3.0. This allows automatic clock boosts when some cores are inactive. TurboBoost range tends to shrink as the base clock increases. I provide both the base and turbo speed, but calculate using the base speed, again because fuck it.
 {| class="wikitable"