Code in Java:
int a = 1; int b = 0; long startTime = System.currentTimeMillis(); for (int i=0; i<1000; i++) { try { try { int c = a / b; } catch (Exception e1) { try { try { int c = a / b; } catch (Exception e2) { int c = a / b; } } catch (Exception e3) { } } } catch (Exception e4) { } } System.out.println(System.currentTimeMillis()-startTime); Code in Smalltalk: | a b c | a := 1. b := 0. [ 1000 timesRepeat: [ [ [ c := a // b. ] on: Exception do: [ [ [ c := a // b. ] on: Exception do: [ c := a // b ] ] on: Exception do: [] ] ] on: Exception do: [] ] ] timeToRun On my notebook: Java: about 36 ms, Squeak: about 25 ms VisualWorks: about 12 ms C# (on the other machine): more than 100 ms Cheers, -- Pavel |
Hi Pavel,
On 2/16/07, Pavel Krivanek <[hidden email]> wrote: > Code in Java: > ... > Code in Smalltalk: > ... are you being serious? Sorry for asking, I just want to make sure... Best, Michael |
In reply to this post by Pavel Krivanek
Here too, Squeak's VM (which, BTW, does all that context memory allocation
per send) is 50% better than the static's VM :) And it does only a bit better after you force class loading (i/o !) before the timed loop {java.io.PrintStream p = System.out;} {java.lang.Throwable t = new ArithmeticException();} and replace Exception by ArithmeticException (and ZeroDivide). FWIW, I think that the main reason for this difference is the heavy string processing in the vendor's libraries, once per exception thrown. /Klaus On Fri, 16 Feb 2007 22:03:20 +0100, Pavel Krivanek <[hidden email]> wrote: > Code in Java: > > int a = 1; > int b = 0; > long startTime = System.currentTimeMillis(); > > for (int i=0; i<1000; i++) > { > try { > try { > int c = a / b; > } catch (Exception e1) { > try { > try { > int c = a / b; > } catch (Exception e2) { int c = a / b; } > } catch (Exception e3) { } > } > } catch (Exception e4) { } > } > System.out.println(System.currentTimeMillis()-startTime); > > Code in Smalltalk: > > | a b c | > a := 1. > b := 0. > [ > 1000 timesRepeat: [ > [ > [ > c := a // b. > ] on: Exception do: [ > [ > [ > c := a // b. > ] on: Exception do: [ c := a // b ] > ] on: Exception do: [] > ] > ] on: Exception do: [] > ] > ] timeToRun > > On my notebook: > Java: about 36 ms, > Squeak: about 25 ms > VisualWorks: about 12 ms > C# (on the other machine): more than 100 ms > > Cheers, > -- Pavel > > |
In reply to this post by Michael Haupt-3
On 2/16/07, Michael Haupt <[hidden email]> wrote:
> Hi Pavel, > > On 2/16/07, Pavel Krivanek <[hidden email]> wrote: > > Code in Java: > > ... > > Code in Smalltalk: > > ... > > are you being serious? Sorry for asking, I just want to make sure... It's only small example how misguided results similar speed tests can give. Cheers, -- Pavel > Best, > > Michael > > |
Hi Pavel,
On 2/16/07, Pavel Krivanek <[hidden email]> wrote: > It's only small example how misguided results similar speed tests can give. phew. I'm glad I took the smiley in the subject line the right way. ;-) Best, Michael P.S.: Yes, I'm quite sensitive to overly simplistic so-called benchmarks, especially of the inter-language kind. ;-) |
In reply to this post by Klaus D. Witzel
Hi Klaus,
On 2/16/07, Klaus D. Witzel <[hidden email]> wrote: > FWIW, I think that the main reason for this difference is the heavy string > processing in the vendor's libraries, once per exception thrown. yup. In JVM implementations, the link to the meta level is not as direct as in Smalltalk VMs. This explains why Squeak is better off than Java. VW still being *much* better is interesting, though. Perhaps the JIT compiler kicks in, or the interpreter is much smarter. In Squeak, it can't, and in Java, it doesn't. (At least here: Macbook Pro running OS X, Apple JVM 1.5.0_07, verified by running the "benchmark" both with "java" and "java -Xint".) Could someone with access to VW VM internals please tell me what happens in there? I'm curious. :-) Best, Michael |
Hi Michael,
on Fri, 16 Feb 2007 23:26:34 +0100, you wrote: > Hi Klaus, > > On 2/16/07, Klaus D. Witzel wrote: >> FWIW, I think that the main reason for this difference is the heavy >> string >> processing in the vendor's libraries, once per exception thrown. > > yup. In JVM implementations, the link to the meta level is not as > direct as in Smalltalk VMs. This explains why Squeak is better off > than Java. :) but, again, this is not asked for in Google's summer of code 2007 :( > VW still being *much* better is interesting, though. Perhaps the JIT > compiler kicks in, or the interpreter is much smarter. In Squeak, it > can't, and in Java, it doesn't. (At least here: Macbook Pro running OS > X, Apple JVM 1.5.0_07, verified by running the "benchmark" both with > "java" and "java -Xint".) > > Could someone with access to VW VM internals please tell me what > happens in there? I'm curious. :-) I'm not a VW VM expert but the main difference is - http://www.google.com/search?q=visualworks+context+to+stack+mapping /Klaus > Best, > > Michael > > |
Hi Klaus,
On 2/16/07, Klaus D. Witzel <[hidden email]> wrote: > > yup. In JVM implementations, the link to the meta level is not as > > direct as in Smalltalk VMs. This explains why Squeak is better off > > than Java. > > :) but, again, this is not asked for in Google's summer of code 2007 :( hell yes. Can we change that? > I'm not a VW VM expert but the main difference is > - http://www.google.com/search?q=visualworks+context+to+stack+mapping Thanks for this pointer! That is something I *have* to read for sure. Best, Michael |
In reply to this post by Michael Haupt-3
On 16-Feb-07, at 2:26 PM, Michael Haupt wrote: > > VW still being *much* better is interesting, though. Perhaps the JIT > compiler kicks in, or the interpreter is much smarter. There *is no* interpreter in VW. When a method is activated in VW it only runs the translated code; if there isn't any in the n-cache it takes a moment to translate the bytecodes. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Trancelators interpret messages from the dead |
Hi Tim,
On 2/17/07, tim Rowledge <[hidden email]> wrote: > > VW still being *much* better is interesting, though. Perhaps the JIT > > compiler kicks in, or the interpreter is much smarter. > There *is no* interpreter in VW. When a method is activated in VW it > only runs the translated code; if there isn't any in the n-cache it > takes a moment to translate the bytecodes. thanks for pointing this out, that's good to know. :-) Best, Michael |
Free forum by Nabble | Edit this page |