Subject: Benchmark results for gcc From: ajayshah@lill.frmug.fr.mugnet.org (Ajayshah) Date: Tue, 1 Jun 1993 12:11:00 +0001
ÿ@SUBJECT:Benchmark results for gcc -O2 to compile jgraph
ÿ@ORIGIN :University of Southern California, Los Angeles, CA, US N
Message-ID: <1ug9kv$k4u@almaak.usc.edu>
Newsgroup: comp.benchmarks,comp.os.linux,comp.unix.pc-clone.32bit
comp.sys.sun.misc
The relevant file is pub/jgraph.Z on princeton.edu
You must edit the makefile to use gcc -O2 (doublecheck: just setting
CFLAGS is not enough).
This is 5000 lines of .c files.
Unless otherwise stated below, the PCs are all running Linux and the
Sun is running SunOS 4.1.x, and the gcc version is 2.3.3+.
`Time' here is wall clock time under the assumption that no other
processes are active.
Some of the results are a bit odd -- e.g. 386@40 w/16M is faster
than a 486@33 w/20M :-)
Using CFLAGS = -O2
==================
386@40, 64k cache, 8Meg, IDE disk 720s
from John DiMarco (jdd@cdf.toronto.edu)
IPC w/24M, SunOS 4.1.1 217s
from Nicolai Langfeldt (janl@ifi.uio.no)
486@33 w/16M, SCSI 205s
from Brian Edmonds (edmonds@edmonds.home.cs.ubc.ca)
486@33 with 20M 177s
from Bill Broadley (broadley@neurocog.lrdc.pitt.edu)
386@40 w/16Meg, IDE disk 165s
from Dana Jacobsen (jacobsd@heart.cor.epa.gov)
SS2, SunOS 4.1.3, gcc 2.4.1, gmake 3.67 125s
from John DiMarco (jdd@cdf.toronto.edu)
Classic with 16M and tmpfs, Solaris 2.2 121s
from Ajay Shah (ajayshah@rcf.usc.edu)
Sparcsystem 600 with 384M 120s
from David Mazieres (maziere1@das.harvard.edu)
486@50 w/16M, running SVR4 100s
from Dana Jacobsen (jacobsd@heart.cor.epa.gov)
SS 10/30, SunOS 4.1.3, gcc 2.4.1, gmake 3.67 99s
from Dana Jacobsen (jacobsd@heart.cor.epa.gov)
SS 10/41, SunOS 4.1.3, gcc 2.4.1, gmake 3.67 78s
Using CFLAGS = -O2 -pipe
========================
from Nicolai Langfeldt (janl@ifi.uio.no)
486@33 w/16M, SCSI 210s
from John DiMarco (jdd@cdf.toronto.edu)
IPC w/24M, SunOS 4.1.1 165s
from John DiMarco (jdd@cdf.toronto.edu)
Classic with 16M and tmpfs, Solaris 2.2 121s
from Dana Jacobsen (jacobsd@heart.cor.epa.gov)
SS2, SunOS 4.1.3, gcc 2.4.1, gmake 3.67 113s
from Brian Edmonds (edmonds@edmonds.home.cs.ubc.ca)
486@33 with 20M 105s
from Ajay Shah (ajayshah@rcf.usc.edu)
Sparcsystem 600 with 384M 100s
from Dana Jacobsen (jacobsd@heart.cor.epa.gov)
SS 10/30, SunOS 4.1.3, gcc 2.4.1, gmake 3.67 97s
from Dana Jacobsen (jacobsd@heart.cor.epa.gov)
SS 10/41, SunOS 4.1.3, gcc 2.4.1, gmake 3.67 73s
Using CFLAGS = -O2 -pipe and gmake -j
=====================================
from Brian Edmonds (edmonds@edmonds.home.cs.ubc.ca)
486@33 with 20M 105s
600 MP with 4 (SS2) CPUs 62s
===========================================================================
Eirik Fuller <eirik@elf.Ithaca.NY.US> writes:
If you were using both compilers in native mode, there might have been
a difference in the complexity of the compilation because of the
difference in target CPUs. Offhand, I'd guess the sparc compilation
takes more CPU time (all else equal, which it isn't) because of things
like instruction scheduling.
If, on the other hand, you compared a native 386 compiler with a sparc
cross compiler generating 386 code, that would be a more even match.
I suppose you could also compile to sparc code ona 386, but I don't
see much point in that.
It's also conceivable that header files affect the compilation to the
point of skewing the results. This is not an issue when cross
compiling on one machine, to perform exactly the same compilation as
on the other.
===========================================================================
Dana Jacobsen (jacobsd@solar.cor2.epa.gov) writes:
All systems running SunOS 4.1.3, gcc 2.4.1 -O2, GNU Make 3.67, all times are
elapsed wall clock time in seconds, all systems are uni-processors:
Sparc 2 Sparc 10/30 Sparc 10/41
make gcc -O2 125 99 78
make -j 2 gcc -O2 116 92 74
make -j 3 gcc -O2 107 89 73
make gcc -O2 -pipe 113 97 73
make -j 2 gcc -O2 -pipe 108 89 72
make -j 3 gcc -O2 -pipe 110 87 76
My conclusion is that using parallel makes on a uni-processor machine saves
time (to a certain degree -- continuing to use more processes increases
contention until it is a loss -- this is why one probably should not blindly
use "-j" but instead "-j #" where # makes sense for the number of processors
on the machine, or use the "-l" option also). If gcc does not use pipes,
then there is more I/O going on, so using parallel makes smooths out the
response more; i.e. using the "-pipe" option keeps the processor busy most
of the time, just like using parallel makes with or without -pipe.
===========================================================================
In case you planned on using jgraph -- it does not work on Linux
out of the box!
Ronald Jeppesen (RONJ.AN@site007.saic.com) writes:
The problem with jgraph is that it uses some floating point values
that have been allocated with malloc() and not initialized. The
easiest fix is to change all the malloc(size) calls to calloc(size,1)
so that things are initialized. If I remember correctly there are
only a few places that this needs to be done -- use grep.
-- Ajay Shah, (213)749-8133, ajayshah@rcf.usc.edu