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: 2) by engblom on Thursday April 23 2020, @01:33PM (12 children)
The first generation of Ryzen Zen was really terrible. When running Linux they crashed more or less daily, making them totally worthless. This was fixed in Zen+ and newer.
(Score: 2) by bzipitidoo on Thursday April 23 2020, @02:06PM (7 children)
I never had any luck with the AMD K6 and other AMD CPUs of that era. Just not stable. Seemed the chips themselves were okay, but I kept running into motherboards that would run a Pentium fine, but not an AMD K5. They were supposed to work with either, but they wouldn't work long with an AMD chip before hanging, while being rock steady with an Intel CPU.
(Score: 5, Interesting) by RS3 on Thursday April 23 2020, @03:26PM (2 children)
I also had some stability problems with them, but I blamed Windoze. Turned out to be MB capacitors! Changed them when they finally started oozing and the cap plague became widely known. Rock-solid after that.
Interestingly, that MB ran Linux fine, which is why I blamed Windows. (dual-boot machine of course). What was Windows doing that caused instability? I can't imagine MS would mess with RAM or other MB timings. Does anyone have any ideas on that?
(Score: 1, Insightful) by Anonymous Coward on Thursday April 23 2020, @09:00PM (1 child)
Usage patterns, man. With bad caps, doing work under load and under low load can give different outcomes. So maybe peripherals were brought up in a different order, or maybe bootup stressed the bridges differently, or maybe some init or usage pattern was actually identical to both but had a stochastic failure chance, at which point "error handling in software"
(Score: 2) by RS3 on Saturday April 25 2020, @01:42AM
Yeah, maybe. But running Linux I ran X-windows, KDE, kstars, played videos including YouTube. Never a glitch.
But Windows would freeze, reboot, blue-screen...
Again, after new caps, Windows never flinched. No sw changes either. Just caps. I have to believe Windows messes with hardware stuff.
Maybe Linux was loading a better CPU microcode?
(Score: 3, Interesting) by Anonymous Coward on Thursday April 23 2020, @04:28PM (3 children)
I had a k6-2 and it was rock stable
It could not overclock it as the pentium and maybe it is why several people had problems trying to push it too hard, specially with weaker MB
whatever CPU, most problems at that time were bad power supply/MB (ie: stable power problems) and bad windows drivers (very common).
(Score: 2) by turgid on Thursday April 23 2020, @04:44PM
I had two K6-2s and a K6-III and they were all rock solid. I did have trouble with one but that was bad RAM, not the CPU.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by Booga1 on Thursday April 23 2020, @05:03PM
I also had a K6-2 and had no issues whatsoever. I did spring for a decent motherboard since I needed extra ports for Firewire and such.
(Score: 2) by TheRaven on Friday April 24 2020, @03:22PM
I had a K6-2 and it crashed a lot. It turned out, there was a hairline crack on the motherboard. When I replaced the mother board it was very stable.
These chips also didn't do any thermal throttling and a lot of them had poorly fitted heat sinks (especially bad thermal paste), which caused them to overheat.
sudo mod me up
(Score: 1) by zion-fueled on Thursday April 23 2020, @02:36PM (1 child)
Was it? Because mine is running great. Then again I got it this year, long after linux support matured. Vega must be terrible too because I read about it's linux trouble recently.
(Score: 0) by Anonymous Coward on Thursday April 23 2020, @07:53PM
Did you read recently Gilead Sciences (your home company and pride) has had its coronavirus drug failed in the first trial?
(Score: 2) by Freeman on Thursday April 23 2020, @02:53PM
Ryzen Zen and/or my motherboard MSI B350 Tomahawk was buggy as all get out when I first got it. I picked up a Ryzen 7 1700 right at release date and I had all kinds of trouble with blue screens of death and other issues in general. After a few BIOS updates, everything settled down and it's been solid for years.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 1, Interesting) by Anonymous Coward on Friday April 24 2020, @06:41PM
A masking error on the machine learning instruction scheduler. It was functionally flawed.
The solution for motherboards that supported it was to disable that part, which netted a 10-20 percent performance loss, but many motherboards didn't include the option, or send your cpu back to AMD who would exchange it for one of the fixed models from after the mask error was detected. No Zen+'s had that error, but neither did any later revision Zen cores. Only the original first or second masking runs had the flaw, which initially only showed up on gcc 8.3 which was how it was discovered. Apparently windows and the microsoft compiler had a different optimizing pattern that didn't trigger it at the time, as did the earlier gcc releases.