GCC code generation sucks.... ([SunRescue] IPC dead as doornail... possible causes? )

[Greg A. Woods]

[ On Saturday, April 28, 2001 at 10:09:37 (-0400), Brian Hechinger wrote: ]
> Subject: Re: [SunRescue] IPC dead as doornail... possible causes?    
>
> >> Does gcc generate 64-bit code at all ? I don't think so but if someone
> >> proves me wrong i wouldn't be angry on them.                        
> >
> >It must do.  NetBSD runs on both DEC-Alpha and Sparc-64 and only uses    
> >GCC (or at least the more recent egcs version) as the system
> >compiler....                                                           
> 
> from what i understand, GCC is able to generate 64-bit code, but in the case
> of the sparc (can't speak for the alpha, although mine runs fine) it generates
> very poor code.

I think that's basically true of GCC across the board, but certainly for
Alpha it turns out to be less than optimal for at least two sample
benchmarks, as shown in this recent post from <port-alpha at netbsd.org>:

------- start of forwarded message (RFC 934 encapsulation) -------
Message-Id: <200104291732.SAA01055 at devnull.demon.co.uk>
Date: Sun, 29 Apr 2001 18:32:18 +0100 (BST)
From: Scott Telford <st at devnull.demon.co.uk>
To: port-alpha at netbsd.org
Subject: Benchmarks, and Compaq C

I've recently installed NetBSD 1.5 on a DEC 3000 Model 300L and, while
building a custom kernel, noticed that things were running a bit slower
than I expected. I then compiled up a couple of integer benchmarks I had
to hand (Dhrystone 2.1 and the "speedfcrypt" benchmark from Crack 4.0a)
which confirmed that my DEC 3000's integer performance was somewhere in
the ballpark of a mid-range 486, rather than the low-end Pentium I was
expecting (from the SPEC92 numbers).

To investigate further, I ran the same benchmarks on a selection of the
Compaq Test Drive Alpha boxes. The systems I chose were 466MHz EV6 DS10s
or DS10-Ls running Tru64 Unix 5.1A, Red Hat Linux 7.0 and NetBSD 1.5,
plus a 667MHz XP1000 running FreeBSD 4.2 (no DS10 running FreeBSD was
available). The results are summarized below (apologies if the tabbing
is wonky):

OS and compiler				Dhrystone	speedfcrypt

Tru64, Compaq C 6.4-007			~1558k/s	~26k/s

RHL 7.0, gcc "2.96"			~497k/s		~10.5k/s
RHL 7.0, gcc 2.91.66 ("kgcc")		~485k/s		-
RHL 7.0, Compaq C 6.2-506 for Linux	~1660k/s	~23k/s

FreeBSD, gcc 2.95.2 (667MHz)		~488k/s		-

NetBSD, gcc 2.91.66			~340k/s		~11.5k/s

Dhrystone was compiled without any optimisations, speedfcrypt was
compiled as per its makefile.

>From the results it seems obvious that NetBSD/alpha's lack of
performance is (as previously conjectured) largely due to gcc producing
deeply sub-optimal Alpha code compared to the Digital/Compaq compiler,
although RedHat's gcc "2.96" snapshot seems to have improved on it a
little. If the FreeBSD result is scaled by processor clock speed, then
it's pretty much exactly the same as the NetBSD number, which is
probably to be expected.

Whilst browsing the freebsd-alpha mailing list archives, I noticed that
the FreeBSD/alpha folks have made a port/package of Compaq C for Linux,
integrating it with the FreeBSD libraries etc. to produce native
FreeBSD/alpha binaries.  This seems like a cool idea - has anybody
looked at doing the same for NetBSD/alpha? If not, I'll try to look into
this sometime soon.

- -- 
Scott Telford,                                      st at devnull.demon.co.uk
Edinburgh, UK.                                      s.telford at bcs.org.uk

------- end -------

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>     <woods at robohack.ca>
Planix, Inc. <woods at planix.com>;   Secrets of the Weird <woods at weird.com>