Depends on how you look at it.
Performance wise it's clearly better, no argument there of course even at lower MHz.
However looking at it from a perf/w perspective, "destroys" is exactly the right word.
It looks like it's routine to get SB close to 5 GHz, Haswell, maybe 4.5 if you are lucky.
This misconception is even more common that I originally thought once the HW threads started popping up. I won't comment on expected OC on HW since it might be early to establish, but its anything but "routine" to get SB anywhere close to 5GHz.
The easiest way to increase IPC across the board would be to increase clockspeed.
The Intel Conroe CPUs were introduced in 2006. By that Intel moved from the old Netburst to the new Core uarch generation. It was a revolutionary change in the design of their CPUs.
Since then we've basically only seen incremental improvements of the Core uarch generation (going from Conroe->...->Haswell).
So now I just wonder when it's likely we'll see a new revolutionary jump in uarch design from Intel like when transitioning from Netburst->Core? How long can they continue just making incremental updates to the now 7 year old Core architecture? Isn't a complete redesign needed at some point to get any further major increases in performance (IPC, CPU clock frequency, etc)?
I've been wondering that too. Once Intel beat AMD in the IPC game, they went back to being Intel and milking an architecture for all it's worth. The only reason we got rid of NetBurst is because AMD trumped Intel in IPC. Intel was planning on using NetBurst for a long, long time.
IPC = instructions per clock, which is unaffected by clockspeed
What? Allright you can rationalize it but calling BS is BS.
Theoretical or practical IPC? Clocking one part of the system, the CPU, higher while leaving the rest of the subsytem intact will of course not yield linear performance scaling and thus fewer instructions PER clock will get chewed up in the processor. But talking about IPC, for talking about IPC in any sense that makes sense, we have to keep all other things equal, thus we are talking about theoretical IPC, which by definition is unaffected by clock.
The Intel Conroe CPUs were introduced in 2006. By that Intel moved from the old Netburst to the new Core uarch generation. It was a revolutionary change in the design of their CPUs.
Since then we've basically only seen incremental improvements of the Core uarch generation (going from Conroe->...->Haswell).
So now I just wonder when it's likely we'll see a new revolutionary jump in uarch design from Intel like when transitioning from Netburst->Core? How long can they continue just making incremental updates to the now 7 year old Core architecture? Isn't a complete redesign needed at some point to get any further major increases in performance (IPC, CPU clock frequency, etc)?
JimmyG is exactly right. There is not a lot of headroom left to increase single threaded CPU performance beyond Haswell barring a major breakthrough (and btw, most architecture research labs have already decided that this problem isn't solvable and have moved onto other problems like power efficiency or parallel architectures).
I meant within the design constraints of a desktop CPU that can be sold at a profit. If you throw cost out the window you could probably do somewhat better, although this isn't always true since bigger structures often have higher latency. You can never throw out power as a constraint in a CPU because increased power increases temperature.
The constraints on HW are imposed mainly by physics.
About the caches, I don't think you need to sacrifice anything if you just add additional levels of cache. For example if you don't think increasing L3 would be beneficial, because the increased latency would more then offset the increase in capacity and it would actually be detrimental to performance, just add L4 cache etc.Yeah, I more or less agree that it is possible to increase perf if you are willing to arbitrarily increase cost. We probably will see small 3-5% improvements over time. There may even be a few ideas that can deliver more than this. This is what I meant when I said that there isn't a lot of headroom.
Although I don't strongly agree with your individual examples. Bigger caches have diminishing returns and you typically have to sacrifice something other than just area for more capacity (latency, associativity, NUMA effects, etc). There is often a sweet spot rather than more perf with more capacity.
ASICS are like "heroic compiler optimizations", they only work for a few apps and are not general purpose. So I don't think it is really fair to say they can speed up ST code. They can, but only in very limited circumstances, and it doesn't happen automatically behind the scenes. The app developer needs to be aware of it.
IPC = instructions per clock, which is unaffected by clockspeed
About the caches, I don't think you need to sacrifice anything if you just add additional levels of cache. For example if you don't think increasing L3 would be beneficial, because the increased latency would more then offset the increase in capacity and it would actually be detrimental to performance, just add L4 cache etc.
Even if we increased ST performance by 5% each year, we would have doubled ST performance in 14 years. That's the very least that's going to happen.