My observations show that the results of the benchmark is heavily dependent on the amount of L2 cache.

 

Processor                    OS/Type   VM     L2 Cache       Results    Description
--------------------------------------------------------------------------------------------------
Intel Core2 Duo 2.0          32-bit  VMware   4096 KB          1:43s    Laptop
AMD Opteron 165 1.8          64-bit           1024 KB          3:08s    Home Desktop
AMD Opteron 165 1.8          32-bit           1024 KB          2:21s    Home Desktop
AMD X2  4400+                64-bit            512 KB          6:55s    Work Desktop
AMD X2  4400+                32-bit            512 KB          6:27s    Work Desktop
Intel Xeon(TM) Core2 2.80GHz 32-bit           2048 KB          2:39s    Work Server X-Series
Intel Xeon(TM) 3.00GHz Blade 32-bit  VMware   1024 KB          3:48s    Work Server VM Bladecenter

The ones running on AMD chips were all running RHEL5.  The servers (Core2 and Blade) were running RHEL4.  And, the laptop was running Kubuntu 7.10 under VMware on WinXP.  It appears that running in a virtualized environment has little effect.  Note that the X2 (which is faster) performed worse than the Opteron.   However, the Opteron has twice the L2 cache.  The laptop has the most L2 cache and beat them all significantly.  My thinking is that because of the large memory footprint this benchmark makes heavy use of L2 cache.

Richard Lynch
WVNET


John Summerfield wrote:

Pedro Espinoza wrote:

Thank you, Tony.

I just compiled with -m32, yes, it made a difference: from 8m40s to
2m51s, on that box. Is there any way to effect globally such that all
calls made to qsort() make use of 32bit stuff.

This benchmark is all very interesting in an academic sense, but I;m sceptical that it represents anyone's workload.

Nor does it do anything to exploit 64-bit capabilities. If you have lots of RAM then you stand to gain considerably from the 64-bit architecture;   the CPUs handle it much better.

I don't know whether it's related, but I've misguidedly been trying to repair my 64-bit Fedora 9A system with a 32-bit F8 rescue disk. It took around 30 minutes to get it running ready to use, whereas once I got the equivalent 64-bit media it was all over in a minute or two. The system has 2 Gbytes of RAM.

This "benchmark" tests very little, and the measurements might be useful as part of a model to estimate a system's performance, but it's of little use in deciding how to run a complex workload.

For that you need a benchmark that is typical of what you really do, that actually runs Perl scripts. If you load up databases then your benchmark must include that activity, either with the same version (for commercial such as Oracle) or with the version matching your OS (for free such as Postgresql).

You need to measure the _system_ performance, that is the hardware and the software both, in configurations you use or that you might use.

Meanwhile, here are some more numbers:
+ for o in s 1 2 3
+ cc sorttest.c -Os -lm -o sorttest
+ ./sorttest 20

real    1m17.105s
user    1m16.270s
sys     0m0.671s
+ for o in s 1 2 3
+ cc sorttest.c -O1 -lm -o sorttest
+ ./sorttest 20

real    1m16.831s
user    1m16.027s
sys     0m0.605s
+ for o in s 1 2 3
+ cc sorttest.c -O2 -lm -o sorttest
+ ./sorttest 20

real    1m16.941s
user    1m16.241s
sys     0m0.628s
+ for o in s 1 2 3
+ cc sorttest.c -O3 -lm -o sorttest
+ ./sorttest 20

real    1m16.821s
user    1m16.072s
sys     0m0.623s
++ echo -ne '\033]0;summer@localhost:~'

I can't test 32-bit on this system, I don't have the libraries installed.
+ cc sorttest.c -Os -lm -o sorttest
+ ./sorttest 40

real    2m32.955s
user    2m31.507s
sys     0m1.181s

-- 

_______________________________________________
rhelv5-list mailing list
rhelv5-list@(protected)
https://www.redhat.com/mailman/listinfo/rhelv5-list