Hello wingo and list,
A couple days ago on #guile, I started a conversation about optimizing
some record types I use for linear algebra to take advantage of unboxed
arithmetic in the upcoming Guile 2.2. Andy informed me of a temporary
hack I could try, but then said that The Right Thing is for Guile to
unbox struct fields. So, I thought since Andy wrote such a nice post on
his blog about about Guile compiler tasks [0] that maybe I would give it
a try! I have gone about as far as I can on my own (not far), and seek
the guiding light of the Guile maintainers to help unblock me.
The task is as follows, quoting from the above mentioned blog post:
Guile's "structs", on which records are implemented, support unboxed
values, but these values are untyped, not really integrated with the
record layer, and always boxed in the VM. Your task would be to
design a language facility that allows us to declare records with
typed fields, and to store unboxed values in those fields, and to
cause access to their values to emit boxing/unboxing instructions
around them. The optimizer will get rid of those boxing/unboxing
instructions if it can. Good luck!
I took an exploratory romp around the codebase and here's what I've
learned:
- Guile indeed supports unboxed fields in the struct implementation.
Currently it only supports unboxed unsigned integers, but there's some
preprocessor magic that can be removed to enable unboxed signed
integers and doubles:
switch (field_type)
{
case 'u':
data[p] = SCM_NUM2ULONG (3, val);
break;
#if 0
case 'i':
data[p] = SCM_NUM2LONG (3, val);
break;
case 'd':
*((double *)&(data[p])) = scm_num2dbl (val, (char *)SCM_ARG3);
break;
#endif
...
- It's easy enough to create a vtable with unboxed fields:
(define vtable (make-vtable "uwuw"))
(define s (make-struct vtable 123 456))
(struct-ref s 0) ;; => 123
- struct-ref/immediate and struct-set!/immediate are the VM operations
for reading from/writing to structs
- Roughly speaking, in the case of unboxed unsigned integers, one would
want to insert a scm->u64 instruction before setting the value of an
unboxed field, and one would want to insert a u64->scm instructor
after getting the value of an unboxed field.
- In TreeIL, struct refs and sets are primcalls, and when compiling to
CPS they receive some special treatment to unbox the index component
of the respective operations. This might be the procedure that will
insert the boxing/unboxing instructions for the struct fields, but I'm
not sure.
Now that I've learned a little bit, I have a bunch of questions that I
cannot yet answer:
- Is it possible to know the layout of a vtable at compile time?
- If so, where is that information stored?
- If not, does this mean that TreeIL needs to be changed to be able to
store typed struct field data in order to generate the correct CPS?
- Can the TreeIL format even be reasonably changed since its a public
interface that people target when writing their own language
implementations?
Basically, how could I possibly get my hands on the vtable information
at compile time?
Help would be very much appreciated!
Thanks,
--
David Thompson
GPG Key: 0FF1D807
[0] http://wingolog.org/archives/2016/02/04/guile-compiler-tasks
