Re: GCC SUN-4 code speed

dave@imax.com (Dave Martindale)
Mon, 16 Jul 90 15:05:02 GMT

          From comp.compilers

Related articles
Re: GCC SUN-4 code speed mike@tuvie (1990-07-14)
Re: GCC SUN-4 code speed dave@imax.com (1990-07-16)
| List of all articles for this month |

Newsgroups: gnu.gcc,comp.compilers
From: dave@imax.com (Dave Martindale)
Keywords: benchmarks, gcc
Organization: Imax Systems Corporation, Oakville Canada
References: <1016@soleil.UUCP> <37555@ucbvax.BERKELEY.EDU> <1990Jul14.230954.14607@esegue.segue.boston.ma.us>
Date: Mon, 16 Jul 90 15:05:02 GMT

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.


--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.