Hacker News new | past | comments | ask | show | jobs | submit login

It's a bit ironic that one of the reasons for Itanium's failure was that the compilers were not ready. I have no doubt that nowadays GCC and clang would immediately have good support for any new processor (especially from a big player like Intel). In any case the processor vendor would make sure themselves that there would be good compiler support (see Apple).

(Setting aside the question if good compiler support would have been possible with Itanium's architecture, or if the optimizations they thought of could not be implemented in principle. I don't know enough about it to tell for sure.)




gcc had already existed for 14 years by the time Itanium came out, and it had been widely ported to many different systems... that was kind of the whole point of the project. The real issue I feel is locked up in your parenthetical: it is difficult to put aside the question of whether good compilers for Itanium were even possible, as part of the entire problem was that the VLIW architecture concept was so incredibly different than CISC/RISC that it made porting the compiler very difficult (and while you could, can, and did somewhat easily do naive compilation that simply ignored the potential benefits, the resulting performance sucked). I was in college at the time and I remember VLIW being cited as a reason why compilers had a lot of hot research that needed to be done ASAP.


AFAIK Intel and HP spent well north of $1B on VLIW compiler research, with crickets to show for it all.

The people prophesying the second coming of VLIW (for general purpose code) seriously need to explain the compiler breakthroughs that have been done to make the whole affair worthwhile.


Yes -- and explain how code statically scheduled for the worst-case dependences at compile time can ever beat out-of-order and speculative execution that can see the actual dependences at runtime. For anything other than extremely regular codes, there's an information gap that can't be overcome.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: