Playing with Exupery

Göran Krampe writes:
 > Hi folks!
 >
 > Just stumbled on this little tiny benchmark:
 >
 >    http://butunclebob.com/ArticleS.UncleBob.SpeedOfJavaCppRuby

Interesting, for what it's worth Exupery should be as fast or slightly
faster than VW for that benchmark. Though I may have lost a little
time recently but there's plenty of room for a little tuning to make
it back up.

First I had a look at what Exupery's doing with:

   tail -f Exupery.log | grep -v block

Which shows the following:

   9:38:21 pm: Initializing the Code Cache
   9:38:24 pm: Compiling SmallInteger>>to:by:do: inlining #()
   9:38:25 pm: Compiling WBKToys>>runOn: inlining #()
   9:38:29 pm: Compiling SmallInteger>>to:by:do: inlining {{61 . ExuperyBlockContext}}
   9:38:29 pm: Failed to inline ExuperyBlockContext>>value:
   9:38:29 pm: Compiling WBKToys>>runOn: inlining {{33 . Array} . {44 . Array} . {61 . Array}}

What's interesting is the #to:by:do. If you look at the bytecodes it's
there. If I wrote a compiled version of ExuperyBlockContext>>value
then even with the current bytecodes it should improve noticeably. Only
compiled primitives can be inlined at the moment.

Here's Exupery's benchmark suite:

   arithmaticLoopBenchmark 1387 compiled 127 ratio: 10.920
   bytecodeBenchmark 2139 compiled 484 ratio: 4.419
   sendBenchmark 1582 compiled 728 ratio: 2.173
   doLoopsBenchmark 1063 compiled 843 ratio: 1.261
   pointCreation 1075 compiled 1030 ratio: 1.044
   largeExplorers 585 compiled 595 ratio: 0.983
   compilerBenchmark 474 compiled 454 ratio: 1.044
   Cumulative Time 1058.337 compiled 521.541 ratio 2.028

The bytecode benchmark is a prime number sieve similar to what you
were using though coded to avoid sends and real blocks.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery