Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!hamachi@ucbkim
From: hamachi@ucbkim
Newsgroups: net.micro.mac
Subject: Re: C Compiler Benchmarks
Message-ID: <5124@ucbvax.ARPA>
Date: Wed, 27-Feb-85 21:14:24 EST
Article-I.D.: ucbvax.5124
Posted: Wed Feb 27 21:14:24 1985
Date-Received: Fri, 1-Mar-85 08:27:39 EST
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 48

From: hamachi@ucbkim (Gordon Hamachi)

Additional information concerning my C compiler evaluation at the
MacWorld Expo:

I sent my benchmark results to Bill Duvall at Consulair Corp. and he
phoned me right back with some comments:

1.  After the show he added register variables to his compiler.  With
    register variables the sieve program runs in 3.6 seconds.  Is that
    right?  I may have misunderstood him.

2.  Bill points out that the Megamax compiler uses 16 bit integers, while
    his compiler uses 32 bit integers.  When the Consulair compiler used
    16 bit integers in the sieve program the run time with his old compiler
    was 6.3 seconds.
    
    This is an excellent point.  I neglected to notice whether the other
    compilers used 16 or 32-bit integers.  Someone told me that the C
    standard stipulates that an integer's worth of bits must be able
    to span the entire address space.  I don't know about this.  Can
    someone comment?

3.  Bill doesn't think that the size of binaries for small programs is
    a significant test of a compiler.  With small programs it doesn't
    matter that much if some extra stuff gets loaded, while with larger
    programs almost everything ends up getting used.

    I personally have mixed feelings about this.  If you're limited to
    400K floppy disks, you probably don't want many useless bits on them.
    Bill says that he's planning a smarter linker that only links in what's
    needed.  The anticipated release date is a month after his April
    release (the one that will include floating point).

4.  Bill says that a better benchmark might have lots of function calls
    in it.  His compiler has paid special attention to making calls go
    fast, since he believes that real sized programs make lots of them.
    The sieve benchmark doesn't let him show off that feature.

    I'd have run the famous fibonacci benchmark if I'd had the time.  Many
    of the compiler vendor booths were so packed with people that I couldn't
    tie up their machines long enough to do everything I'd wanted.

Watch this space for additional details.  Consulair Corp. is lending me
a copy of their compiler so I can do additional evaluation.  I'll post
the results as soon as they are available.

--Gordon Hamachi