|
|
|
|
|
by p_l
1491 days ago
|
|
The critical difference is that EPIC (the architecture model of Itanium) essentially exposed CPU pipelines naked to the code - so you didn't just have to reorder instructions as optimizers do today, you also had to figure out changes that experience so far suggests is doable either in hw with runtime-only data, or in very tight numerical code. This includes compiler taking the place of branch predictor as well as OOOE scheduling, as well as no on-cpu instruction reordering or out of order retirement, and IIRC a branch mispredict was quite costly. More over, EPIC pretty much meant thar you couldn't apply similar chip-level IPC improvements as you could elsewhere, at least originally. |
|
That, though, seems like it might make for a good power/performance tradeoff. Those circuits aren't free. We just didn't get to the point where compilers were doing a good job of that OOOE reordering (not until after EPIC died).
The real reason, though, that itanium died (IMO) is most businesses insisted on emulating their x86 code at a 70% performance cost. So costly that it seems like intel/hp spent most of their hardware engineering budget making that portion fast enough.