NAVOCEANO%OACIS@io.arc.nasa.gov (01/07/89)
This is a condensation of the responses to my recent query on optimizing C compilers for Sun3s. This was my first question put to the net and I have been very impressed by the quality of the responses. As a result of this study we have installed GNU C on our Suns and will soon be benchmarking some of our numerically intensive applications. I would like to thank everyone who helped with their contributions and particularly Richard Stallman and the Free Software Foundation for making GNU C available. Don Newcomb navoceano%oacis.decnet@norda.arpa navoceano%oacis@io.arc.nasa.gov ____________________ Have you checked into the GNU C compiler? We use that here, and it does a pretty good job of optimization. It does coloring register allocation, loop optimizations, optional strength reduction, etc. (I don't think it does instruction alignment, though.) On "standard" benchmarks (e.g. dhrystones, etc.) it comes out about 50% ahead of Sun's compiler. It may be a little slower for floating point, though; I haven't checked it. It's public domain (continually being improved), and available via anonymous FTP from prep.ai.mit.edu, among many other places. Oh yes, it also has ANSI C compatibility (prototypes etc.). Anton Rang rang@cpswh.cps.msu.edu ____________________ The GNU C compiler (gcc) does a very good job of optimization. It even supports -g -O, which provides an intermediate level of optimization while still allowing debugging. We use gcc for our operating system (Sprite) which runs on Sun2's and Sun3's, so we are confident with the quality of the generated code. Sorry I don't any specific numbers. Brent Welch University of California, Berkeley brent%sprite@ginger.Berkeley.EDU ____________________ > Has anyone else been underwhelmed by the optomization in the Sun-3 C > compiler? Which release are you running? SunOS 3.x has only the standard UNIX "peephole" optimization available for C on the 68K. SunOS 4.0 has the same global optimizer that Sun FORTRAN, and the Sun-4 compiler, have; however, in 4.0 you have to compile with "-O2" or higher, not just "-O", to get it. (In a future release "-O2" may become the default.) > Does anyone have experience with or information about C compilers that > do a realy good job of optomizing for the 68020? The GNU C compiler is supposed to do a pretty good job. Note: An interesting but lengthy discussion on optimization has been deleted in the interest of brevity. We are running SunOS 3.4. ____________________ srs!matt@uhura.cc.rochester.edu: We purchased the Green Hills C compiler for our Sun systems about a year ago. We found that although it did produce better code from "normally" written C source, our somewhat Sun-modified C source ran faster using the Sun compiler. The Green Hills compiler (gcc) has many optimization techniques, but one thing it didn't have was a way to generate "dbra" loops in C. This can be done as: for (i=count; i--; ) do_one_machine_instruction; /* like y += *x++ */ in the Sun compiler. You need to supply the -O switch, and for some strange reason, the routine this code belongs to MUST return the type of operand it is declared to return (or return nothing if it is of the void type). Overall, the gcc compiler appears very good. It's just that we were already in the habit of hand-optimizing our own C code to the Sun system so that using gcc didn't help. We never put it into general use. Other Sun (release 3.x) compiler tricks: there are 6 data registers that can be used/declared, use them! there are 5 address registers use 16 bit integers on 68010 machines whenever possible We were doing lots of work on Sun2 computers at the time, and that's when/why we really needed to get everything we could out of them. I think we ended up getting a 128 point FFT every 13ms on a Sun2. The dbra stuff was necessary to achieve this... uucp: {rutgers,ames}!rochester!srs!matt Matt Goheen internet: matt@srs.uucp OR matt%srs.uucp@harvard.harvard.edu Note: I tested GNU C. It passes the dbra test with flying colors. ____________________ In the process of this study I also posted a query to info-gcc@prep.ai.mit.edu about the opitmizations used by GNU C. I found out that what I (in my ignorance) was calling alignment and concurrency optimization generaly goes by the moniker "instruction scheduling". These are the responses from that query: ____________________ gnu@toad.com: Motorola was claiming in 1985 that instruction scheduling would not be very useful on the 68020, so Sun (where I worked at the time) did not implement it for the 68020. As far as I know, nobody else has either. You could try it and see; also, the 68030 might be different. (In particular, cache lines in the 68030 are 16 bytes, not 4 bytes, so alignment of branch targets, subroutine entry points, etc on 16-byte boundaries might improve performance slightly.) John Gilmore ____________________ rms@wheaties.ai.mit.edu (Richard Stallman): I have heard rumors that insn scheduling is useful for 68881 insns with the 68020, but GCC does not try to do this. Someone is working on a portable scheduling pass; when it is done, perhaps it will be reasonable to try this.