phr@mit-hermes.UUCP (02/19/87)
I just ran the notorious Dhrystone benchmark through the GNU C
compiler and compared the results with the Unix compiler. They
generally favor GCC. Recent discussion on comp.arch suggests that
Dhrystone is not a wonderful measurement of either CPU or compiler
performance, but it's better than nothing; don't treat these numbers
as if they were holy.
The first four runs were with 50000 Dhrystone passes; the last two
were with 500000. The 500000 pass test was time consuming so I only
ran it with optimizers on (the interesting case). Each of the first
four tests were run twice in succession to get things into cache, and
the SECOND timing is given in each case. The last two tests were run
only once each. All measurements were taken on an unloaded diskless
Sun 3/75 workstation with 8 megabytes of memory running Sun 4.2bsd
Unix. I don't know the exact release numbers of the Sun OS or
compiler. Times are in seconds, sizes in bytes. Compile times are
user time followed by system time.
Compiler Compile time Code size Run time Dhrystones/sec
GCC, opt off 3.6u/1.8s 1888 18.5 2707
Sun cc, opt off 3.9u/1.4s 1812 16.4 3061
Sun cc -O 5.5u/1.8s 1576 15.0 3363
GCC -O 4.0u/1.4s 1348 12.6 4005
Sun cc -O (as above) 149.3 3368
GCC -O (as above) 125.4 4012
Remarks:
1. GCC will go into beta test pretty soon now; we'll make an
announcement when that happens. Please don't flood us with mail
yet. It will eventually be distributed free, like GNU Emacs.
(Hats off to RMS for this winning new compiler).
2. Code from GCC without -O runs slow because some optimizations
are deliberately not done in order to improve debuggability of the
object code. However, you can still use gdb or dbx on gcc -O
output, with some success.
3. Dhrystone.c is probably not large enough for the code size numbers
in this test to be meaningful, but generally gcc -O output is
several percent smaller than cc -O output.
4. I hope to try the benchmark on the Vax pretty soon.root@sdd.UUCP (02/26/87)
What CPUs / architectures / a.out formats is the GNU C compiler work for? How easy will it be to port the compiler to other machines / CPUs? Is gbd the GNU equivalent to sdb? If so, is it currently available. I would like to have a debugger that works with C++. Daniel Corbett Software Design & Development Corp Camarillo, CA 93010 UUCP: ihnp4!nrcvax!sdd!root
cwruacm@cwruecmp.UUCP (02/28/87)
In article <376@sdd.UUCP> root@sdd.UUCP (Root) writes: > >Is gbd the GNU equivalent to sdb? If so, is >it currently available. I would like to have a debugger that >works with C++. > Daniel Corbett From what I've gleaned through very limited experience with it, gdb is closer to dbx (Berkeley debugger) than sdb. On a related topic, how has Sun extended dbx to use it as dbxtool? What new features does it have? Chet Ramey ARPANET: cwruacm%case@relay.cs.net ramey%cwru-20%case@relay.cs.net CSNET: cwruacm@case or ramey%cwru-20@case UUCP: {...}!decvax!cwruecmp!cwruacm or {...}!decvax!cwruecmp!ramey@cwru-20 BITNET: ramey%cwru20@cu20b "we built this city on structured code..."
phr@mit-hermes.UUCP (02/28/87)
In article <376@sdd.UUCP> Daniel Corbett writes: > > What CPUs / architectures / a.out formats is the GNU C compiler >work for? How easy will it be to port the compiler to other >machines / CPUs? Is gbd the GNU equivalent to sdb? If so, is >it currently available. I would like to have a debugger that >works with C++. 1. Currently backends exist for vax, 68000, and 68020. It produces assembly code, so the a.out format is not relevant (but it produces debugging info used by 4.2bsd as/ld). 2. GCC is reasonably easy to retarget. Someone who has looked at both GCC and Unix PCC says that GCC is probably easier, but who knows. Documentation on GCC internals for would-be retargeters is being written and some will be available when GCC is released. 3. GDB is more like DBX than SDB. It has been in distribution for a year or so on the GNU Emacs tape. It works on Vaxes and Suns under 4.2bsd. We have no plans to make it work under Sys V although others are welcome to try. Making it work with other languages (e.g. C++) will be of more interest once we have more front ends for GCC.