[racket] translate from Racket to Common Lisp

Probably it's because I'm no authority on benchmarks, but I'm confused
in a couple ways.

It sounds like this is morphing into benchmarking C compilers?

Also I wonder about measuring a "best-case" scenario (find/install/use
best-available C compiler) vs. a "typical-case" scenario (using the
"out of box" default config).  AFIK the latter is being measured for
Racket.


p.s. When people have had a specific use case that's not working as
well as they expect, I've seen the Racket team (especially Matthew)
very interested and helpful. The resolution might be suggestions how
to use Racket differently. Or it might be an update to Racket itself
-- sometimes even within hours of the inquiry. As was the case in the
question prompting this thread, I think.


On Tue, Nov 6, 2012 at 7:29 AM, Marc Feeley <feeley at iro.umontreal.ca> wrote:
>
> Le 2012-11-06 à 3:50 AM, Hugh Aguilar <hughaguilar96 at yahoo.com> a écrit :
>
>> I am very impressed that Racket is as fast as it is. I had expected the compilers such as Gambit to be much faster than the VM-JIT system. If Racket had a 64-bit x86 assembler available, I might even consider using it instead of Gambit.
>>
>>
>> Message: 1
>> Date: Mon, 5 Nov 2012 08:09:19 -0500
>> From: Sam Tobin-Hochstadt <samth at ccs.neu.edu>
>> To: Matthew Flatt <mflatt at cs.utah.edu>
>> Cc: "users at racket-lang.org" <users at racket-lang.org>
>> Subject: Re: [racket] translate from Racket to Common Lisp
>> Message-ID:
>>     <CAK=HD+Yyr1R4K6emrgSXqie2c_AmT1BzhLpP1X=1NDXRgzsjGg at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> It's impressive to note the change in relative performance for Racket
>> over past 3 years since you published the benchmarks on the blog --
>> Racket has gone from slower than Gambit on the majority of benchmarks,
>> sometimes by a significant margin, to faster on most of them, and
>> never more than 2x slower (except ctak).
>
> For your information, it seems that the change in relative performance has more to do with the change in C compiler over the past 3 years than anything else.  The benchmarks were run on Mac OS X with the C compiler available with Xcode.  Recently Apple dropped distributing the GNU gcc compiler with Xcode, and the "gcc" program that is installed is actually a version which uses the gcc compiler parser but LLVM as a back-end (i.e. llvm-gcc).  That C compiler has bugs which prevent using gcc's computed gotos which are critical for the best performance.  This is what Gambit's "configure" script has to say when using llvm-gcc:
>
> configure:
> **************************************************************************
> ***                                                                    ***
> *** The LLVM GCC compiler that is being used may have a bug in the     ***
> *** compilation of label values (i.e. &&label).  This bug was          ***
> *** discovered when compiling Gambit with Xcode on Mac OS X (see bug   ***
> *** ID# 9956714).  For this reason the use of computed gotos in the    ***
> *** generated code has been disabled.  This greatly reduces the run    ***
> *** time performance.  The system runs 5 times slower than when it is  ***
> *** compiled with GNU GCC.  It is highly recommended that you use      ***
> *** another C compiler if possible.                                    ***
> ***                                                                    ***
> **************************************************************************
>
> I have suggested to Matthew that he rerun the benchmarks on a linux machine where GNU gcc is the default C compiler.  It will be interesting to see how that affects performance.
>
> Marc
>
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users