On Tue, Dec 1, 2009 at 1:16 AM, dmiles@users.sourceforge.net wrote:
----- Original Message ----- From: "Erik Huelsmann" ehuels@gmail.com To: "Ville Voutilainen" ville.voutilainen@gmail.com Cc: armedbear-devel@common-lisp.net Sent: Monday, November 30, 2009 3:35 PM Subject: Re: [armedbear-devel] svn r12228 breaks build
On Mon, Nov 30, 2009 at 11:30 PM, Ville Voutilainen ville.voutilainen@gmail.com wrote:
2009/11/30 Ville Voutilainen ville.voutilainen@gmail.com:
I added the missing file, now the build should be ok. We can debate the merits of the trampoline separately.
Ok, r12290 gets rid of the LispTrampolinesFile completely. We don't need it, so I took it out.
Thanks.
The trampolines are a different issue. If they really are an issue to performance, we need to do something about it. However, if they're not we should not increase our startup costs: reflection seems to have a high lookup performance hit.
I believe for the "compiled library" in abcl.jar the use of calling only "static final" functions (AKA Trampolines) will be a tremendous speedup.
Here is some reasoning why:
All first order function calls, "(dosomething a b c)" would not use symbol primitives. and bypasses several java frames. (trace Allesso's COPY-TREE example so see how much overhead he removed)
But the worry that we have is:
Second order " (funcall #'dosomething a b c)" or "(sort foo #'mypred)" will hit reflection. This will penalize when done early (load time) or late (first call)). then durring runtime.
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). If all that is not enough, the techniques you suggested are interesting, though a bit too complicated for my personal tastes.
Cheers, Alessio
However even this is fixed in one of two ways:
There are 2 techiniques to get rid of reflection here:
First is at the source level with a AST printer that converts the execute(...) signature to calling the exact static methods that the compiler personally calls.
The second, is on on load time or first call to bytegenerate the primitive that makes each execute(..) that has an @SomeAnnotation(symbol="copy-tree",package="CL") public static final LispObnect copyTree(LispObject object) {..}
And this second get rid totally the primitive subclasses in .java!
Oh, There is also a even combination of the two....
At compile time the annotations are read.. and the .class(es) are generated. and packaged into the current archive.
Bye,
Erik.
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel