armedbear-devel November 2009

armedbear-devel@common-lisp.net

12 participants
38 discussions

[armedbear-devel] Performance improvement special binding read/write
by Erik Huelsmann 10 Nov '09

10 Nov '09

Last weekend, I ran Maxima tests since some time again. I don't remember the older performance figures, although I remember the total test suite - possibly performance tuned - to take 3300seconds before. Last weekend, it was 3900seconds, giving me a feeling of performance regression. So I decided to take another look. I found two things, one of which is that we still have slow special binding value lookup. Peter Graves suggested some time ago that we switch to the same scheme used by SBCL and CCL because he found that XCL benefitted ~10% on his tests when he made the same switch. The scheme used by SBCL/CCL differs from the one used by ABCL in the way the "active" binding is being accessed. ABCL manages all bindings as a linked list, with the most recent one as the active one. This means O(n) access time on the number of special bindings. In SBCL/CCL, the active binding is stored in an array, with a linked list to record which values to restore when unwinding the binding. Upon restore, this solution takes more cycles than our solution: we simply change the head of the linked list, whereas the SBCL/CCL solution needs to set all the array elements. Running the application which we know tests special bindings performance the best [Maxima], I see a strong performance improvement: 3900 seconds before and 2300 seconds after the change. Performance improved by ~40%! I'll commit this change after cleaning up. Bye, Erik.

1 1

[armedbear-devel] Class file extenstions
by logicmoo＠gmail.com 10 Nov '09

10 Nov '09

I dont think this patch has any ill-effects - But I only tested on Win64/Linux64 Sun Java 6s Its for http://trac.common-lisp.net/armedbear/attachment/ticket/34 (Ignore the previous patch posted there) The goal of it.. for is for the start leveraging Ahead Of Time compilers like GCJ/EcellisorJET According to Peter the original use of ".cls" was more for figuring out which files to delete.. not because the classfile format was non-compliant. ---------------------------------------------------------------------------------------------------------------- Index: src/org/armedbear/lisp/compile-file.lisp =================================================================== --- src/org/armedbear/lisp/compile-file.lisp (revision 12273) +++ src/org/armedbear/lisp/compile-file.lisp (working copy) @@ -45,8 +45,8 @@ *output-file-pathname*)) "Computes the name of the class file associated with number `n'." (let ((name - (%format nil "~A-~D" - (substitute #\_ #\. + (%format nil "~A_~D" + (substitute #\$ #\. (pathname-name output-file-pathname)) n))) (namestring (merge-pathnames (make-pathname :name name :type "cls") output-file-pathname))))

1 0

[armedbear-devel] Inline primitives as static method calls
by Alessio Stalla 10 Nov '09

10 Nov '09

Attached is a patch + a Java class that tentatively implement logicmoo's idea of "inlining" primitives as calls to static methods (just for test on a single primitive, COPY-TREE). The Java class, InlinedPrimitive, extends Primitive and implements its execute() methods with static methods with a given name found in a given class. When interpreted or passed as a higher-order function an InlinedPrimitive calls the static method through reflection, resulting in slower performance than now. But, when compiled it is translated as a direct call to the static method, without passing through the symbol, which is faster than now (I haven't measured how much faster). Consider this patch as a rough draft - it must be polished if we ever decide to include it. In particular "inlining" is always performed, while we should probably avoid it with some debug/speed settings. Bye, Alessio

2 2

[armedbear-devel] SETF for JFEILDS
by logicmoo＠gmail.com 10 Nov '09

10 Nov '09

Hi, Could we add add something like this to java.lisp? (defun (setf jfield) (newvalue class-ref-or-field field-or-instance &optional ( instance :noinst) (value :novalue)) (if (eq instance :noinst) (jfield class-ref-or-field field-or-instance newvalue) (jfield class-ref-or-field field-or-instance instance newvalue))) -Thx

1 0

Re: [armedbear-devel] Changes to ConditionThrowable
by logicmoo＠gmail.com 08 Nov '09

08 Nov '09

