SoylentNews is people
SoylentNews
Today, we've decided to revisit some of the worst CPUs ever built. To make it on to this list, a CPU needed to be fundamentally broken, as opposed to simply being poorly positioned or slower than expected. The annals of history are already stuffed with mediocre products that didn't quite meet expectations but weren't truly bad.
Note: Plenty of people will bring up the Pentium FDIV bug here, but the reason we didn't include it is simple: Despite being an enormous marketing failure for Intel and a huge expense, the actual bug was tiny. It impacted no one who wasn't already doing scientific computing and the scale and scope of the problem in technical terms was never estimated to be much of anything. The incident is recalled today more for the disastrous way Intel handled it than for any overarching problem in the Pentium micro-architecture.
We also include a few dishonourable mentions. These chips may not be the worst of the worst, but they ran into serious problems or failed to address key market segments. With that, here's our list of the worst CPUs ever made.
- Intel Itanium
- Intel Pentium 4 (Prescott)
- AMD Bulldozer
- Cyrix 6×86
- Cyrix MediaGX
- Texas Instruments TMS9900
Which CPUs make up your list of Worst CPUs Ever Made?
(Score: 5, Interesting) by KilroySmith on Thursday April 23 2020, @04:46PM (3 children)
The concept of the Itanium was great; still is. I never used one, so I don't know about the quality of the hardware implementation.
The Itanium's downfall is the piss-poor state of software engineering. They couldn't write a compiler that demonstrated the Itanium working faster than a contemporary x86, so potential customers couldn't be bothered with the new architecture.
In a modern x86, a significant amount of die space is devoted to solving parallelism and superscalar problems. The intention of the Itanium was to solve those problems at compile time, freeing up silicon area for other functions - perhaps more cores, or more cache, or more features (AVX-512, anyone?). It seems like a simple problem - after all, the hardware designers do a reasonable job of it in current x86 architectures - but for "reasons" software was never able to deliver the same level of parallelism.
(Score: 2) by isj on Thursday April 23 2020, @05:03PM
I've used Itaniums at my work. They performed fine for our workloads.
Yes, modern x86 CPUs use a lot of die space untangling the mess of register re-use and OoO execution. The "belt" architecture from Mill Computing tries to avoid that - it is an interesting architecture. I hope they succeed so we have more fun architectures to play with instead of micro-improvements of x86.
(Score: 4, Insightful) by sjames on Thursday April 23 2020, @08:02PM
Part of that was Intel not wanting to share enough information for anyone but Intel to make a decent compiler. I say only part because Intel wasn't able to make their compiler produce fast code for Itanic either.
Adding insult to injury, Itanic was eye-wateringly expensive (about $10,000 each IIRC) but didn't have the performance to back it up.
I wouldn't blame it all on the software guys, unlike the hardware, the compiler didn't have the advantage of seeing what branches have already been taken by the actual code with the actual data. To get that information, the compiler would need an emulator and a representative input dataset.
(Score: 2) by epitaxial on Friday April 24 2020, @02:05AM
I always wanted an Itanium box but they are still expensive on eBay. The cheapest would be the HP rx2660 or similar. Run the latest version of OpenVMS!