> At the end of the day, the idea that you can rip out all of this fancy OoO-execution hardware and make it the compiler's problem just turns out worse than hav

> At the end of the day, the idea that you can rip out all of this fancy OoO-execution hardware and make it the compiler's problem just turns out worse than having the OoO hardware With Itanium and then NetBurst, it seemed to me that Intel had really bad tunnel vision with the overall designs. It's like they got over focused one a couple use cases and then designed towards those architecturally. As an example I remember the marketing for Itanium and then NetBurst really hammered on tasks like media encoding. The chips could tear through MPEG macroblocks! Wow! Of all workloads what percent are tearing through MPEG encoding or other highly ordered cache-friendly things? Most real world code is cache-hostile super branchy pointer chasing. The philosophy of making the compiler do all the instruction scheduling serves the cache-friendly predictable data stream model. The only way it can serve the real world model of code is to explode memory requirements by having the compiler emit hundreds of variants of routines and use some sort of function multi-versioning to select one appropriate for the current data shape. This is an unscientific observation on my part but it's how the situation seemed to me two decades ago. When Intel didn't have marketeers demanding "moar media encoding" they ended up with genuinely good chips like the Tualatin (which became the Core line).