[plt-scheme] Why is the JIT Written in C?

At Tue, 1 Dec 2009 12:46:32 -0600, "Will M. Farr" wrote:
> I had not realized that there were unsafe-f64vector-ref and 
> unsafe-f64vector-set!, 

They're brand new and previously unadvertised (though documented).

> or that the JIT would unbox compositions of the various 
> unsafe operators. 

Still fairly new, but at least advertised once on plt-dev. :)

> * unboxing of floating-point values that are stored in purely local variables 
> and used in only float expressions
> * better code generation.
> 
> I'm guessing that the first is much easier than the second :).  For example, 
> instead of the expression 
> 
> >              (vs! result
> >                   i
> >                   (fl+ (vr result i)
> >                        (fl* (vr kernel j)
> >                             (vr signal k))))
> 
> it would be nice to have 
> 
> (let ((result (vr result i))
>       (kernel (vr kernel j))
>       (signal (vr signal k)))
>   (vs! result i (fl+ result (fl* kernel signal))))
> 
> with all the unboxing that appears in the uglier version (in addition, if you 
> use the kernel and signal elements of the vector again, it's possible to 
> reduce the f64vector "vr" overhead if these are stored unboxed in registers or 
> on the stack).  Perhaps the JIT already does this, and I'm just ignorant?  

No, the JIT doesn't yet do that. As a first step, I plan to have the
bytecode compiler convert the latter to the former, but that will work
only when a result is used just once and when the expressions
definitely can be reordered.

And, yes, better code generation is the more difficult one.

> In general, would it be possible to guarantee the same unboxing rules as in 
> OCaml (see http://caml.inria.fr/pub/old_caml_site/ocaml/numerical.html , in 
> the section about boxing)?

I think we're close, at least with the `unsafe-fl' operations. 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'. Unboxed
local binding is the big gap right now, as you pointed out.

> Let me know if you would like to have me implement some simple (but
> "real") numerical codes in Scheme for benchmarks that you can use for
> feedback on useful optimizations of the JIT. (i.e. a "full" N-body
> simulation, as opposed to a bunch of micro-benchmarks like FFT,
> convolution, the shootout N-body, matrix multiply etc.)

Yes, that would be very helpful. It's often difficult to tell whether a
given JIT change is worthwhile.