[armedbear-devel] svn r12228 breaks build

Wed Dec 2 19:00:50 UTC 2009

On Wed, Dec 2, 2009 at 6:49 PM,  <logicmoo at gmail.com> wrote:
> I have some progress towards the patch
> ;; INLINE REPORT total=653 cannot=1490 soon=0 inlined-calls=2280    <- thats in building ABCL library
>
> First, I rewrote a Java PrettyPrinter to transform the AST to make primtive subclasses produce static funcions in the outer
> classes.. Instead of reflection, I produced synthetic methods to make the non-static execute(..)s to call the static ones.
> 653 of these are done this way.
>
> Here is the transformed src: http://uabcl.googlecode.com/files/start-of-inlines.zip
>
> Then I used Allesio's .patch on compiler-pass2.lisp to make bytecode call the static methods instead.
> 2280 call site were transformed this way
>
>  First here was a couple successes: (from decompiling the .cls files)
>
>  lispobject.aset(Primitives._ARRAY_ROW_MAJOR_INDEX_execute(
>         lispobject, alispobject[2]).intValue(), lispobject1 = alispobject[0]);
>
>
>    That called #'ARRAY-ROW-MAJOR-INDEX
>
>  And
>
>  LispObject lispobject1 =
>       HashTableFunctions.GETHASH_execute(
>                                lispobject,
>                               SYM223280_TRACE_INFO_HASHTABLE.symbolValue(lispthread));
>
>   Before that inline it would have been
>
>       lispthread.execute(
>                 Symbol.GETHASH,
>                 lispobject,
>                 SYM223280_TRACE_INFO_HASHTABLE.symbolValue(lispthread));
>
> So that is good news!
>
>
> However I could not do this to 1490 call sites. due to the fact that there was no static function avalible because the primtive was
> produced by the lisp compiler and had no method stub.
>
>  lispthread.execute(SYM223284_SET_FDEFINITION, lispobject, lispobject2);
>
> That needed to say:
>
>    fdefination_22._SET_FDEFINITION_execute(lispobject, lispobject2);
>
> that was %set-fdefinition which was defined in fdefination.lisp

Yes, I think that's because iirc the compiler-written function classes
extend Primitive, but those aren't really primitives. We can't have
the compiler produce static methods and inline those all of the time,
or function redefinition won't work anymore! In fact, I believe that
inlining should not be done indiscriminatingly even for primitives
written in Java, but it should be done selectively just for those that
are heavily called and can be performance bottlenecks.
Also the reason I chose COPY-TREE for my earlier example is not
random: many of the primitives are already handled specially by the
compiler (e.g. the arithmetic functions, apply/funcall, ...) so they
don't get any benefit from trampolines, and should probably be left
alone. COPY-TREE was the first that I found that was not special-cased
and that could be handled easily with reflection.
Furthermore, the compiler could and should inline local functions
defined by flet and labels, but I'm afraid it's not that easy.
(Actually if it can determine that the local function is only used
locally and never returned or passed as argument to other functions it
should not even create a class for it, just a private final static
method).

Just my .02€

Alessio

>
> So I still need to do some more work on getting the lisp part o the compiler to
> produce outer method stubs with inroads to being called via invoke-static.
>
>
> I ran the ANSI-TESTS and CL-BENCH ..Tthe ansi-tests had too much variance in Time to say anything eigther way.. I proved to myself
> that the inlines was better.. a few times.. then I proved to myself a couple more time they weren't any faster.
> So didnt prove anything at all.
>  (and I had some regressions that have to be fixed by removing some struct things from the inlinable registry (or something))
> The CL-BENCH is also a bit too varied to say anything.  But shouldnt expect too much yet since only 1/3 of the callsites that should
> be inlined are when I ran them.
>
> PLEASE Anyone who wants, can download that .zip file and see of that can work on compiler-pass2.lisp
> To make the emitted primtives (and closures?)  to produce statically invokable sites.
> (Also a clear way to find thm at later compile passes)
>
> I am kinda sorta working on that.. but its easier for me to decompile the classes to .java..
> (I use a patched JODE instead of JAD).  Reprint them.. and recompile them (instead of doing it with .lisp)
>
> However doing it with comnpiler-pass2.lisp would be much prefered and appriciated
>
>
>
>
>
> ----- Original Message -----
> From: "Ville Voutilainen" <ville.voutilainen at gmail.com>
> To: "Alessio Stalla" <alessiostalla at gmail.com>
> Cc: <dmiles at users.sourceforge.net>; <armedbear-devel at common-lisp.net>
> Sent: Tuesday, December 01, 2009 1:55 AM
> Subject: Re: [armedbear-devel] svn r12228 breaks build
>
>
>> 2009/12/1 Alessio Stalla <alessiostalla at gmail.com>:
>>> Let me add that, iirc, our compiler is smart enough to translate
>>> (funcall #'something a b c) to the same code it generates for
>>> (something a b c). It would only need to fall back to reflection if
>>> the parameter to funcall is not constant, as in (let ((fn
>>> #'something)) (funcall fn a b c)). Also what is especially costly
>>> about reflection is not the invocation per se but the lookup of the
>>> methods, and that is done only once, when the primitive is
>>> instantiated or when it makes the first reflective call (depending on
>>> the "lazy" flag).
>>
>> I think the obvious route forward is to make a patch and measure. Then
>> we'll know whether there are performance changes. Has anybody done
>> measurements with the current partial patches, or have I missed a more
>> comprehensive patch?
>
>
> _______________________________________________
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>