Re: guile 3 update: instruction explosion for pairs, vectors

[Andy Wingo <wingo@pobox.com>]

On Tue 09 Jan 2018 15:30, Mikael Djurfeldt <mikael@djurfeldt.com> writes:

> Maybe this is all completely obvious to you, but I want to remind,
> again, about the plans and ideas I had for GOOPS before I had to leave
> it at its rather prototypical and unfinished state:
>
> As you recall, generic functions (GFs) then carried a cache (ideas
> taken from PCL) with "instantiated methods" (IM; there is probably a
> better term and I might have called them "compiled methods" or
> "cmethods" before)---method code where the types of the arguments are
> known since each instance come from an actual invocation of the
> GF. Given a new invocation, the dispatch mechanism would just use
> argument types to look up the correct IM.
>
> I then had the idea that since we know the types of the arguments of
> the IM, a lot of the type dispatch could be eliminated within the IM
> based on flow information---very much in line with what you are doing
> here. If we now add one more piece, things get really exciting:
> Wherever there is a call to other GFs within one IM and the types of
> the arguments can be deduced at the point of the call, then the
> polymorphic type dispatch of the GF can be eliminated and we can
> replace the GF call with a direct call to the corresponding IM.

I totally agree!  You could call the compiler at runtime to produce a
type-specialized method.  There are some tricky things (how to embed a
precompiled Tree-IL representation of the method into the reified .go
file?  Possible but needs work).

Thinking more globally, there are some more issues -- one is that
ideally we need call-site specialization.  A GF could be highly
polymorphic globally but monomorphic for any given call site.  We need
away to specialize.

Secondly, it would be nice of course to have speculative optimization,
including speculative inlining and type specialization not only on GF
arguments but also arguments to regular calls, types of return values,
and so on.

Finally I wonder that if we had the latter, if it matters so much about
optimizing generic functions in any kind of specific way -- instead you
could just have a generic optimizer.

Of course the speculative optimizer could work on traces instead of
methods, and in that case we'd get a lot of this stuff for free... but
that's a question for farther down the road.  See
http://scheme2016.snow-fort.org/static/scheme16-paper3.pdf.

Cheers, and happy new year to you too!

Andy