mike@tuvie (Inst.f.Techn.Informatik) (07/15/90)
In article <1016@soleil.UUCP> gendel@soleil.UUCP (Gary Gendel) writes: >SUN (cc -O2) >GCC 1.37.1 (gcc -O) 12% slower, same size executable >GCC 1.37.1 (gcc -O -fstrength-reduce -finline-functions -fforce-mem) > 6% slower, 50% larger executable. If you look at gcc and compare it with the Dragon book's description of a code generator generator, you will find aut that gcc has just about everything a code geneator generator needs to have. Specification of code to be matched, semantic attributes, constraints for operands, the ability to simply emit a constant pattern or to use a piece of code to find the exact instruction... Note that if you look at gcc as a code generator generator, it is doing very well indeed. Most generators cannot boast getting roughly equivalent (or in some cases even better) performance than an equivalent hand-coded program. bye, mike Michael K. Gschwind mike@vlsivie.at Technical University, Vienna mike@vlsivie.uucp Voice: (++43).1.58801 8144 e182202@awituw01.bitnet Fax: (++43).1.569697 -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus| world}!esegue. Meta-mail to compilers-request@esegue.
dave@imax.com (Dave Martindale) (07/16/90)
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.