July 2009 - armedbear-devel - mailman3.common-lisp.net

[armedbear-devel] (lisp) Stack management efficiency
by Erik Huelsmann 21 Jul '09

21 Jul '09

Peter Graves pointed me at the language/implementation efficiency shootout at http://www.ffconsultancy.com/languages/ray_tracer/benchmark.html which implements a ray tracer in a multitude of languagues, one of them being Common Lisp. There are a number of rows, which I conviniently name version 1 (row 1) to version 5 (last row). Peter points out that version 1 isn't optized at all: all functions lead to function calls (no inlining). When running this code, it takes around 1440 seconds on my PC. Then I modified the stack management routine to re-use available stack frames (and conses), instead of creating new ones on every call. This took execution time down to around 1240 seconds. A good improvement, I'd say. However, with the change described above, stack frames won't ever become garbage anymore. My question is: does the loss of GC-ability outweigh the performance gain? Please note that it's possible to run without a lisp stack (but that also means without traces) by compiling code with a (SPEED 3) declaration. Comments? Bye, Erik.

7 16

[armedbear-devel] Parameterized Lisp Calls vs Array Calls
by logicmoo＠gmail.com 21 Jul '09

21 Jul '09

Parameterized Lisp Calls vs Array Calls In the code I added a Interface "barrier" just in-case there was some inlining /***********************START JAVA*************************************************/ package benchtest; interface ISomeFunParams { int SomeFun(int i, int j); } interface ISomeFunArray { int SomeFun(int[] ij); } interface ISomeFunVarArgs { int SomeFun(int... ij); } class BenchArrays1 { public static void main(String[] args) { ISomeFunParams sumFun = new SomeFunImpl1(); int res = 0; for (int i = 0; i < 100000; i++) for (int j = 0; j < 100000; j++) { res += sumFun.SomeFun(i, j); } // make sure we care about 'res' int foo = res; if (foo > 0) { res--; } } } class BenchArrays2 { public static void main(String[] args) { ISomeFunVarArgs sumFun = new SomeFunImpl2(); int res = 0; for (int i = 0; i < 100000; i++) for (int j = 0; j < 100000; j++) { res += sumFun.SomeFun(i, j); } // make sure we care about 'res' int foo = res; if (foo > 0) { res--; } } } class BenchArrays3 { public static void main(String[] args) { ISomeFunArray sumFun = new SomeFunImpl3(); int res = 0; for (int i = 0; i < 100000; i++) for (int j = 0; j < 100000; j++) { res += sumFun.SomeFun(new int[]{i, j}); } // make sure we care about 'res' int foo = res; if (foo > 0) { res--; } } } class SomeFunImpl1 implements ISomeFunParams { public int SomeFun(int i, int j) { return i + j; } } class SomeFunImpl2 implements ISomeFunVarArgs { public int SomeFun(int... ij) { return ij[0] + ij[1]; } } class SomeFunImpl3 implements ISomeFunArray { public int SomeFun(int[] ij) { return ij[0] + ij[1]; } } /***********************END JAVA*************************************************/ [root@titan ArrayBoundsCheckBenchmarks]# time java -cp bin/ benchtest.BenchArrays1 real 0m0.113s user 0m0.040s sys 0m0.013s [root@titan ArrayBoundsCheckBenchmarks]# time java -cp bin/ benchtest.BenchArrays2 real 1m42.898s user 1m21.279s sys 0m0.742s [root@titan ArrayBoundsCheckBenchmarks]# time java -cp bin/ benchtest.BenchArrays3 real 1m40.823s user 1m21.411s sys 0m0.651s

1 0

[armedbear-devel] Proposed patch to move remaining symbols to THREADS
by Mark Evenson 21 Jul '09

21 Jul '09

Attached is a proposed patch to complete moving the various THREADS related stuff into the new package. This patch removes the Gates implementation, as the new SYNCHRONIZED-ON and OBJECT-NOTIFY primitives provide more appropriate (i.e. more JVM specific) abstractions. If Tobias and Erik could check that this patch is what they want to have happen, I'll commit it. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] missing right parenthesis for Clisp in build script
by Robert Dodier 20 Jul '09

20 Jul '09

Hi, I tried to use the build-from-lisp.sh with Clisp but there was a missing right parenthesis in the forms to be evaluated on the command line. Just putting in another paren fixed it. HTH Robert Dodier

2 1

[armedbear-devel] Wikipedia page on ABCL deleted
by Kevin Krouse 18 Jul '09

18 Jul '09

Yesterday, the wikipedia minions decided ABCL is not "notable enough" and so have deleted the ABCL page: http://en.wikipedia.org/wiki/Armed_Bear_Common_Lisp http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Armed_Bear_Com… http://en.wikipedia.org/w/index.php?title=Special:Log/delete&page=Armed_Bea… I'm not sure what their requirements for notability are exactly. At any rate, it would be good to get the page restored and expand upon the sparse text that was originally there -- perhaps with code samples and links to projects using ABCL. Kevin

2 1

[armedbear-devel] patch for bug: function JVM::%FLOAT-BITS is undefined
by Anton Vodonosov 18 Jul '09

18 Jul '09

Hello, Consider the following java snippet: public static void main(String[] args) throws Throwable { Interpreter interpreter = Interpreter.createInstance(); interpreter.eval("(compile nil '(lambda () 0.1))"); } It fails with error: Debugger invoked on condition of type UNDEFINED-FUNCTION: The function JVM::%FLOAT-BITS is undefined. In the REPL (compile nil '(lambda () 0.1)) works normally. I do not understand what is the difference in environment between ABCL REPL and embedded ABCL, but the following trivial patch fixes the problem in for the embedded case. Index: src/org/armedbear/lisp/compiler-pass2.lisp =================================================================== --- src/org/armedbear/lisp/compiler-pass2.lisp (revision 12050) +++ src/org/armedbear/lisp/compiler-pass2.lisp (working copy) @@ -132,7 +132,7 @@ (defknown pool-float (single-float) (integer 1 65535)) (defun pool-float (n) (declare (optimize speed)) - (pool-get (list 4 (%float-bits n)))) + (pool-get (list 4 (sys::%float-bits n)))) (defun pool-long/double (entry) (let* ((ht *pool-entries*) @@ -163,7 +163,7 @@ (defknown pool-double (double-float) (integer 1 65535)) (defun pool-double (n) (declare (optimize speed)) - (let* ((n (%float-bits n)) + (let* ((n (sys::%float-bits n)) (entry (list 6 (logand (ash n -32) #xffffffff) (logand n #xffffffff)))) Best regards, - Anton

1 1

[armedbear-devel] Thread safety of the compiler (was: Thread safety of clos.lisp)
by Erik Huelsmann 17 Jul '09

17 Jul '09

Well, I've been investigating the issue with our clos.lisp not being thread safe and me seeing NullPointerExceptions. It turns out that GENSYM was not thread safe in case there were no thread-local special bindings: the SYMBOL-VALUE wasn't protected against being manipulated from 2 threads at the same time. I changed that. Now, even though clos.lisp is not thread safe, I'm not seeing any NullPointerExceptions anymore. The NullPointerExceptions were caused by the fact that COMPILE was running in 2 threads at the same time, generating the same symbol at the same time. Then, it called REMEMBER from both threads, one overwriting the value stored by the other. That doesn't cause NullPointerExceptions by itself, but when each thread loads its COMPILEd function, the constructor calls Lisp.recall(), which removes the key from the hash used for temp-storage. The second function then finds 'null' instead of the value it stored. So, that's another mystery solved. Fixed in trunk now. However, what remains is the fact that the remember/recall combo uses global keys while COMPILE may be generating thread-local key values. I'm wondering what to do about that. Possibly I should just create a ThreadLocal which has a temp-storage hash table per thread and document remember/recall are a thread-local storage mechanism. Of course, your opinions are welcome as always, especially with respect to the last paragraph. Bye, Erik.

1 1

[armedbear-devel] Thread safety of clos.lisp (and supporting Java classes)
by Erik Huelsmann 15 Jul '09

15 Jul '09

During my testing of multi-threaded use of ABCL over the past weeks, I found that ABCL performs reliably with 2 threads on 2 cores (fully dedicated to running ABCL code). However, there's one notable exception: Any code which requires CLOS, such as the pretty printer and other actions which require generic methods. I'm able to quite reliably break ABCL by starting a specific series of actions on 2 threads at the same time. (No global values in the program code!) The cause can be led back to slow-method-lookup; if I add SYNCHRONIZED-ON to it, the tests work fine. However, SLOW-METHOD-LOOKUP has friends which also manipulate the EMF-CACHE, so I don't think this would be the full solution. There's however an additional issue: Hashmap is defined to be thread-unsafe: 2 concurrent readers are fine, but concurrent writers or mixed concurrent readers/writers are not guaranteed to work. So, to guarantee results with the current EMF-CACHE implementation, we need to make sure there's 1 reader/writer at the same time - using synchronized-on, that is. For most applications this would be horribly inefficient: most methods will be added once and read huge numbers of times. ECL chose a rather unconventional direction in this case: instead of searching for lock-less semantics of global state, they have an EMF-CACHE per thread, meaning that read/write operations on the cache are thread-local and hence can be done lockless. ABCL could easily go with java.util.concurrent.ConcurrentHashMap, which is lock-less and allows concurrent readers and limited synchronous writers (~16 by default). However, this assumes that the actual threading issue is mainly with writing values to the cache. ie, before an "entry to be cached" is available, nothing happens which can't be overwritten immediately after it has been added to the cache. It's that last bit I have problems with assessing: do we simply need to use another caching hash class or do we need to do much broader "global" locking? (The "global" locking proposed would simply be locking that specific generic function; clos could easily run in other threads for other GFs...) Help welcome! Bye, Erik.

1 0

[armedbear-devel] Compiler macros vs source transforms
by Erik Huelsmann 14 Jul '09

14 Jul '09

While reading through precompiler.lisp, I noticed we have 3 concepts for transformation of lisp sources * normal macros, * compiler-macros, * source-transforms The difference between macros and compiler-macros is well documented in the CLHS; however, the difference between compiler-macros and source-transforms is unclear to me. I found that the former is expanded in compiler-pass1 while the latter is expanded in precompiler.lisp. However, when we're compiling for interpretation (not compilation), *in-jvm-compile* is NIL, meaning that source-transforms don't get expanded. The net effect would be that both source-transforms and compiler-macros only get expanded when we're compiling. I'm wondering what the benefit of source transforms is if this is really true. Bye, Erik.

3 4

[armedbear-devel] LispThread.execute, funcall(), stack frames
by Tobias C. Rittweiler 14 Jul '09

14 Jul '09

I just added http://trac.common-lisp.net/armedbear/ticket/60 Essentially the code needs some refactoring. It's not obvious that LispThread.execute is "execute with stack frame". It's also not really obvious when to use it. In fact, why is it there? Isn't it the same as Lisp.funcall()? -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1