Super Pi always takes longer under Windows 98 SE than under Windows 2000 and Windows XP!!

I find this strange, because Super Pi is from 1995!



Super Pi 1 MB benchmark results:

Windows XP Pro SP2: 47 s

Windows 2000 Pro SP4: 47 s

Windows 98 SE: 53 s

What CPU are you using? AMD right?

Your CPU needs a microcode update. Either get a new BIOS with new m/c update or use manual updater utility.

Win2k and XP already have a later microcode update in the form of Driver.

It's probably not related to the BIOS, because it's a new motherboard. I have an Asus A7N8X-X motherboard.
The BIOS revisions later than I have only have smaller updates. Probably don't require a BIOS flash unless it's a Sempron. I have a regular Athlon XP. It's a Barton core, thus there shall not be any problems with this motherboard!!

A later BIOS date isn't gonna fix anything unless it's something that prevents the motherboard from POSTing.

See here for similar problem: http://www.msfn.org/board/index.php?showtopic=51386

First 3DMark scores, now this? (How did those 40.72 drivers work out for you anyways?) Highly suspect.

Is that you Link21?

meh, i can live with that.

But if you use Intel CPU, you don't notice any difference, because the microcode is already updated by the BIOS and Windows doesn't update it.

Update:

This just popped up in my head, Windows 98 SE likely isn't taking advantage of more than 256 KB of L2 cache!!

I have a "Barton" core, which has 512 KB of L2 cache. I wonder if you can get Windows 98 SE to use more than 256 KB of L2 cache?

surely 98 SE must use the full L2 cache already ?

otherwise what would have been the point of the 512KB-1MB-2MB external L2 cache super socket 7 boards produced during it's prime ?

i have 2 (almost totally identical in terms of chipset) super socket 7 boards and the 1MB L2 cache one performs way better than it's 512KB sibling.

L1,L2,L3 caches are managed by the hardware. The software need not intervene.

Regarding size of cache, I have a circa. 1993 80486dx2-66 with 512KB of L2, and that was around before 98se...

But, this may be because of another problem. It's possible that Windows 98 SE assumes that it only has 256 KB of L2 cache, because most Athlon processors have 256 KB of L2 cache. (before "Barton") The Windows 98 SE processor driver may be getting confused. It may not like the fact that the L2 cache is integrated. Most processors at the time Windows 98 SE was released didn't have integrated L2 cache!

There is no such thing as a "processor driver" - what seems to be a driver for the processor is only a microcode updater... see \windows\system32\drivers\update.sys which on my system claims to have the following microcode updates:



Also see http://www.msfn.org/board/?showtopic=44388

The microcode updates supplied with original 98se only updates Intel processors and does not support AMD.

I knew that already. But, I'm wondering if it's not updating the microcode because of it not recognizing the L2 cache type? Even if it has microcode information for Athlon processors (at least the pre-T-bird Athlons) Athlon processors before the T-bird don't have integrated L2 cache!!

Also, which driver versions should I use for nForce2?

Wow! No reply! I been noticing that people have a tendency to ignore my posts. I'm requiring some help here, because I'm lost at what to do about this. I wonder if this issue only affects a couple of benchmarks?

Windows 98 SE should be faster, because of less bloat. I wonder if most games arn't affected?

I remember from back in 2002, when running Nintendo 64 emulation, it felt faster than under Windows XP!

It does still seem true that the following applies: Later Windows version=requires more processor power just for itself.

Switch to Intel

But the thing is, I thought that later Windows versions, especially Windows XP were even more pro-Intel! I heard that it's best to use an earlier Windows version for AMD systems!

Don't forget that in the days of Win98, AMD was not as popular as it is today, and thus the majority of code was optimised for Intel CPUs such as the Pentium II.

Operating systems do not "select" how much cache to
use - they either use all or nothing of it, and disabling
the cache would only be useful for troubleshooting.

The fact that Win98 is so much more compact than XP/2K
should affect performance positively as far as the cache
is concerned, because a larger portion of the system will
fit into it.

There other CPU-related features that affect performance,
of course, such as the Memory-Type Range Registers that
Pentium Pro and newer Intel CPUs support, and that can
be used to select caching strategies for portions of the
address space, as appropriate. I assume AMD processors
have something similar.

For example, enabling maximum read/write caching for the
video memory can greatly enhance performance, because
it allows the CPU schedule accesses to it in whatever order
it finds optimal.

However, using the same caching strategy for self-modifying
code (e.g. JIT compilation) or for data segment that need to
be accessed in the order assumed by the compiler or
programmer, would crash either the application in question,
or whole the system.

The default settings programmed by the BIOS at startup,
or the CPU's power-on defaults, are likely to be selected
with stability and compatibility in mind, and of course, the
settings will remain that way until reprogrammed - and
that's where device-, chipset- or CPU-specific drivers
come in.

For example, the DOS kernel basically regards any CPU as
an 8086, and it requires drivers like HIMEM, QEMM or
386MAX to take advantage of more advanced functionality.

Windows 95 is written to run on a 386 (I've tested).
I think Windows 98 demands a 486 at minimum. However,
the setup program installs more specific drivers where
available.

For example, the VMM32.VXD-archive on my Celeron 400
system includes a module called MTRR.VXD. I imagine that
the absence of such processor-specific support could
adversely affect performance to significant degrees.

For more speed, but a 386 is all that's needed... I've tried a 33MHz 80386DX and 98se does indeed run on it.

I'm wondering if most games aren't affected?

Anything running on the CPU will be affected by the microcode updates...

Likely not if the application wasn't compiled with a pro-Intel compiler. Super Pi was unfortunately compiled with a pro-Intel compiler, AFAIK.

Super Pi, at least the non-modded one was written in 1995! Back then, AMD wasn't popular at all!

In 1995, I didn't even have a PC at all!

I have gotten wording about the following:

Intel made it's complier so that it's slower on purpose if a non-Intel processor is detected. Even if the processor supports the functions required.

Makes sense. It is the Intel compiler after all... so it'd be optimised only for their processors.

All this talk about a possible performance gap? Gap that might manifest itself under certain uncommon conditions (very uncommon conditions) such as running certain stress-test/bechmarking software dating from mid 90s on a particular OS. (I say might because who knows what configuration of hardware/software dear RJARRRPCGP is running, and that is if RJARRRPCGP is not BS'ing us to begin with)