[plt-scheme] Has PLT performance improved?

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.

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

On the other hand, native vectors would store the same range of
integer values relatively speedily and space-efficiently too, so
that's not a win either...

I suppose that the same concerns apply to the use of
bytevector-ieee-double-ref and friends under (rnrs bytevectors
(6)) libraries?

Cheers,

-- 
Andrew