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;[EMAIL PROTECTED]:~'
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@redhat.com
https://www.redhat.com/mailman/listinfo/rhelv5-list
