[Ecls-list] Pin your slots

[Juan Jose Garcia-Ripoll]

Hi,

being offline also has its advantages: no distractions. That means I
have been conducting my own personal hackaton for the last day and a
half. I must say this also arose because of my stubborn character and
because I want to prove that ECL is not fundamentally slow, just has
some rough spots.

I have identified two of them: TYPEP and slot acces. The former is
probably affecting a lot the CAS software (FriCAS, Maxima, etc), but
it can be solved. I have implemented, as a  first step, a compiler
macro that optimizes TYPEP when the type is constant and known. This
is really a win. Now doing something like (TYPEP x 'standard-class) is
much much faster, as it involves just calling a function that iterates
over the class precedence list of X.

Incidentally, this also revealed that CLASS-OF benefits from having a
precomputed vector of builtin classes to look at. That is also
implemented.

But the most interesting feature is constant-time slot access. That
is, reading and writing to slots without reverting to generic
functions and method dispatch. This is based on an old idea of mine,
which is currently used to bootstrap ECL. Namely, some direct slots
have an explicit location. Those slots are (I call them so) "sealed",
as their position is fixed throughout the class hierarchy.

The advantange of this is that the compiler can always infer the
position of a sealed slot if it knows at least one superclass of the
object we want to access. This makes it possible to optimize
CLASS-NAME, CLASS-SLOTS, etc, and also to bootstrap ECL, since the
position of these slots is know before methods are even active.

I have implemented now this in a more formal way, using the MOP. This
is done in two steps. First, when the class is finalized and
COMPUTE-SLOTS is called, it will order the slots in a way that
preserves any explicit location. User is not allowed to interfere with
this and any conflict will produce an error.

The second step is to generate the slot accessors, which now know the
precise position of the values in the instance -- at least for some
slots --. Note that even in this step we will use reader-class-method,
writer-class-method, etc.

The second layer is implemented in DEFCLASS, adding a new option
called :SEALEDP. This option seals all the slots of a class, so that
it and all its children classes know the positions of the slots
efficiently.

This would be useless if the compiler did not know how to use the
information of sealed slots. This has been implemented as well. When a
function is called, the compiler finds out whether it is a generic
function and whether their methods are all of the
standard-reader-method or standard-writer-method. If so, then it tries
to guess the classes of the arguments and, in case it can determine
that a valid access to a sealed slot will happen, it will optimize it.

Is this of any use? Well, indeed! The slowest component in ECL right
now is the pretty printer. Ours is a port of SBCL's pretty printer
using Gray streams. But Gray streams are classes which means that
formerly every slot access lead to a method dispatch -- unlike in
SBCL, where Pretty-stream is a structure with some internal magic to
turn it into an stream.

Ok, so I finished coding this and now pprint.lsp only has inlined
access to slots. If you take the stress test posted by Waldek long
time ago, pretty printing the file goes down from 2.4 seconds with CVS
HEAD to 0.4s with these fixes.

Interestingly this also revealed a lot of other places where ECL is
using too safe compiler settings which lead to redundant and slower
code.

Well, that's all. You must guess I needed to write this email after
such a big success :-) I will upload the patches next week, together
with the corresponding fixes for HEAD.

I welcome any comments on these ideas. They might be completely wrong,
since I am by no means a MOP expert O:-)

Regards,

Juanjo

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com