Xref: utzoo gnu.gcc:1761 comp.compilers:1051
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!lotus!esegue!compilers-sender
From: dave@imax.com (Dave Martindale)
Newsgroups: gnu.gcc,comp.compilers
Subject: Re: GCC SUN-4 code speed
Keywords: benchmarks, gcc
Message-ID: <1990Jul16.150502.23287@esegue.segue.boston.ma.us>
Date: 16 Jul 90 15:05:02 GMT
References: <1016@soleil.UUCP> <37555@ucbvax.BERKELEY.EDU> <1990Jul14.230954.14607@esegue.segue.boston.ma.us>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: dave@imax.com (Dave Martindale)
Organization: Imax Systems Corporation, Oakville Canada
Lines: 37
Approved: compilers@esegue.segue.boston.ma.us

The Sun-supplied C compiler and GCC each have weak points.  I doubt if you
can select the "best" compiler between the two, unless you have just one
program to compile.

A colleague brought up GCC here, and to try it out he compiled his favourite
test program, a Mandelbrot generator.  The gcc-produced code was faster and,
I think, smaller.  He was very happy.  I then compiled my most CPU-intensive
program, and the gcc-produced code was significantly slower, by perhaps 30%.
I was not happy.

We looked at the assembler output for the inner-loop routines for both
programs.  It was immediately apparent that the Sun compiler could be rather
stupid about expressions using register variables - the Mandelbrot code ended
up copying data from one floating-point register (the register variable) to
another scratch register before using it.  These redundant moves were what
slowed down the Sun compiler; the code was otherwise pretty much identical.

On the other hand, for my cruncher, the Sun compiler and gcc generated
essentially the same sequence of instructions, with no redundant operations.
The difference was that the Sun compiler had taken into account how long each
floating-point operation would take, and moved up integer instructions
(pointer increment, loop counter increment, etc.) from the bottom of the loop
into the spaces between the floating-point instructions.  This kept the
integer and floating-point units running in parallel whenever possible.  Gcc
just left the instructions in the "obvious" order; it didn't seem to
understand how to reorder code for the SPARC pipeline, and that's why it was
slower.

In hindsight, this is not surprising.  Gcc is better at a function that
benefits all machines - getting rid of redundant moves, or perhaps just
cleverer about register allocation.  The Sun compiler is better at the
SPARC-specific code reorganization needed to get good performance from that
architecture.

-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus| world}!esegue.  Meta-mail to compilers-request@esegue.