Clock for clock this is the slowest CPU I tested. At 100 MHz with 8k WB cache it is slower than Intel with 16k WT cache. At full 120 MHz it is only a little faster than Intel CPUs at 100 MHz. But even at full 120 MHz it consumes less power than Intel CPUs, thanks to 500nm core (Intel has 600nm) and of course half cache means less transistors to produce heat. AMD also has 500nm core with 16K cache but it is supposed to be rare. More likely AMD DX4 CPU with 16k cache is actually 350nm 5x86 core and that might be a bad thing because it has a problem when disabling L1 cache.
This makes no sense, sounds like your board is adding a wait state for 40MHz FSB.
Yes a Cyrix 5x86 is a good match for a PCI board. That is one reason I settled on it.
I don't think that the AMD cores are inferior to Intel's cores. Unless I miss my guess other than WB/WT and microcode (N or no N) the cores are very nearly identical.
I don't think that the AMD cores are inferior to Intel's cores. Unless I miss my guess other than WB/WT and microcode (N or no N) the cores are very nearly identical.
This is true, hence why I think some shennanigans are going on with the benchmarks. The differences should be negligable.
I mean the cores are at probably same levels of performance but the AMD chip has only half the L1 of Intel. Performance parity is only reached with 16kb AMD chips. More cache = more better
I mean the cores are at probably same levels of performance but the AMD chip has only half the L1 of Intel. Performance parity is only reached with 16kb AMD chips. More cache = more better
It REALLY does not make that much of a difference.
You will see that while synthetic benchmarks like Speedsys, 3DBench appear to clearly favor i486, the performance in real world applications like Doom and Quake are a wash - 8 vs 16KB difference is actually marginal, whereas WB does make a difference.
Moral of this story: Take Speedsys results with a grain of salt.
Personally, I stick to NSSI scores for comparison as they are VERY good gauges of real world ALU and FPU performance in my experience.
I mean the cores are at probably same levels of performance but the AMD chip has only half the L1 of Intel. Performance parity is only reached with 16kb AMD chips. More cache = more better
It REALLY does not make that much of a difference.
You will see that while synthetic benchmarks like Speedsys, 3DBench appear to clearly favor i486, the performance in real world applications like Doom and Quake are a wash - 8 vs 16KB difference is actually marginal, whereas WB does make a difference.
Moral of this story: Take Speedsys results with a grain of salt.
Personally, I stick to NSSI scores for comparison as they are VERY good gauges of real world ALU and FPU performance in my experience.
Well, yeah, Speedsys probably does something that fills up the cache. The bigger cache doesn't make a difference ... until it does. Just run a set of instructions that doesn't fit in to that 8kb or something that benefits from reading and writing in a single cycle and you'll probably start seeing the difference. All 486 benchmarks should always be taken with a grain of salt and synthetics will always be different from "real world" bencmarks.
I mean the cores are at probably same levels of performance but the AMD chip has only half the L1 of Intel. Performance parity is only reached with 16kb AMD chips. More cache = more better
It REALLY does not make that much of a difference.
You will see that while synthetic benchmarks like Speedsys, 3DBench appear to clearly favor i486, the performance in real world applications like Doom and Quake are a wash - 8 vs 16KB difference is actually marginal, whereas WB does make a difference.
Moral of this story: Take Speedsys results with a grain of salt.
Personally, I stick to NSSI scores for comparison as they are VERY good gauges of real world ALU and FPU performance in my experience.
Well, yeah, Speedsys probably does something that fills up the cache. The bigger cache doesn't make a difference ... until it does. Just run a set of instructions that doesn't fit in to that 8kb or something that benefits from reading and writing in a single cycle and you'll probably start seeing the difference. All 486 benchmarks should always be taken with a grain of salt and synthetics will always be different from "real world" bencmarks.
Good luck finding a set of genuine real world instructions that max out a 486's 8KB cache and don't run like shit regardless. Let it be noted that even the original Pentium had 16KB cache, and that was actually split for code and associative write back so even THAT CPU did not conform to a 16KB instruction cache capability. Some features are just overkill marketing bullet points.
I wouldn't look at the Speedsys results too closely. I included it mostly to show CPUID end perhaps how overclocking effect. It is a synthetic benchmark so it likely fits in 16k L1 cache but does not fit in 8K cache. That explains why 8K Am486 performs so poorly and why I didn't do more synthetic benchmarks expect Topbench (I stored Topbench results to a database file but it requires some cleaning). But that CPU is not very good in ANY of the benchmarks and almost needs the extra 20 MHz to keep up with Intel.
It is possible, for example that I forgot it in WT mode when doing 120 MHz bencmarking (I don't remember what order I tested) or messed with some BIOS settings. I can run a few benchmarks again to see if they match. I don't think that is the problem here. It can be seen that Am5x86 is slower than Intel at the same clock and the Am486 does have less cache so it must be even slower.
What I don't understand is why Intel performs so much better on PC Player benchmarks than AMD or Cyrix.
It is possible, for example that I forgot it in WT mode when doing 120 MHz bencmarking (I don't remember what order I tested) or messed with some BIOS settings. I can run a few benchmarks again to see if they match. I don't think that is the problem here. It can be seen that Am5x86 is slower than Intel at the same clock and the Am486 does have less cache so it must be even slower.
The first assertion is outright wrong the Am5x86 core is essentially the exact same Am486 core on a smaller node. The second one is true but the magnitude of difference should have been miniscule.
So I thought I'd fire off some quick tests as well because the topic piqued my interest and I have a 486 here right now that I can easily bench.
I have here a Zida 4DPS 2.11 with jumpers set to 5x86-133, tightest timings possible (all maxed except memory RAS at 3 and memory speed FASTER) and 2 CPUs:
Other Specs
Generic S3 Trio64 2mb PCI
64mb FPM
256k L2 Cache (set to write through)
Between CPU swaps, nothing was changed except FSB jumper (one jumper from 33mhz to 40mhz) and multiplier jumper (off for 1/3 or on 2/4). Settings otherwise remained exactly same.
To get the Intel DX4-120 results for Doom and Quake, I had to overvolt to 5v. Quake had to load at 100mhz and then be overclocked to 120mhz immediately before the run starts as it wasn't stable enough to load the game (but was stable enough to run it).
The 4DPS works fine with on the fly overclocking via jumper switching. I verified that this did not chance results from boot vs during runtime (ie. no sneaky checks for 40mhz to add wait states while booting)
What pains me is that I also have AmDX4-120SV8B but that's one of those bunk later rebranded 5x86 chips (25544) which have 16kb of cache instead 8kb. I really wanted to see whether that makes a difference, but alas.
Anyways, the difference is small but they seemed to be quite consistent. Apart from Speedsys, I ran all tests twice and got same results always within 0.1fps. I rounded down (ie. chose the lower number if different)
Here AMD wins Doom, loses Quake and 3DBench. Make of these numbers what you will.
Those figures look a whole lot more reasonable to me.
Yeah that is more in line with the other comparisons that I have seen.
CPU galaxy is a good one, also it's been some time ago but Phil also did some testing and he was seeing very little difference in most testing as well.
There are plenty of other examples as well.
So no or very little changes. And BIOS and jumper settings are correct. I didn't have sound card installed this time but it should not matter since the tests do not have sound enabled.
I think I'm going to try older BIOS version just in case the last beta from 97 does have some issues with non-Intel CPUs.
appiah4wrote on 2022-06-21, 10:30:The first assertion is outright wrong the Am5x86 core is essentially the exact same Am486 core on a smaller node. The second on […] Show full quote
It is possible, for example that I forgot it in WT mode when doing 120 MHz bencmarking (I don't remember what order I tested) or messed with some BIOS settings. I can run a few benchmarks again to see if they match. I don't think that is the problem here. It can be seen that Am5x86 is slower than Intel at the same clock and the Am486 does have less cache so it must be even slower.
The first assertion is outright wrong the Am5x86 core is essentially the exact same Am486 core on a smaller node. The second one is true but the magnitude of difference should have been miniscule.
This is AFAIC the holy grail of 486 benchmarks. And feipoa's findings show that there is about 1% ALU+FPU difference between Intel WB and AMD WB CPUs.
Even in pure ALU the AMD part is only 8% slower - and that is due mostly to, yes you guessed it, stupid synthetic benchmarks.
And even then the AMD-120 part is SIGNIFICANTLY faster than Intel-100.
So yeah, something is not right with your test setup. Quite possibly your board runs AMD CPUs with some hidden wait states or something.
Sorry to complain, but I don't understand that figure.
There are AMD DX4 WB, AMD DX4 WT and Intel DX4.
So is the Intel a L1 WT or a L1 WB? I am sure that DOES make a difference.
Or did I miss something?
EDIT: Also according to this figure, the intel 486DX4 is minimum 10% faster than the AMD at same clock. Or when you compare AMD DX4-100 WT with Intel DX4-100 (WB or WT unknown) a lot more.
Haha
CoffeeOnewrote on 2022-06-21, 18:34:Sorry to complain, but I don't understand that figure.
There are AMD DX4 WB, AMD DX4 WT and Intel DX4.
So is the Intel a L1 WT […] Show full quote
appiah4wrote on 2022-06-21, 10:30:The first assertion is outright wrong the Am5x86 core is essentially the exact same Am486 core on a smaller node. The second on […] Show full quote
It is possible, for example that I forgot it in WT mode when doing 120 MHz bencmarking (I don't remember what order I tested) or messed with some BIOS settings. I can run a few benchmarks again to see if they match. I don't think that is the problem here. It can be seen that Am5x86 is slower than Intel at the same clock and the Am486 does have less cache so it must be even slower.
The first assertion is outright wrong the Am5x86 core is essentially the exact same Am486 core on a smaller node. The second one is true but the magnitude of difference should have been miniscule.
This is AFAIC the holy grail of 486 benchmarks. And feipoa's findings show that there is about 1% ALU+FPU difference between Intel WB and AMD WB CPUs.
Even in pure ALU the AMD part is only 8% slower - and that is due mostly to, yes you guessed it, stupid synthetic benchmarks.
And even then the AMD-120 part is SIGNIFICANTLY faster than Intel-100.
So yeah, something is not right with your test setup. Quite possibly your board runs AMD CPUs with some hidden wait states or something.
Sorry to complain, but I don't understand that figure.
There are AMD DX4 WB, AMD DX4 WT and Intel DX4.
So is the Intel a L1 WT or a L1 WB? I am sure that DOES make a difference.
Or did I miss something?
EDIT: Also according to this figure, the intel 486DX4 is minimum 10% faster than the AMD at same clock. Or when you compare AMD DX4-100 WT with Intel DX4-100 (WB or WT unknown) a lot more.
Haha
If you read the thread feipoa points out that the i486DX4 is a WB and the only one he had - he laments not having a WT model.
The noted 8% (not 10%) difference between AMD and Intel's WB models is for ONLY ALU tests and those tests are biased towards Intel due to synthetic benchmarks that unrealistically use 8+ KB L1 cache - you will find that real world applications and FPU tests have no such performance discrepancy and the overall ALU+FPU performance difference between the CPUs is rightly <1%.
I tested BIOS versions 0402 and 0401 (I was using the last 0402.1 beta) with 8k AMD but no difference. I also tested Intel DX4 WB @ 100 MHz with BIOS 0401 but with same results as with latest BIOS. BIOS version does not affect speed.
I made my first retrobright attempt. This was just a test to see I don't do anything wrong. Two 3.5" bezels (ivory and grey) and bezel from Mitsumi 4x CD-ROM-drive. Here is how the Mitsumi looks like:
The attachment Mitsumi4x.jpg is no longer available
As can be seen, I did one mistake. I forgot the part from the sled. At least it is now obvious that retrobrite did work. I'm going to retrobrite the original case from this system and take it back to use.
I took a look at old pictures and verified that the original CD-ROM-drive for this system was 4x Panasonic IDE-drive. I should have kept that one. Since I'm now using CF-adapter on front of the case (and a network card once I put this back together), I no longer need those newer DVD-RW-drives to transfer files. So back to good old period correct QUIET CD-ROM-drives. I couldn't find a Panasonic but I did find that 4x Mitsumi I tested retrobright on.
But it was not a good drive. It does not support 80-min CD-R discs at all (it does not detect them). It detects 74-min discs but they must be very high quality discs for it to read them. I also had problems with original discs but recapping helped for that. So basically that Mitsumi doesn't really support CD-R-discs. Even older 2x-speed Panasonic (I like those) does support them nicely. It doesn't support multisession discs (it only sees the first session) but that is not a problem for me. But the 2x-panasonic uses Panasonic interface and that would make sound card stuff harder (I have two or maybe three Panasonic controller cards but there are no free ISA slots).
But no worry. I did find another Mitsumi. It is a 8x drive and supports CD-R discs and is quiet. It is from 96 so a little too new but it will do. I hope I'm going to find one of those 4x Panasonic drives again. No point to change this 8x Mitsumi to anything else.
But since the test bench is up again, I did couple of new tests. This time with GUS Extreme (ES1688f), SB16 CT2940 with CQM and other CT2940 with YMF289B (OPL3 but smaller chip). I tested how speed sensitive they were.
CQM was perfect. Cycles worked with full speed (with Intel DX4-100 WB) and so did Indy 3 and it didn't even need the "a" command line parameter so auto-detection worked perfectly.
ESFM worked perfectly with Cycles. No problems with full speed. But Indy required "a" parameter even with internal cache disabled. Most likely some compatibility issue with detection routines and not because of speed sensitivity.
YMF289B was just as bad as YMF262. It is just as speed sensitive.
YMF289B was just as bad as YMF262. It is just as speed sensitive.
Out of curiosity, which game are you testing with?
My OPTi card (which uses a 1:1 YMF289B copy) has no speed issues on a Pentium MMX 166, but I haven't tested anything older than the first Monkey Island on it, and that sounded fine to me. Somewhat newer games like Doom, Duke3D and Tyrian work flawlessly of course.
EDIT - I just realized that Cycles is a game. For some reason, I kept thinking of CPU cycles. 😁 Is the intro music playing at the correct speed in this video? If so, I can use that for comparison purposes.
There are two different kinds of speed issued with YMF and Cycles. If CPU is little too fast you get distorted audio (it is instantly obvious) and if CPU is way too fast the game won't start. You just get abnormal program termination error message.