Yep I had *improperly* tried to divide the three type of ControlTransfers They are indeed undistinguishable by class. In fact my now I remember: 3rd party code didn't catch the ControlTransfers but instead override ERROR/%DEBUGGER-HOOK-FUNCTION Symbol sym = Lisp.PACKAGE_CL_USER.findAccessibleSymbol("ERROR"); sym.setSymbolFunction(new CSThrowError(sym.getSymbolFunction())); sym = Lisp.PACKAGE_SYS.findAccessibleSymbol("%DEBUGGER-HOOK-FUNCTION"); sym.setSymbolFunction(new CSThrowError(sym.getSymbolFunction())); Then had to decide to handle it with inspecting the arguments with lines: 32-54 of http://code.google.com/p/opensim4opencog/source/browse/trunk/Cogbot/ScriptE… Thanks for he clarity. ----- Original Message ----- From: "Erik Huelsmann" <ehuels(a)gmail.com> To: <dmiles(a)users.sourceforge.net> Sent: Friday, November 06, 2009 11:39 PM Subject: Re: [armedbear-devel] Changes to ConditionThrowable Hi Douglas, On Sat, Nov 7, 2009 at 1:33 AM, <logicmoo(a)gmail.com> wrote: > My two cents: > > Those who call Lisp.eval(...) or mySymbol.execute() should at least be > capable of catching RuntimeCondition But should not be forced to also catch > Go and Throw > > The way it is now.. > I have a Primitive that I implement outside of ABCL. > It catches certain condition throwables but should not have to catch > Throw/Go > > which means: > ABCL calls my primitive. > My code is calling back into ABCL > I must catch ConditionThrowable. > I must also check to see if ConditionThrowable instanceof Go or instanceof > Throw. > If one of these things are true, I have to rethrow the Go or Throw > However I do not rethrow SeriousCondtions.. I have a different handler. > that may change the type of condition. > > > I suggest dividing the ontology of ConditionThrowable into two types: > > ControlTransfer > RuntimeCondition > Derive them both from RuntimeException if you'd like. The thing is: SeriousCondition is never thrown in terms of Java 'throw': it's either signalled or error-ed, which don't use the Java throw primitive. I think these conditions really *are* transfer-of-control events. Thanks for your feedback! Bye, Erik.

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.17.0 released
by Erik Huelsmann 07 Nov '09

07 Nov '09

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.17.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements JSR-223. This release features - among lots of other things - performance improvements, a fix for unexpected thread termination due to uncaught exceptions and example code for running ABCL on Google App Engine. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.17.shtml If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/abcl-src-0.17.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.17.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.17.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.17.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.17.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.17.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.17.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.17.0.zip.asc Erik Huelsmann

1 0

Re: [armedbear-devel] Changes to ConditionThrowable
by logicmoo＠gmail.com 07 Nov '09

07 Nov '09

Sorry I should said Go & Return -> ControlTransfer - > RuntimeException Throw -> RuntimeCondition -> RuntimeException Though some people use Throw for for flow control ----- Original Message ----- From: <dmiles(a)users.sourceforge.net> To: "Erik Huelsmann" <ehuels(a)gmail.com>; "Armed Bear" <armedbear-devel(a)common-lisp.net> Sent: Friday, November 06, 2009 4:33 PM Subject: Re: [armedbear-devel] Changes to ConditionThrowable > My two cents: > > Those who call Lisp.eval(...) or mySymbol.execute() should at least be capable of catching RuntimeCondition > But should not be forced to also catch Go and Throw > > The way it is now.. > I have a Primitive that I implement outside of ABCL. > It catches certain condition throwables but should not have to catch Throw/Go > > which means: > ABCL calls my primitive. > My code is calling back into ABCL > I must catch ConditionThrowable. > I must also check to see if ConditionThrowable instanceof Go or instanceof Throw. > If one of these things are true, I have to rethrow the Go or Throw > However I do not rethrow SeriousCondtions.. > I have a different handler. that may change the type of condition. > > > I suggest dividing the ontology of ConditionThrowable into two types: > > ControlTransfer > RuntimeCondition > > Derive them both from RuntimeException if you'd like. > > > > ----- Original Message ----- > From: "Erik Huelsmann" <ehuels(a)gmail.com> > To: "Armed Bear" <armedbear-devel(a)common-lisp.net> > Sent: Friday, November 06, 2009 11:49 AM > Subject: [armedbear-devel] Changes to ConditionThrowable > > >>A very prominent item in our API is that nearly every function is >> declared to throw ConditionThrowable. >> >> Personally, I have 2 gripes with that situation: >> >> 1) ConditionThrowable is the most undescriptive name of what it actually is and >> 2) Since ConditionThrowable is a completely *internal* thing to ABCL, >> it's wrong to expose it this way >> >> >> My proposal is to: >> >> 1) Rename ConditionThrowable to ControlTransfer - which is more of a >> description of what it does: it's used internal to ABCL to cause >> non-local transfer of control >> 2) Make ControlTransfer an unchecked exception (thus derive it from >> RuntimeException), because that'll allow us to keep it from being >> exposed in the API. >> We'll need to document in an abcl-embedding manual that callbacks >> should be aware of the fact that a ControlTransfer exception may cause >> the function's execution to be terminated. >> >> >> For normal API use, ControlTransfer won't be seen: it'll be thrown and >> consumed inside ABCL. >> >> >> How about that? >> >> Bye, >> >> >> Erik. >> >> _______________________________________________ >> armedbear-devel mailing list >> armedbear-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 1

