[racket-dev] better x86 performance

Here are the numbers for Racket, Typed Racket, Gambit and Larceny on
32 bits, and without Larceny on 64 bits.

Overall, we're competitive, but we're losing pretty hard on deriv.

Vincent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20110426/1a6bfdb4/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20110426/1a6bfdb4/attachment-0001.html>
-------------- next part --------------


At Sun, 24 Apr 2011 22:09:18 -0400,
Vincent St-Amour wrote:
> 
> These are impressive speedups!
> 
> Given how close we were to the fastest Scheme compilers on some of
> these, that may be enough to give us the lead.
> 
> I'll run the benchmarks on different implementations tomorrow.
> 
> Vincent
> 
> 
> At Sun, 24 Apr 2011 17:11:21 -0600,
> Matthew Flatt wrote:
> > 
> > The `assoc' example helped focus my attention on a long-unsolved issue
> > with JIT-generated code, where non-tail calls from JIT-generated code
> > to other JIT-generated code seemed more expensive than they should be.
> > This effect showed up in `assq' and `assoc' through a high relative
> > cost for calling `assq' or `assoc' on a short list (compared to calling
> > the C implementation).
> > 
> > This time, I finally saw what I've been missing: It's crucial to pair
> > `call' and `ret' instructions on x86. That won't be news to compiler
> > writers; it's a basic fact that I missed along the way.
> > 
> > When the JIT generates a non-tail call from to other code that it
> > generates, it sets up the called procedure's frame directly (because
> > various computed values are more readily available before jumping to
> > the called procedure). After setting up the frame --- including a
> > return address --- the target code was reached using `jmp'. Later, the
> > `ret' to return from the non-tail call would confuse the processor and
> > caused stalls, because the `ret' it wasn't matched with its `call'.
> > It's easy enough to put the return address in place using `call' when
> > setting up a frame, which exposes the right nesting to the processor.
> > 
> > The enclosed table shows the effect on traditional Scheme
> > microbenchmarks. Improvements of 20% are common, and several improve by
> > 50% or more. It's difficult to say which real code will benefit, but I
> > think the improvement is likely to be useful.