[racket] translate from Racket to Common Lisp
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