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

[armedbear-devel] Fw: [jvm-l] Re: Some Array vs GETFILED access times
by logicmoo＠gmail.com 02 Nov '09

02 Nov '09

----- Original Message ----- From: "Charles Oliver Nutter" <headius(a)headius.com> To: <jvm-languages(a)googlegroups.com> Sent: Sunday, November 01, 2009 8:47 PM Subject: [jvm-l] Re: Some Array vs GETFILED access times None of your results are too surprising to me. In JRuby, we moved several structures from encapsulating an array to using differently-sized "slotted" objects, with performance registering much better as a result. Some of that was due to the lack of boundschecks on the arrays, but another portion was probably due to the reduced size of an object + reference versus object + reference + array. Some comments inline below. On Sun, Nov 1, 2009 at 7:48 PM, <logicmoo(a)gmail.com> wrote: > public class ArrayVsClass { > > public static void main(String[] args) { > long lVectorStartTime = System.currentTimeMillis(); > int iterations = Integer.MAX_VALUE; > while (iterations-- > 0) { > // int iterations2 = 10; > //while (iterations2-- > 0) > { > //testArray(); // ARRAY > // vs > //testGETFIELD(); // GETFIELD > // vs > testIBean(); // INVOKE INTERFACE > // vs > //testBean(); // INVOKE VIRTUAL > // vs > //testABean(); // INVOKE VIRTUAL POSSIBLY THROW > // vs > //testSlots(); // INVOKE FOR AVALUE > } > } > long lVectorRunTime = System.currentTimeMillis() - lVectorStartTime; > System.out.println("Bench time: " + lVectorRunTime); > > } Because of optimization effects, you should try running them all together in the same benchmark in varying orders. Short benchmarks like these can skew actual results because only a small subset of the full code needs to be considered for optimization. > // SLOTS time: 33157,33250,33156 > public static void testSlots() { > ClassWithSlots oneSlot = new ClassWithSlots(6); ... > // Array time: 18438,18437,18422 > public static void testArray() { > final long[] accessArray = new long[] { 6 }; Not too surprising; you're paying the cost of the array plus the cost of the virtual invocation. So even after inlining, you've got something like boundscheck + deref + virtual call. > // GETFIELD time: 14688,14531,14453 > public static void testGETFIELD() { > ClassWithOneSlot oneSlot = new ClassWithOneSlot(6); ... > // INVOKE VIRTUAL time: 14750,14594,14719 > public static void testBean() { > ClassWithOneSlot oneSlot = new ClassWithOneSlot(6); This is exactly the pattern we use in JRuby for heap-based scopes. We have from ZeroVarDynamicScope up to FourVarDynamicScope and then it falls over into an array-based version. Because we can statically tell how many variable slots we'll need in most Ruby scopes, this ended up being a big perf improvement for us. > // INVOKE INTERFACE time: 14469,14610,14859 > public static void testIBean() { > IBeanWithOneSlot oneSlot = new ClassWithOneSlot(6); > > int iterations = Integer.MAX_VALUE; > long result = 0; > while (iterations-- > 0) { > result += oneSlot.getValue(); > } > } invokeinterface ends up as fast as invokevirtual once it's been inlined, so this is no surprise. > // INVOKE VIRTUAL POSSIBLY THROW time: 14641,14594,14547 > public static void testABean() { > AClassWithOneSlot oneSlot = new ClassWithOneSlot(6); Exception-handling paths not followed do not impact performance, so this is also not surprising. Try having one out of the N invocations trigger the exception and watch the perf change drastically from then on. - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages(a)googlegroups.com To unsubscribe from this group, send email to jvm-languages+unsubscribe(a)googlegroups.com For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---

1 0

[armedbear-devel] Some Array vs GETFILED access times
by logicmoo＠gmail.com 02 Nov '09

02 Nov '09

ABCL, For implementing MOP-like objects these times are something to consider. What I draw from it is when not messing with arrays (array bounds checking). Every case is better than. JVM-L, Do these tests with times make sense? package ArrayTests; public class ArrayVsClass { public static void main(String[] args) { long lVectorStartTime = System.currentTimeMillis(); int iterations = Integer.MAX_VALUE; while (iterations-- > 0) { // int iterations2 = 10; //while (iterations2-- > 0) { //testArray(); // ARRAY // vs //testGETFIELD(); // GETFIELD // vs testIBean(); // INVOKE INTERFACE // vs //testBean(); // INVOKE VIRTUAL // vs //testABean(); // INVOKE VIRTUAL POSSIBLY THROW // vs //testSlots(); // INVOKE FOR AVALUE } } long lVectorRunTime = System.currentTimeMillis() - lVectorStartTime; System.out.println("Bench time: " + lVectorRunTime); } // SLOTS time: 33157,33250,33156 public static void testSlots() { ClassWithSlots oneSlot = new ClassWithSlots(6); int iterations = Integer.MAX_VALUE; long result = 0; while (iterations-- > 0) { result += oneSlot.getValue(); } } // Array time: 18438,18437,18422 public static void testArray() { final long[] accessArray = new long[] { 6 }; int iterations = Integer.MAX_VALUE; long result = 0; while (iterations-- > 0) { result += accessArray[0]; } } // GETFIELD time: 14688,14531,14453 public static void testGETFIELD() { ClassWithOneSlot oneSlot = new ClassWithOneSlot(6); int iterations = Integer.MAX_VALUE; long result = 0; while (iterations-- > 0) { result += oneSlot.slot; } } // INVOKE VIRTUAL time: 14750,14594,14719 public static void testBean() { ClassWithOneSlot oneSlot = new ClassWithOneSlot(6); int iterations = Integer.MAX_VALUE; long result = 0; while (iterations-- > 0) { result += oneSlot.getValue(); } } // INVOKE INTERFACE time: 14469,14610,14859 public static void testIBean() { IBeanWithOneSlot oneSlot = new ClassWithOneSlot(6); int iterations = Integer.MAX_VALUE; long result = 0; while (iterations-- > 0) { result += oneSlot.getValue(); } } // INVOKE VIRTUAL POSSIBLY THROW time: 14641,14594,14547 public static void testABean() { AClassWithOneSlot oneSlot = new ClassWithOneSlot(6); int iterations = Integer.MAX_VALUE; long result = 0; while (iterations-- > 0) { result += oneSlot.getValue(); } } static interface IBeanWithOneSlot { public long getValue(); } static class ClassWithOneSlot extends AClassWithOneSlot implements IBeanWithOneSlot { final public long slot; ClassWithOneSlot(long s) { slot = s; } @Override final public long getValue() { return slot; } } static class ClassWithSlots { final public long[] slots = new long[1]; ClassWithSlots(long s) { slots[0] = s; } final public long getValue() { return slots[0]; } } static abstract class AClassWithOneSlot implements IBeanWithOneSlot { @Override public long getValue() { throw new NullPointerException(); } } }

1 0

[armedbear-devel] Fwd: [j-devel] Improving startup time: sanity check
by Erik Huelsmann 29 Oct '09

29 Oct '09

forwarding ---------- Forwarded message ---------- From: Alessio Stalla <alessiostalla(a)gmail.com> Date: Wed, Oct 28, 2009 at 11:34 PM Subject: Re: [j-devel] Improving startup time: sanity check To: Erik Huelsmann <ehuels(a)gmail.com> Cc: armedbear-j-devel(a)lists.sourceforge.net, Alex Muscar <muscar(a)gmail.com> On Wed, Oct 28, 2009 at 11:20 PM, Alessio Stalla <alessiostalla(a)gmail.com> wrote: > The test might be wrong It was, indeed, wrong. It measured class loading time too for reflection, but that can't be eliminated, no matter what instantiation technique you use. New results on 50000 iterations: REFLECTION: 9660480097 NEW: 88353767 % SLOWER: 10933 REFLECTION: 9602410291 NEW: 78459331 % SLOWER: 12238 REFLECTION: 9925574038 NEW: 86923015 % SLOWER: 11418 ~100 times slower is still impressive. Ale

1 1

[armedbear-devel] Fwd: [j-devel] Improving startup time: sanity check
by Erik Huelsmann 29 Oct '09

29 Oct '09

Sorry, we seem to be having this discussion on the wrong mailing list. Forwarding. ---------- Forwarded message ---------- From: Alessio Stalla <alessiostalla(a)gmail.com> Date: Thu, Oct 29, 2009 at 9:36 AM Subject: Re: [j-devel] Improving startup time: sanity check To: Erik Huelsmann <ehuels(a)gmail.com> Cc: armedbear-j-devel(a)lists.sourceforge.net, Alex Muscar <muscar(a)gmail.com> On Wed, Oct 28, 2009 at 11:34 PM, Alessio Stalla <alessiostalla(a)gmail.com> wrote: > On Wed, Oct 28, 2009 at 11:20 PM, Alessio Stalla > <alessiostalla(a)gmail.com> wrote: >> The test might be wrong > > It was, indeed, wrong. It measured class loading time too for > reflection, but that can't be eliminated, no matter what instantiation > technique you use. > > New results on 50000 iterations: > > REFLECTION: 9660480097 > NEW: 88353767 > % SLOWER: 10933 > > REFLECTION: 9602410291 > NEW: 78459331 > % SLOWER: 12238 > > REFLECTION: 9925574038 > NEW: 86923015 > % SLOWER: 11418 > > ~100 times slower is still impressive. Incidentally, if those figures are right, it means that class loading from byte array is very costly too, and Erik's idea is likely to improve performance significantly if the application never uses a relatively large part of Lisp.

1 0

Re: [armedbear-devel] [armedbear-cvs] r12226 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 27 Oct '09

27 Oct '09

> Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp Sun Oct 25 18:35:52 2009 > @@ -1948,6 +1948,8 @@ > (when (plusp (length output)) > output))) > > +(defvar *declare-inline* nil) > + > (defmacro declare-with-hashtable (declared-item hashtable hashtable-var > item-var &body body) > `(let* ((,hashtable-var ,hashtable) > @@ -1970,19 +1972,19 @@ > (declare-object symbol +lisp-symbol+ > +lisp-symbol-class+)))) > (t > - (let ((*code* *static-code*) > - (s (sanitize symbol))) > - (setf g (symbol-name (gensym "SYM"))) > - (when s > - (setf g (concatenate 'string g "_" s))) > - (declare-field g +lisp-symbol+ +field-access-private+) > - (emit 'ldc (pool-string (symbol-name symbol))) > - (emit 'ldc (pool-string (package-name (symbol-package symbol)))) > - (emit-invokestatic +lisp-class+ "internInPackage" > - (list +java-string+ +java-string+) +lisp-symbol+) > - (emit 'putstatic *this-class* g +lisp-symbol+) > - (setf *static-code* *code*) > - (setf (gethash symbol ht) g)))))) > + (let ((*code* *static-code*) > + (s (sanitize symbol))) > + (setf g (symbol-name (gensym "SYM"))) > + (when s > + (setf g (concatenate 'string g "_" s))) > + (declare-field g +lisp-symbol+ +field-access-private+) > + (emit 'ldc (pool-string (symbol-name symbol))) > + (emit 'ldc (pool-string (package-name (symbol-package symbol)))) > + (emit-invokestatic +lisp-class+ "internInPackage" > + (list +java-string+ +java-string+) +lisp-symbol+) > + (emit 'putstatic *this-class* g +lisp-symbol+) > + (setf *static-code* *code*) > + (setf (gethash symbol ht) g)))))) There's a thinko in the above hunk: it only re-indents, that was intentional. However, it assumes the package to intern into exist. When *declare-inline* is non-NIL, there's a fair chance the package hasn't been created at *static-code* time though. This means the symbol creation will need to happen in-line too. I'll fix this later today. Bye, Erik.

1 0

[armedbear-devel] Change the default action of 'build.xml' to 'abcl.clean abcl.wrapper'?
by Mark Evenson 26 Oct '09

26 Oct '09

[Including armedbear-devel@ for potential wider dicussion.] On 10/26/09 1:05 PM, Erik Huelsmann wrote: […] > > BTW: I'm always doing complete builds; are you too? Yeah, in fact I think the much more common use case of the build system is 'ant abcl.clean abcl.wrapper'. I almost always want a full build from scratch, which is now taking slightly under two minutes for my MacBook Pro laptop. A couple years ago, a full build took something like five minutes from what I remember, so there was more of a need for incremental builds. What's your usage pattern like? Maybe I should make 'abcl.clean abcl.wrapper' the default target, where the old behavior could be re-restablished via setting an Ant property. This is contrary to the behavior of most build systems that I have experienced, but since we could write a banner message like "Starting build from scratch; set 'abcl.build.incremental' in 'build.properties' to enable incremental builds in the future." Thoughts? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

[armedbear-devel] Binary FASL support
by Erik Huelsmann 26 Oct '09

26 Oct '09

As the result of an attempt to reduce our startup time, I implemented binary FASL support: a compiled lisp function (= Java class) which gets executed instead of the interpreted forms which used to constitute the texty fasl format. The texty format is still there, but in case of a binary fasl only contains 2 forms to be evaluated, the rest will be in the compiled function. I don't feel like we achieved much: my startup times used to be 0.4 s and 1.6 s and that doesn't seem to have changed. Bummer. However, that's probably to be expected, because I was just guessing where our performance issue would be: I want to know how much of the 0.4 and 1.6 seconds are actually spent waiting on I/O happening. In case we're waiting big time on the data coming from the JAR, maybe there's an optimization possible to the way we create/read the JAR file. Any help on the subject of reducing our startup time would be most welcome! Bye, Erik.

2 1

[armedbear-devel] Error in 'test.lisp' to create .abcl_completions
by John Pallister 23 Oct '09

23 Oct '09

Hello list, I think there's an error in the 'test.lisp' code used to create .abcl_completions at http://common-lisp.net/project/armedbear/doc/abcl-install-with-java.html . Basically it should start with (defvar symbols nil) or somesuch to avoid an UNBOUND-VARIABLE error. Cheers, John :^P -- John Pallister john(a)johnp.net john(a)synchromesh.com

2 1

[armedbear-devel] Binary release 0.17 (steps to be taken)
by Erik Huelsmann 23 Oct '09

23 Oct '09

I'm hoping to be able to publish binaries when releasing 0.17. However, I think we're not yet completely ready to do so. We're missing: * Usage descriptions in terms of an INSTALL file, or something similar * Build targets, like we have for the src archives, for abcl-bin-<version>.zip and abcl-bin-<version>.tar.gz * Anything else? As for the archives, I'd like them to contain many of our top-level files (COPYING, README, etc) and instead of the subdirectories, I think it should contain abcl.jar Comments? Bye, Erik.

2 2

[armedbear-devel] Bug: Attempt to GO to a tag whose extent has ended quits ABCL
by Brian Mastenbrook 23 Oct '09

23 Oct '09

When attempting to GO to a tag whose dynamic extent has ended, ABCL quits and prints the name of the exception used for internally handling GO (org.armedbear.lisp.Go). I see the same behavior in compiled or interpreted code. CL-USER(1): (lisp-implementation-version) "0.16.0" CL-USER(2): (let ((f nil)) (tagbody (setf f (lambda () (go foo))) foo) (funcall f)) org.armedbear.lisp.Go abcl-src-0.16.0 chandler$ -- Brian Mastenbrook brian(a)mastenbrook.net http://brian.mastenbrook.net/

2 1