Hardware pr0n...w00t!

**clocker** · 07-15-2005, 06:07 PM

You certainly make valid points...clearly, all this benchmarking is just for bragging rights, not for day-to-day usability.

**clocker** · 07-18-2005, 04:02 AM

And speaking of bragging....

If I can break past 41 I'll hit the top three in the competition.

Anyone know what winRAR is most dependent on?

**lynx** · 07-18-2005, 06:40 AM

Have you read the help file?

Apparently it doesn't start showing meaningful data until at least 10MB of data has been processed. In theory that means that the amount of data processed in 60 seconds is not actually significant, it is the resulting speed which is important. Having said that, multiplying your resulting speed by 60 does actually give 40MB (allowing for rounding).

Apparently the program generates random data, then compresses it and decompresses it simultaneously. As far as I can tell there is no actual disk access involved. By way of confirmation of that, a virus scan running at the same time hardly seemed to affect the performance.

There seem to be three processes involved:
Generation of random data.
Compression of that data.
Decompression of the compressed data.

There is also comparison of the original and resulting data streams, but I don't think that would have much bearing on the result.

Obviously, since data is constantly passing from the processor to memory, the memory management system must be highly involved.

I can see little advantage (and many disadvantages) in the software using floating point arithmetic for the compression and decompression but I suppose that depends on whether the software designers were smart enough to realise that. I would guess they were.

All other filters and algorithms are disabled, so the only other factor is pure processor power.

All in all I would say that the benchmark tests a mixture of memory access speed and processor performance. The one thing I can't tell from your images is the speed the memory is running at, so I suppose it is 260MHz.

Just found out that revision E chips (Venice, San Diego and x2) have hidden memory speed settings as long as the bios supports it, namely 433, 466 and 500. That'll upset all those people who think AMD are stuck at DDR400. Of course if, as is likely, those speeds are achieved by a multiplier of the base frequency then 500 would become 650 with your 260MHz base. Bet you wish you'd held out for the Venice core now.

**clocker** · 07-18-2005, 10:53 AM

The last couple of Oskar Wu beta BIOS releases have had the memory dividers in place as you describe.
I had never seen a "plus side" divider before (i.e., over 1:1 favoring the RAM) and naturally, HAD to see what happened.

Well, long story short, you gotta have an E-revision chip to make that work.
It wasn't pretty.
Women ran screaming and strong men lay twitching on the floor.
Sprocket was bleeding from her IDE ports.

I've reflashed to the June official BIOS release and may even go further back.
The last several betas have all addressed issues involving the x2s and the e's in general...much of which might actually be detrimental to Winnie performance.

Two firsts in a row.
Although I've booted at 2.8GHz before it was never stable enough to even get a screenie.
I could do some stuff this time although SuperPi crapped out before completing one iteration.

Back to work.