I'm seeing several anecdotal accounts of slow/poor performing and unreliable systems blaming the CPU, especially on the Cyrix comments (and many similar examples on some older bad/worst CPU discussions).
This isn't really a valid or fair metric for "bad" CPU since many of those systems were cheaply/poorly/inefficently built (or configured) pre-built systems that weren't limited primarily by the CPU but by a clutted OS install, crappy (or simply mismatched) motherboard, slow hard drive, too little RAM, etc.
In the specific case of some late gen cyrix chips (like the MII 333 and 366), I know eMachines commonly used them along with POS PCChips motherboards and the typical bloated installs of those machines. Though, to be fair, on a decent SS7 board, those Cyrix parts were still a bit overrated at 333 and 366, even for the business/office apps they were markted towards (Cyrix had declined heavily under National Semiconductor and become a bit despirate at that point). The 333 was really closer to a 300 and 366 a 333 or 350 for business apps (compared to PII/Celeron and K6 parts) and certainly much further behind in gaming performance. (the 262/75 MHz 333 variant was more comparable to a Pentium MMX 233 for gaming, or a bit worse -kind of the polar opposite to the cachless celerons which were poor for buiness but a good value for gaming -great if overclocked)
The same kinds of things would apply to crappy L2 cacheless 486 machines using otherwise good CPUs . . . or L2 cachless 486SLC machines posed as 486SX/DX class systems. (which in reality were little better than cacheless 386SX systems of the same clock speed -or worse if other hardware was weaker- . . . perhaps better for some 3D games of the time where the cache and faster computational performance would make a difference)
AFIK, the only L2 cacheless 386SX bus/board based part with anything near 486 class performance was IBM's clock doubled 66/33 MHz 486SLC with 16 kB on-chip cache (to the Cyrix's 1 kB).
OTOH, the 386DX counterpart to the Cyrix SLC, the 486DLC had realistic 486 class performance. (obviously no FPU, but prior to Quake that was a total non-issue for 99% of users -ie aside from CAD and 3D workstation stuff) IBM's 486DLC pushed things a good bit further though (16k cache and clock doubled and trippled), there's the rare clock-doubled Cyrix 486 DRX-2, but that was still limited to a 1k cache and was so late it didn't much matter.
DDR and RDRAM didn't really benefit Tualatin much. i820, i820E, and i840 all supported RDRAM and didn't show any real performance gains. There were also a few DDR chipsets produced by VIA, I believe. Same effect there.
None of those changed the FSB architecture of the platform . . . it was still tied to the SDR 66/100/133 (or a bit more if overclocked) FSB of the S370 platform.
RDRAM was actually worse than PC133 SDR in most cases due to the high latency on top of zero gain in peak throughput (same FSB bottleneck). DDR on S370 would be rather pointless for the same reason.
Had the Athlon/Duron been released on a Socket 7 or Socket 370 style SDR bus platform, they'd have been crippled too.
Looking at the 7 stage pipeline PPC 7450/G4e I'm going to say moar layers wouldn't have been enough. Wikipedia says overclockers got 800 MHz at best on the K6-3+.
Yes, the existing 180 nm 2+ and III+ were only officialy rated up to ~570 MHz (more commonly 450 for the III+, and 500 or 550 for the 2+) and tended to overclock consistently to ~600 MHz or a bit beyond, with more extreme cases nearing 800 MHz. Note, it wouldn't be possible to go beyond 600 MHz using the default 100 MHz FSB as 6x multiplier is the maximum, so higher speed overclock the FSB, which can lead to other problems with the chipset and/or overclocked PCI/AGP bus. (800 MHz would need 133 FSB, which very few boards supported, all of which overclocked 100 MHz rated chipsets, 120/124 MHz support was much more common but still not always stable for those chipsets, 112/115 MHz was usually fine though)
Wikipedia also says "For a time, the K6-III was a low priority part for AMD—something to be made only when all orders for high-priced Athlons and cheap-to-produce K6-2s had been filled—and it became difficult to obtain in significant quantities." A Celeron like K6 might have been made if that darn Athlon wasn't so succesful.
Yes, hence why I said much less extreme than the P3/P4 situation of the same time.
That Wiki quote pertains to the original K6-III (250 nm) which was competing with Athlon and K6-2 production (and K6-III dies took 118 mm2 to 81 mm K6-2 and 184 mm Athlon). It lacked the gaming prowess or marketing hype of the K7, so it was both lesser known and lower-priority for AMD, but was a very good choice for general users and as a SS7 upgrade part (significantly faster in most apps than a K6-2 of the same clock speed) and also happened to score quite well in server benchmarks of the time.
The K6-III was on the scene durring the big CPU shortage of '99/2000, so the priority for K6-2 and K7 production was even heavier still. By the time the 180 nm K6 2+/III+ parts were out, the shortage was over and the smaller dies also meant much better cost effectiveness. However, retail/dealer availability was limited for those (officially notebook) parts, though they were available wholesale in most cases. (so dealers in the know usually had access to them)
Here's an interesting article from the perspective of general desktop office/business multitasking on the K6-III and III+.
http://redhill.net.au/c/c-e.html (apparently a very good performer for multitasking at 560/112 MHz on a FIC-503+ with 1 MB board level cache)
Had AMD pushed K6 development more, it really would have only catered to the notebook (beyond what the SS7 based K6+ parts already did) and the entry level office desktop niche (especially for less FPU-intensive applications) . . . probably much more popular with home builders and small dealers than OEMs. (as the K6-2+/III+ ended up historically) The Duron obiously catered better to the mainstream gaming/multimedia performance side of things.
The tiny die of the K6 based parts would have allowed for a considerable increase in the L2 cache beyond 256k while remaining as small or smaller than the Duron, though even then it would have been limited to the notebook/entry level buiness/office niche and perhaps low power servers. (more so if it could have been tweaked to higher clock speeds)
Facebook
Twitter