Matthew,
On Dec 1, 2009, at 1:12 PM, Matthew Flatt wrote:
> We don't
> have the type information to inline floats in structures or generic
> vectors, so we'll have to make do with types like `f64vector'.
I think inlining floats in structures or having enough inference to unbox generic vectors falls in the category of "nice, but not worth spending time on". If I want an unboxed float structure, I'll use an f64vector behind the scenes, and just wrap up some accessors. And, I don't really care if I have to use f64vectors when I want unboxed vectors, and vector-vectors when I don't. It's just not that much extra effort compared to the difficulty of the general type inference for Scheme.
For example, Bigloo is sometimes smart enough to notice that a given vector is only filled with floats, and specialize it to an f64vector-like structure (i.e. unboxed) automatically. But, the analysis required is fragile, and can essentially only be done on a whole-program basis. Additionally, you have to be *extremely* careful not to accidentally confuse the type analyizer, or things (silently!) degrade to a standard, boxed scheme vector. This isn't really useful in a numerical code---you want not only good performance, but predictable performance. If that means using an f64 prefix on some operations, well, it's still better than C :).
> Unboxed
> local binding is the big gap right now, as you pointed out.
Yes, I think this is probably important to get right eventually, but fortunately it's a much easier problem than the earlier one.
Thanks again for the detailed explanation. I'll try to put together a simple, but complete, N-body simulation in Scheme over the weekend so you have at least one larger-scale benchmark to use.
Will