[armedbear-devel] Changes to ConditionThrowable
by Erik Huelsmann 07 Nov '09

07 Nov '09

A very prominent item in our API is that nearly every function is declared to throw ConditionThrowable. Personally, I have 2 gripes with that situation: 1) ConditionThrowable is the most undescriptive name of what it actually is and 2) Since ConditionThrowable is a completely *internal* thing to ABCL, it's wrong to expose it this way My proposal is to: 1) Rename ConditionThrowable to ControlTransfer - which is more of a description of what it does: it's used internal to ABCL to cause non-local transfer of control 2) Make ControlTransfer an unchecked exception (thus derive it from RuntimeException), because that'll allow us to keep it from being exposed in the API. We'll need to document in an abcl-embedding manual that callbacks should be aware of the fact that a ControlTransfer exception may cause the function's execution to be terminated. For normal API use, ControlTransfer won't be seen: it'll be thrown and consumed inside ABCL. How about that? Bye, Erik.

2 1

[armedbear-devel] Compilation bug in LET/LET* init-form
by Mark Evenson 06 Nov '09

06 Nov '09

There seems to be a bug around the compilation of illegal LET/LET* init forms with an extra set of parentheses. The form (defun f () (let ((x ((1))))) 42) when placed in a file, and compiled gives a error on loading the file that it can't find the '.cls' associated with this function. Looking at the FASL shows that the '.cls' is zero length. The compiler should signal an error when compiling the form rather than writing the malformed FASL. Presumably this is a failure to recognize that the compilation of the the LET init form has failed somewhere in the compiler. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 3

Re: [armedbear-devel] 0.18 and beyond
by logicmoo＠gmail.com 06 Nov '09

06 Nov '09

>> How do you then pass the primitive as one? Like passing EQ/EQUAL/EQUALP >> to FIND/POSITION family of functions? Oh right, I understand the question a little better Here is that impl: http://larkc.svn.sourceforge.net/viewvc/larkc/trunk/platform/src/com/cyc/to… public static final SubLObject find(SubLObject item, SubLObject sequence, SubLObject test, SubLObject key, SubLObject start, SubLObject end) { // throw type error or allow user to supply a sequence type SubLSequence sequenceTyped = sequence.toSeq(); // find or compile 2 arg signture version of the Test function // if UNPROVIDED use EQ BinaryFunction testFunction = extractBinaryFunc(test); // find or compile 1 arg signture version of the key function UnaryFunction keyFunction = extractUnaryFunc(key); //unboxers (or force user to supply an int if not coercable) int startTyped = extractStart(start); int endTyped = extractEnd(end); // use the specific Seq find/5 impl SubLObject result = sequenceTyped.find(item, testFunction, keyFunction, startTyped, endTyped); return result; }

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel November 2009