This doesn't seem to be the best-researched article out there. If they thought Itanium was bad, they should have looked into the i860. Itanium was an attempt to fix a bunch of the i860 ideas. i860 quickly went from a supercomputer chip to a cheap DSP alternative (where it had at least the hope of hitting more than 10% of its theoretical performance). Intel iAPX 432 was preached as the second coming back in the 80s, b…
At least the 960 was somewhat usable. Many variants were created, and several were widely used in embedded products for quite a few years. The 860, however, was Just Crap. Full stop. End of story. IIRC it had weird double-instruction modes that compilers just couldn't handle, and if you used them anyway (for very necessary performance) then handling exceptions properly was all but impossible. Definitely gets my vote…
I worked on an unreleased third-party C compiler for the i860. It wasn't that compilers couldn't handle the double-issue float mode, it was more that it was worthless in real-world code due to the entry/exit latency. It had high performance on paper but not in reality, which was exactly the lesson that Intel did not learn for the Itanium.
I'm so ashamed to have owned a Cyrix, a P4, and an AMD Bulldozer. They were all awful.
Nothing to be ashamed of on the cyrix and AMD, both were better price/perf than what you would have bought with the same money from intel. The same can't be said of the P4, which was right in the middle of AMD giving intel a good solid whumping.
My vote for worst CPU goes to the iAPX 432 (also not on this list).
Wow, a garbage collector implemented inside of the processor. Chip level support for objects. You can't fault Intel for their ambition here, just their common sense. And the whole thing is built for a world where everybody is writing code in Ada. I bet some compiler makers were salivating at the prospect of collecting all of those huge license fees from developers.
It was a different time - memory/CPU speed trade-offs were very different - we saw RISC once we were able to move cache on-chip (or very very close) - but at that point CISC made sense and the 432 pushed CISC to the extreme.
IMHO the x86 won out (an d is still with us) because of all the CISCs of its time it was the closest to RISC when memory started to get a lot faster (almost all instructions make at most 1 memory access, few esoteric memory operations etc)
For a bit of time, I ran an over clocked FX 8320 and crossfire 7970's. The heat that machine put out was tremendous. I only had a wall mounted AC unit so I had to practically take my shirt off when I loaded it up.
Agreed. I think Itanium gets a lot of unnecessary slack. It really tried some exciting new ideas and clean concepts. Not all of those concepts were much of a win, but with the first chip arriving years late then there’s no wonder it was perceived as underwhelming from the get go (that would happen to any chip that’s late)
Funnily, I feel like SIMD instructions are slowly reinventing what the itanium did out of the box. I think a modern compiler could likely do a good job with itanium now-a-days. However, when it first came out, there simply wasn't the ability to keep those instruction batches full. Compiler tech was too far behind to work well with the hardware.
I'm not sure I'd say many compilers are even that great with SIMD these days and that is easier than what the itanium was asking of compilers.
There are real gains to be had by using SIMD but it tends to be massively parallel data processing workloads with specially written SIMD code or even hand tuned assembly (image/video processing, neural networks) not just feeding in a source file and compiling with the SIMD flag to then realize meaningful gains.
My vote for worst CPU goes to the iAPX 432 (also not on this list).
Wow, a garbage collector implemented inside of the processor. Chip level support for objects. You can't fault Intel for their ambition here, just their common sense. And the whole thing is built for a world where everybody is writing code in Ada. I bet some compiler makers were salivating at the prospect of collecting all of those huge license fees from developers.
I once encountered a note from one of the people working on iAPX 432, claiming that the core idea of high level cpu wasn't really the issue it tanked, but project mismanagement and horrible design applied which resulted in a chip that would be technologically at home... In 1960s, just done in VLSI - one of the things I recall were issues with actual physical implementation of the memory data paths resulting in horrible IPC
This doesn't seem to be the best-researched article out there. If they thought Itanium was bad, they should have looked into the i860. Itanium was an attempt to fix a bunch of the i860 ideas. i860 quickly went from a supercomputer chip to a cheap DSP alternative (where it had at least the hope of hitting more than 10% of its theoretical performance). Intel iAPX 432 was preached as the second coming back in the 80s, b…
the Cell processor in the PS3 was not terrible in the PS3 and I doubt you ever worked on it. So talk about 'not the best-researched'. You can find many people singing it's praises, including me.
It probably was spectacular once you knew how to work with it. Like the Atari Jaguar though, getting the performance needed out of such a highly parallel architecture took a lot of time and investment. With cross-platform games really taking off during that time, it was a strategic mistake IMO.