3 ms·

It seems to me that the speed increase in your example comes from having twice the cache and therefore half the misses. You can do that without adding cores. (B

by wtracy 8y ago

It seems to me that the speed increase in your example comes from having twice the cache and therefore half the misses. You can do that without adding cores. (Barring edge cases where two threads use different pages that happen to share the same cache line.) As for reducing the need for speculative execution: You're just replacing implicit parallelism with explicit parallelism. Whether or not that is a win depends on the workload and the competency of your developers. :-)

MaulingMonkey 8y ago
> It seems to me that the speed increase in your example comes from having twice the cache and therefore half the misses. My math assumed a share L3 cache of the same size, no "twice the cache", no "half the misses". Same number of misses, but each miss is effectively half as costly, because it's only stalling half your processing power (one of your two 1 Ghz cores) for X number of nanoseconds instead of all of it (your single 2 Ghz core). > As for reducing the need for speculative execution: You're just replacing implicit parallelism with explicit parallelism. Yes and no. If you're already explicitly parallel (more and more common), you're just eliminating a redundant implicit mechanism that's based on frequently wrong branch prediction heuristics. One can optimize for those, but then one can argue just how "implicit" it really is... > Whether or not that is a win depends on the workload and the competency of your developers. :-) Of course. But there's a lot of embarrassingly parallel work out there, and improving building blocks, that don't take a geniuses to operate. Pixel shaders, farming video frames out to render farms, compiling separate C++ TUs... these are all things already made explicitly parallel on my behalf. Really maxing out the performance of a single modern ~4 GHz core is no simple feat either.
- wtracy 8y ago
  >Same number of misses, but each miss is effectively half as costly Wow, I'm still trying to wrap my head around that. I was going to argue that in cases where there's no way to split an algorithm across multiple threads without extremely frequent IPC, pipelining can probably get better performance than multiple cores, but then I realized that I have absolutely nothing to base that claim on. I still wouldn't opt for more cores rather than higher clock speed without first trying to benchmark my expected workloads, but you have given me some very interesting things to think about.

by wtracy 8y ago

MaulingMonkey 8y ago

> It seems to me that the speed increase in your example comes from having twice the cache and therefore half the misses. My math assumed a share L3 cache of the same size, no "twice the cache", no "half the misses". Same number of misses, but each miss is effectively half as costly, because it's only stalling half your processing power (one of your two 1 Ghz cores) for X number of nanoseconds instead of all of it (your single 2 Ghz core). > As for reducing the need for speculative execution: You're just replacing implicit parallelism with explicit parallelism. Yes and no. If you're already explicitly parallel (more and more common), you're just eliminating a redundant implicit mechanism that's based on frequently wrong branch prediction heuristics. One can optimize for those, but then one can argue just how "implicit" it really is... > Whether or not that is a win depends on the workload and the competency of your developers. :-) Of course. But there's a lot of embarrassingly parallel work out there, and improving building blocks, that don't take a geniuses to operate. Pixel shaders, farming video frames out to render farms, compiling separate C++ TUs... these are all things already made explicitly parallel on my behalf. Really maxing out the performance of a single modern ~4 GHz core is no simple feat either.

wtracy 8y ago
>Same number of misses, but each miss is effectively half as costly Wow, I'm still trying to wrap my head around that. I was going to argue that in cases where there's no way to split an algorithm across multiple threads without extremely frequent IPC, pipelining can probably get better performance than multiple cores, but then I realized that I have absolutely nothing to base that claim on. I still wouldn't opt for more cores rather than higher clock speed without first trying to benchmark my expected workloads, but you have given me some very interesting things to think about.