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: 3, Informative) by Anonymous Coward on Thursday April 23 2020, @01:15PM (10 children)
That processor was great. A lot cheaper than Intel's processors and very fast integer performance. Sure the FPU was garbage and therefore performed poorly in Quake, but used in the appropriate application (eg. business desktops) it was excellent. I'd put the Pentium Pro above it on the list.
(Score: 2) by RS3 on Thursday April 23 2020, @03:21PM (3 children)
I liked that they were very low power. But the Intel P3 was pretty low power too. Besides what you mentioned, they didn't generally work in socket 370 motherboards- you had to have an MB that accepted them. But otherwise I had no problems with them.
(Score: 3, Interesting) by shortscreen on Thursday April 23 2020, @06:00PM (2 children)
6x86 was a socket 5/7 processor, not 370. The only real problem with it was that even after multiple die shrinks the clock speed didn't increase much. They managed to get from the original 150MHz up to 300MHz and that was it. AMD and Intel hit 600MHz and beyond and left Cyrix in the dust. The Joshua core that Cyrix had been working on at the time of the VIA buyout was also looking like a big, expensive die with lackluster frequencies.
(Score: 2) by RS3 on Friday April 24 2020, @12:53AM (1 child)
Thanks for the correction and info. Sorry, I guess I mixed the Cyrix memories into 1. I was remembering the most recent Cyrix III / Via C3s that were socket 370 and I had a couple of them, and remember buying special socket 370 MBs to run them. Ran very well, quite cool. Probably didn't need a fan.
I still have at least 1 C3 1 GHz cpu. Other one must be in an MB somewhere in a box...
I just dug into my CPU history museum box and found a 6x68MX, an mII, and 2 labeled IBM, because, iirc, IBM was one of their fabs.
(Score: 1, Interesting) by Anonymous Coward on Friday April 24 2020, @06:24PM
And the actual Cyrix stuff got sold to someone else, because the AMRISC/RDC 3286 (There were a couple different names for it depending on the mode) was a Cyrix 486SLC-133 which may or may not have been related to the 6x86 cores, which I will note were Speculative execution 2+ years before Intel put out the Pentium Pro. In fact the biggest issue with the 6x86 was because they were microcoded speculative execution chips. A sequence of 2-3 instructions could actually put the chip in an infinite loop because it would mask interrupts. this sequence was possible in userspace which could cause an infinite loop if a workaround wasn't implemented. Apparently a page fault was enough so using a 2 page interrupt table was a method of mitigation.
The bigger issue with the 6x86 was the lack of a timestamp counter and a few other items needed for full pentium compatibility, and the fact that the FPU in it was weaker than the Pentium FPU because they had focused the transistor budget on integer processing because at the time it seemed like general purpose cpus focused on integer use was where it was at. Unfortunately Pentium and Doom proved them wrong, followed shortly thereafter by the Pentium MMX leading to the merger of the PPro and the P55C's MMX extensions into the Celeron/P2/Xeon lines. And the rest as they say is history.
(Score: 3, Insightful) by Revek on Thursday April 23 2020, @11:01PM (2 children)
They were trash but not because they were bad processors. The main reason why is they blue screened in windows often since windows didn't have any optimization for the processor. It was already a intel world as far as microsoft was concerned.
This page was generated by a Swarm of Roaming Elephants
(Score: 3, Interesting) by Anonymous Coward on Friday April 24 2020, @07:41AM (1 child)
IIRC, it was worse than that. Around that time if Windows detected a Cyrix chip it would turn off the cache to slow the machine to a crawl and then randomly throw fake blue-screens. That was one of the many charges brought against Microsoft during the big antitrust suit against them. They pulled a similar stunt with the Windows 3x series if it was run on DR-DOS.
(Score: 2) by RS3 on Saturday April 25 2020, @01:37AM
"fake blue-screens" - I actually laughed out loud.
They did that with Novell client software. And cleverly the MS Novell-detecting-blue-screening code was encrypted. It's amazing the criminal activity that some people get away with.
Question: how can you tell a fake one from a real one?
As my dad would have said, I think it's a dubious distinction.
(Score: 2) by toddestan on Thursday April 23 2020, @11:56PM
I had one of those. It was rated a 200+, so supposedly equivalent if not faster than the (somewhat rare) Pentium 200. It actually ran at 150 MHz. For general desktop type stuff, it was fine. It was also okay with the internet as it was back in this CPU's day. However, the FPU was terrible. It could barely play a MP3 file. Well, you could play a MP3, but forget about doing much else with the PC while it was doing it. I also used a K6 233 quite a bit, and the K6 utterly destroyed the 6x86. The K6 could play a MP3 and pretty much still be idling. Ditto for games.
It also wasn't very stable, though for the time it wasn't bad considering I was running Windows 95 and most of the crashes weren't likely the hardware's fault. But nevertheless a big part of the problem was that it was a 150 MHz chip, but unlike the Intel chips which got that with a 60 MHz bus and a 2.5x multiplier, the 6x86 got it with a 75 MHz bus and a 2x multiplier. While this undoubtedly helped it with it's 200+ rating, this hurt its stability quite a bit. I had a Socket 7 motherboard with an Intel VX chipset, which was only rated for 66 MHz (the fastest bus speed Intel ever supported on Socket 7) which meant the chipset was over clocked. The PCI bus ran at half the bus speed, or 37.5 MHz, whereas most any PCI card was expecting 33 MHz max, so all the PCI cards were being overclocked. And the EDO memory was almost certainly being run at a higher speed than it was supposed to. The 6x86 166+ ran at 133 Mhz (66 MHz and 2x, same as the Pentium 133), so I would guess that chip might be more stable.
The 6x86 might fair better in the later Super Socket 7 motherboards which supported up to a 100 MHz bus speed and were backwards compatible with some Socket 7 processors, though those came out after the original 6x86.
Despite its problems, I still don't know if I would call it bad. It was cheap, and it worked well enough for the time.
(Score: 3, Interesting) by epitaxial on Friday April 24 2020, @01:58AM
The FPU wasn't even that bad in the benchmarks. https://liam-on-linux.livejournal.com/49259.html [livejournal.com]
Quake used very cleverly optimised x86 code that interleaved FPU and integer instructions, as John Carmack had worked out that apart from instruction loading, which used the same registers, FPU and integer operations used different parts of the Pentium core and could effectively be overlapped. This nearly doubled the speed of FPU-intensive parts of the game's code.
(Score: 2) by TheRaven on Friday April 24 2020, @03:13PM
sudo mod me up