[plt-scheme] Has PLT performance improved?

From: Eli Barzilay (eli at barzilay.org)
Date: Thu Jul 2 21:42:30 EDT 2009

On Jul  3, Andrew Reilly wrote:
> On Thu, Jul 02, 2009 at 12:10:29PM -0400, Eli Barzilay wrote:
> > On Jul  2, Philippos Apolinarius wrote:
> > > 
> > > I noticed also that PLT is not so good at array intensive
> > > computations. In one of those Lisp benchmarks designed to show that
> > > Lisp can be as fast as C, PLT (7.9s, without f64vector) is twice as
> > > much time as Bigloo (4.3s, without f64vector). Does PLT team intends
> > > to improve array processing?
> > 
> > An `f64vector' stores the FP numbers in a C vector, which means that
> > every access will create a Scheme floating point number -- so
> > accessing the same places over and over means that you keep generating
> > garbage for the GC.  Using a plain Scheme `vector' is likely to work
> > better, and provide more chances for the compiler to better optimize
> > the code.
> Oh, I thought that I had read that there had been some optimizations
> of floating point code to keep float locals on the stack.  Maybe I'm
> thinking of a different project.

Yes, that's exactly what should make plain Scheme floats much faster.
Items in an f64vector cannot be optimized, since as far as the core
mzscheme is concerned, it's just a bunch of binary data.

> The situation would be different for, say, s16vectors, because the
> resulting short integers would fit into the native pointer+tag
> format, right?

The main difference, I think, is that dereferencing a small integer
doesn't require allocating a Scheme object.

          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Posted on the users mailing list.