Round One, Fight!

Out of my own sheer boredomcuriousity, I wondered how the different architectures in the systems I have stand up to each other, so I devised some simple, completely unscientific benchmarks.

Take various CPU-dependent tasks and call them one unit of ‘work’. Divide that by the number of seconds taken to complete the task to get its work rate. Then divide it by the processor speed to get the work rate per clock to try and normalize the values a bit. Of course a 1.6GHz processor is going to waste a 400MHz processor in performance, but does it do so by a factor of four? Finally multiply it by 1,000,000 just so it’s not some horribly small decimal number. That should roughly measure how good each processor is at getting work done within a clock cycle.

The test systems are:
1) A 400MHz Pentium II, 100MHz FSB
2) A 1 GHz iBook G4, 133MHz FSB
3) An Athlon 1700+ (real clock rate 1.467 GHz), 133MHz FSB

Not exactly top-of-the-line compared to P4 Xeons, G5s, and Opterons, but hey, you work with what you have…

The test programs were all run under Linux 2.6.x and were compiled with GCC 3.2.3

Test

1) PII

2) G4

3) Athlon

MP3 encoding to 128kbps
lame –preset 128 lamentation.wav

8.18

4.84

8.99
Ogg Vorbis encoding, default quality
oggenc lamentation.wav

9.74

9.79

12.0
Gzip compression on source code
gzip -9 linux-2.6.3.tar

11.4

18.6

15.9
Bzip2 compression on source code
bzip2 -9 linux-2.6.3.tar

7.98

5.2

5.65
Blowfish encryption of a file
openssl enc -bf linux-2.6.3.tar

136.8

196.3

201.1

So, what does this mean? Well, probably nothing, since real benchmarks have to be stricter than this. :-) There are some interesting anomalies though.

The LAME and oggenc tests both use floating point, and in the LAME test, the G4 fell waaay behind the others. However, the LAME test had additional assembly optimizations for the x86 processors but not for the PowerPC. The oggenc test puts the Intel and G4 back on level ground, but then the Athlon pulls ahead by a fair bit, indicating it might have a slightly better floating point unit. (Ed.: A correction here, the original entry said the oggenc test was integer-only, but it turns out that only applies to the decoder, not the encoder.)

The gzip test is interesting since here the G4 beats both the Intel and Athlon chips by a fairly large margin. Compression is a fairly memory-intensive task, involving more memory scanning than math, so perhaps this indicates a better cache benefit on the G4. The real surprise is with the bzip2 test though, where the ancient old Intel comes out ahead. I’m not familiar with the bzip2 mechanics, but something about it must line up nicely with how the PII operates.

And finally, the encryption test isn’t too exciting. The recent architectures roughly equal, an older one falling behind, *yawn*…

So what’s the conclusion? Well, different CPUs are better at different things. Shocking, I know. :-) It’s hard to draw any firm conclusions since there are other factors unaccounted for still. Although the same compiler version was used on all the systems, there’s no guarantee that it’s equally efficient on each architecture, for example. Most people have x86s so the x86 optimizations are probably better tuned than the PowerPC optimizations. The effect of cache size and how the tests fit into it can also make a large difference.

Still, it’s interesting to note that the G4 is in roughly the same ballpark as the Athlon. When comparing two completely different architectures you might expect that one would be so clearly superior that the numbers wouldn’t even be close, but they’re keeping up with one another fairly well. The iBook’s performance is still lower overall, but it’s primarily due to its lower clock rate as a laptop than the CPU design itself.

Now if I could just get hold of those G5s, Opterons, and Xeons…

2 thoughts on “Round One, Fight!”

  1. Addendum: As an example of the difference the compiler can make, I redid the LAME test on the G4 under OSX, and its score went up to 5.81. That’s using Apple’s own customized gcc 3.3 which presumably optimizes better than stock gcc 3.2.3.

Leave a Reply

Your email address will not be published. Required fields are marked *