Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!msi.umn.edu!src.honeywell.com!uwm.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!wuarchive!psuvax1!rutgers!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!gillies From: gillies@m.cs.uiuc.edu Newsgroups: comp.arch Subject: Slow SPARC SLC? Message-ID: <3300201@m.cs.uiuc.edu> Date: 26 Oct 90 05:58:00 GMT Lines: 45 Nf-ID: #N:m.cs.uiuc.edu:3300201:000:1564 Nf-From: m.cs.uiuc.edu!gillies Oct 26 00:58:00 1990 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).