Geri
Experienced Member
- Joined
- Apr 24, 2019
- Messages
- 163
Which one? The Cyrix 5x86, 6x86MX, VIA C7 were prety neat CPU-s in they time.
| VCF Midwest | Sep 12 - 13, 2026, | Schaumburg Convention Center, IL |
| VCF Montreal V2.0 | Nov 07 - 08, 2026, | Saint-Lambert, Montreal, Canada |
| VCF SoCal | Feb TBD, 2027, | Southern CA |
| VCF East | Apr TBD, 2027, | InfoAge, Wall, NJ |
| VCF Latam | TBD, 2027, | Bahía Blanca, Argentina |
| VCF Pac. NW | TBD , 2027, | Tukwila, WA |
| VCF Southwest | TBD, 2027, | Westin Dallas Fort Worth Airport |
| VCF Southeast | Aug TBD, 2027, | Atlanta, GA |
| VCF West | Aug TBD, 2027, | Mountain View, CA |
-
Please review our updated Terms and Rules here
Worst x86 CPUs over the years
- Thread starter jasa1063
- Start date
Eudimorphodon
Veteran Member
Oh, I'm not expecting it to be great, I'm mostly just curious if driving the board meaningfully from DOS works at all.
(It looks like I *may* have the correct board for the DOS Soundblaster compatibility/emulation wedge to work. If I don't I may have an old Ensoniq PCI card that has a DOS driver, but the next question is going to be how VGA register compatible the onboard video is, etc.)
vwestlife
Veteran Member
Are we forgetting the 486SX-16? No co-processor, and slower than any good 386. Only made for a few OEMs who wanted to sell low-cost Intel 486 systems (including Dell).
lowen
Veteran Member
I think the 486SX-16 was mentioned up-thread. I think I have one here somewhere, but it escapes me at the moment as to where. I do have a 486SX-20, a bit more common. In theory, the 486SX-16 was supposed to equal a 386DX-33 in overall speed.
Was it fixed later on? One of my compatibility tests is OS/2. The Transmeta CPUs run OS/2 just fine. I have some of the HP/Compaq Transmeta-based thin clients. The code morphing software uses 32MB out of the 512MB, so no problem really. I haven't run into any software that won't run on those...
compaqportableplus
Veteran Member
I would agree that the early Pentium 4s weren’t the greatest. I have one and Windows XP runs like shit on it. It’s pretty decent for anything Windows 2000 and below though. I love the newer P4s though.
And the P4m like what was used in the Dell Inspiron 8200 is a fantastic CPU. Doesn’t get very hot and handles Windows XP just fine.
The 486SX-16 has always intrigued the hell out of me. Would love to tinker with one of those.
And the P4m like what was used in the Dell Inspiron 8200 is a fantastic CPU. Doesn’t get very hot and handles Windows XP just fine.
The 486SX-16 has always intrigued the hell out of me. Would love to tinker with one of those.
I had a HP Vectra with a 486 SX2/50 in it. Haven't seen another one of those since.
Some decompression algorithms performed extremely poorly on the Transmetas. I had to service one at my old job..... took FOREVER to install software at the "unpacking" stages.
GiGaBiTe
Veteran Member
I have seen one SX/2-66 in my lifetime and nothing since.
OS/2 isn't really a valid compatibility test, it had long since been dead by the time Transmeta had CPUs out in the mid 2000s.
http://www.vanshardware.com/reviews/2004/04/040405_efficeon/040405_efficeon.htm
Most specifically:
These were common complaints about Transmeta processors, not being able to run Photoshop, media applications or games without crashing or at minimum, performance issues. I remember talking with a few owners of Transmeta laptops years ago and they confirmed the issues, the only reason they bought them is because they were cheap. Even the final TM8600 core from Transmeta only had MMX, which was basically a non-starter. AMD was already on SSE3 in 2003, followed by Intel in 2004 and applications were at least targeting SSE and SSE2 by then.
Transmeta made a series of fatal design decisions by that point which had basically doomed them to failure. They could have fixed the instruction set deficiencies in their code morphing software, but the architecture had so many glaring design flaws that it just wasn't salvageable. Like they had no AGP implementation ever and just one PCI bus, which even the south bridge had to sit on. So there was all of this bandwidth contention on the PCI bus for graphics, and everything else. Memory was another thing, the Transmeta designs had two memory controllers, one DDR and one SDR. According to them, the DDR controller was supposed to just be for the code morphing software cache and SDR was supposed to be for general purpose use, but it was never implemented that way. SDR was EOL in the mid 2000s and it would have been even more performance degradation to use it.
Geri
Experienced Member
- Joined
- Apr 24, 2019
- Messages
- 163
I would like to nominate Vortex86DX to this competition.
The 800 MHz Vortex86 DX2 was released in 2009. Its performance is however WORSE than the performance of a Cyrix 6x86MX at 250 MHz.
The Vortex86DX2 eats less than 1 watts, and it is a 11 year old cpu, so of course, nowdays it is hard to put it into perspective.
HOWEVER, it was released 16 years after the Pentium1, it has 256 kbyte L2 cache, DDR2 memory controller, and the processors clock speed is 800 mhz.
Yet, its unable to beat the Pentium1 or the Cyrix 6x86MX (these dont even have l2 cache whatsoever).
When bench testing the FPU of the Vortex86DX, it's only giving 33 megaflops, either the fpu works on a separate 33 mhz clock, or either the fpu is fully implemented from microcode, without any support at hardware level.
In theory, the ALU has two pipelines, its in-order superscalar design, however the pentium1 and cyrix 6x86mx is also in-order superscalar, so probably they have messed up something very very badly in the vortex86dx.
The Vortex86 family is based off on rise mp6, but the performance of the Vortex86DX is very far from the mp6 clock-to-clock.
When running my game engine, the Cyrix 6x86MX performs 5.9 fps, and the Vortex86DX performs at 5.9 fps. (Again, the Cyrix 6x86MX runs at 250 MHz, and the Vortex86DX runs at 800 mhz).
Its not just my game engine which is slow (which also uses floating point in its vertex processor). Even loading the linux kernel itself is quite of slow, decompressing the linux kernel is about two times slower than on the Cyrix machine.
Its very hard to find any test where the Vortex86DX outperforms the Cyrix6x86MX.
By the way, the Vortex86MX is a totally nice CPU, they have fixed this performance issue (thats about 2x-3x faster on the same clock speeds than the Vortex86DX).
The 800 MHz Vortex86 DX2 was released in 2009. Its performance is however WORSE than the performance of a Cyrix 6x86MX at 250 MHz.
The Vortex86DX2 eats less than 1 watts, and it is a 11 year old cpu, so of course, nowdays it is hard to put it into perspective.
HOWEVER, it was released 16 years after the Pentium1, it has 256 kbyte L2 cache, DDR2 memory controller, and the processors clock speed is 800 mhz.
Yet, its unable to beat the Pentium1 or the Cyrix 6x86MX (these dont even have l2 cache whatsoever).
When bench testing the FPU of the Vortex86DX, it's only giving 33 megaflops, either the fpu works on a separate 33 mhz clock, or either the fpu is fully implemented from microcode, without any support at hardware level.
In theory, the ALU has two pipelines, its in-order superscalar design, however the pentium1 and cyrix 6x86mx is also in-order superscalar, so probably they have messed up something very very badly in the vortex86dx.
The Vortex86 family is based off on rise mp6, but the performance of the Vortex86DX is very far from the mp6 clock-to-clock.
When running my game engine, the Cyrix 6x86MX performs 5.9 fps, and the Vortex86DX performs at 5.9 fps. (Again, the Cyrix 6x86MX runs at 250 MHz, and the Vortex86DX runs at 800 mhz).
Its not just my game engine which is slow (which also uses floating point in its vertex processor). Even loading the linux kernel itself is quite of slow, decompressing the linux kernel is about two times slower than on the Cyrix machine.
Its very hard to find any test where the Vortex86DX outperforms the Cyrix6x86MX.
By the way, the Vortex86MX is a totally nice CPU, they have fixed this performance issue (thats about 2x-3x faster on the same clock speeds than the Vortex86DX).
I just looked in my spare CPU junk box and found a SX 25, SX 33, and an SX/2 50 CPUs along with an IDT Winchip 200 something or other plus the more common CPUs.
The only time I ever seen those SX chips was at a recycler I used to raid that stripped budget OEM machines along with more common machines so I snagged a few for my collection.
This also goes to show how stupid I was back then. The owner would let me go through the CPU box and snag what I wanted and paid probably 2x scrap rates which he figured out by weighing the chips and averaging a rate out (pre gold rush I might add) so it was probably a buck or two a cpu. I basically grabbed a few 486 CPUs I never owned or didn't currently have, some 486 evergreen upgrades, and misc oddball stuff like the above SX chips and socket 5 stuff. At the time the owners sidekick was stealing the PPros and reselling them to another scrapper on the sly but everything else was fair game for me. I should have snagged more then I did.
The only time I ever seen those SX chips was at a recycler I used to raid that stripped budget OEM machines along with more common machines so I snagged a few for my collection.
This also goes to show how stupid I was back then. The owner would let me go through the CPU box and snag what I wanted and paid probably 2x scrap rates which he figured out by weighing the chips and averaging a rate out (pre gold rush I might add) so it was probably a buck or two a cpu. I basically grabbed a few 486 CPUs I never owned or didn't currently have, some 486 evergreen upgrades, and misc oddball stuff like the above SX chips and socket 5 stuff. At the time the owners sidekick was stealing the PPros and reselling them to another scrapper on the sly but everything else was fair game for me. I should have snagged more then I did.
vwestlife
Veteran Member
I have an embedded thin client PC with a Vortex86DX running at 1 GHz. And yes, except for its low power consumption, it's pretty useless.
Geri
Experienced Member
- Joined
- Apr 24, 2019
- Messages
- 163
vwestlife: you are lucky for having the 1ghz model
mine is cardboard form factor, its look like the rpi, manufactured from icop
it only has the 800 mhz model, and 256 mbyte ram (it would be far more usable with 512mbyte ram)
and this was made far after the vortex86 mx was shipped...
its a mistery why someone still tought the dx version will be okay to be used
By the video, you mention:
,,uncompressed linux - they must have compressed it to fit it on the disk module''
no thats normal on every system, they decompressing the kernel at boot.
mine is cardboard form factor, its look like the rpi, manufactured from icop
it only has the 800 mhz model, and 256 mbyte ram (it would be far more usable with 512mbyte ram)
and this was made far after the vortex86 mx was shipped...
its a mistery why someone still tought the dx version will be okay to be used
By the video, you mention:
,,uncompressed linux - they must have compressed it to fit it on the disk module''
no thats normal on every system, they decompressing the kernel at boot.
Last edited:
Andy Mitchell
New Member
My pick is the original 8088/8086. Sure my 10Mhz Turbo XT clone gave me access to a huge range of great games and productivity software, it got the job done. Essays written, games played, all great. I still have that motherboard and the case it lived in.
But was it a good CPU design? No.
The designers left a lot of architectural baggage behind. Design choices that were probably unwise at the time became ever more troublesome as future x86 chips were developed. For a very long time just about every firm who ever designed a non DOS system could go get a faster chip for the same money.
Here are a couple of things
Segment:Offset addressing
Lets have a 20 bit address range but only 16 bit registers. When you access memory its using a segment register shifted 4 places to the left plus another register. Your code gets littered with all kinds of whacky non standard pointer types like "near", "far" and "huge". Extra overhead accessing a far pointer, and even more for a huge one.
Eagle eyed readers will also have spotted that there are many ways to form any address, e.g. C001:0000 == C000:0010. To have "normal" pointers in the way other systems do it has to be huge pointer. That means more overhead normalising pointers so you can compare them and more overhead on pointer arithmetic to deal with running out of range on the offset. You can tell the compiler to make all pointers huge by default to spare your sanity, your performance will suffer. You may wish you were on a 68000.
This pain didn't go away until we got the 386 and DOS/4GW extender and other ways to write 32bit code. Programming then got a lot more pleasant, so long as you were prepared to dump support for older chips.
Instruction Format
I once got a long way into writing an x86 emulator to run on ARM CPUs, I studied the instruction coding with its prefix bytes and varied instruction formats and lengths. The only easy way to parse instructions is to feed the memory one byte at a time into a state machine. I questioned my design choices, did some research, and found out that is exactly how the early CPUs worked. If you have ever looked at how the original 32bit ARM instruction set is encoded you can see how easy it is for the hardware to decode it quickly, read a 32 bit instruction shove it into the decoder, decode it in one go. Easy and fast.
But was it a good CPU design? No.
The designers left a lot of architectural baggage behind. Design choices that were probably unwise at the time became ever more troublesome as future x86 chips were developed. For a very long time just about every firm who ever designed a non DOS system could go get a faster chip for the same money.
Here are a couple of things
Segment:Offset addressing
Lets have a 20 bit address range but only 16 bit registers. When you access memory its using a segment register shifted 4 places to the left plus another register. Your code gets littered with all kinds of whacky non standard pointer types like "near", "far" and "huge". Extra overhead accessing a far pointer, and even more for a huge one.
Eagle eyed readers will also have spotted that there are many ways to form any address, e.g. C001:0000 == C000:0010. To have "normal" pointers in the way other systems do it has to be huge pointer. That means more overhead normalising pointers so you can compare them and more overhead on pointer arithmetic to deal with running out of range on the offset. You can tell the compiler to make all pointers huge by default to spare your sanity, your performance will suffer. You may wish you were on a 68000.
This pain didn't go away until we got the 386 and DOS/4GW extender and other ways to write 32bit code. Programming then got a lot more pleasant, so long as you were prepared to dump support for older chips.
Instruction Format
I once got a long way into writing an x86 emulator to run on ARM CPUs, I studied the instruction coding with its prefix bytes and varied instruction formats and lengths. The only easy way to parse instructions is to feed the memory one byte at a time into a state machine. I questioned my design choices, did some research, and found out that is exactly how the early CPUs worked. If you have ever looked at how the original 32bit ARM instruction set is encoded you can see how easy it is for the hardware to decode it quickly, read a 32 bit instruction shove it into the decoder, decode it in one go. Easy and fast.
Geri
Experienced Member
- Joined
- Apr 24, 2019
- Messages
- 163
Is the Vortex86 related to the SiS550 somehow? I haven't run any benchmarks on mine
Rise MP6 --> SiS550 --> Vortex86SX --> Vortex86DX --> Vortex86MX
Chuck(G)
Gone, but never forgotten.
I've voiced my distaste for the original 8086 implementation before. One thing that hit me in the first couple of days back in 1980 when I first was confronted with the responsibility of programming the thing was the wacky addressing--and the lack of instructions to accommodate it. My first example:
Given two long/far addresses, compute the distance between them, even if said distance is more than 65KB. On a system with linear addressing, it's easy--just subtract the two addresses. Now try that with two segmented address that can be in any form and see how many instructions it takes.
The point is that addresses and data must be considered as a whole. If you're going to have 20-bit addresses, you should have 20 bit registers.
Given two long/far addresses, compute the distance between them, even if said distance is more than 65KB. On a system with linear addressing, it's easy--just subtract the two addresses. Now try that with two segmented address that can be in any form and see how many instructions it takes.
The point is that addresses and data must be considered as a whole. If you're going to have 20-bit addresses, you should have 20 bit registers.
Eudimorphodon
Veteran Member
Segmentation did make sense from a certain 1970's point of view, especially if you kind of think of the 8086 as slotting in somewhere between an 8080 on steroids on the low end and a drunken take on the address-extended version of the PDP-11 architecture on the high side. But it was definitely not a forward-looking decision to assume 64k was going to be enough (easy to handle) per-process memory for anyone for more than a few years.
krebizfan
Veteran Member
128 kB processes if you please. 64k code and 64k data just like the PDP-11. Yes, the programmer had to do more work but the system builder didn't need a MMU. Take 8080 code that is squeezed for room, double the memory available to it with little effort, move the OS into its own pair of segments with plenty of room for buffers. Improve performance for a few years until the chip of the future became ready to handle the influx of affordable memory.