gillies@m.cs.uiuc.edu (10/26/90)
I'm trying to benchmark some code on a SPARC SLC with a color monitor. Surprisingly, I can only soak up 25% of the CPU. Has anyone else encountered this problem? Is that other 75% of the CPU in the box, or is it an extra-cost option? I'm rather disappointed. The wall-clock time on the SPARC is much greater than the wall-clock time on our Multimax, yet the time command is claiming the SPARC has the potential to be faster. What am I doing wrong? What is to stop a vendor from modifying the kernal to lie about how much CPU is available (oh, our CPU is as fast as a CRAY-5, but unfortunately the OS takes 99.9% of the CPU. Just multiply our CPU-time figures by 1000 to get the actual speed of your benchmark...) [ on SPARC with no other users ] % time a.out Iters Ticks Ticks Ticks (60ths of a second) 500 1 3 1 1000 4 5 2 2000 10 11 6 5000 28 30 17 10000 61 63 36 20000 124 128 78 50000 312 322 209 100000 624 646 428 55.6u 0.3s 3:39 25% 0+720k 0+0io 1pf+0w [ on Multimax ] % time a.out Iters Ticks Ticks Ticks 500 4 5 6 1000 9 11 11 2000 20 24 24 5000 57 65 67 10000 122 139 148 20000 251 287 317 50000 635 747 852 100000 1286 1473 1751 143.6u 1.0s 2:24 99% 0+8k 0+0io 0pf+0w (I presume something is wrong with the multimax page-counting algorithm, since the program actually takes about 800k on the multimax).
gillies@m.cs.uiuc.edu (10/27/90)
False alarm, sorry. I didn't think to do "ps -ugra" to see who else might be running a detached background job. Apparently, there are several jobs that have been running in the background for days. Are all these benchmarks (Dhrystone, Whetstone, IOstone, SPEC, etc) measured in wall-clock time?