Benchmarking Smalltalk on JVM

[Charles Oliver Nutter]

Ahh, ok, I figured it was something like that. So is your code there
actual code, or is it what you compile the code as when you realize
the value won't escape?

As in your case, the biggest limitation to JRuby's performance these
days is the cost of boxed numerics, so I'm always looking for ways to
eliminate or reduce that cost.

FWIW, I have done experiments with using enumerators instead of
integer loops over a given range, which acts similar to what you have
(since it's basically a mutable cursor that creates no new
language-visible values). In such cases, JRuby + indy can iterate over
a range as fast as Java.

- Charlie

On Wed, Feb 1, 2012 at 3:44 PM, Mark Roos <mroos at roos.com> wrote:
> Hi Charles
>
> Its pretty simple.  All of my integers are boxed and are by definition
> immutable.  However I noticed
> that many uses of integer were for loop counters and indexes where the
> integer never escapes from
> the method.  So I added two primitives, one to copy a integer into a new box
>  and the other to increment
> the java primitive held inside the box.  In all other ways it inherits from
> my Integer class.  The value is in
> reducing Integer creation for big loop/index ints.
>
> Usage looks like
>         position := 1 newMutable.   gets a mutable integer with an initial
> value of 1
>         position increment:1.            increments the internal primitive
>         position <= 100000          normal integer compare method
>
> I'll probably add a mutable bit to the header to protect the unwary in case
> it escapes but for now its
> a power tool.
>
> regards
> mark
>
>
>
>
>
> From:        Charles Oliver Nutter <headius at headius.com>
> To:        Da Vinci Machine Project <mlvm-dev at openjdk.java.net>
> Date:        02/01/2012 12:43 PM
> Subject:        Re: Benchmarking Smalltalk on JVM
> Sent by:        mlvm-dev-bounces at openjdk.java.net
> ________________________________
>
>
>
> On Tue, Jan 31, 2012 at 6:52 PM, Mark Roos <mroos at roos.com> wrote:
>> For the initial JDK7 I get 400ms,  moving to jdk8 b20 it drops to 117ms (
>> very nice).
>> I then converted some constructor lookups to statics to get to 66ms.
>> Then the obvious move to make an integer cache for which I used the jTalk
>> range of -2000 to 4000 gave 30ms
>> And finally ( to handle the index integer) I created a MutableInteger
>> which
>> dropped me to 5ms.
>
> Can you explain MutableInteger a bit more?
>
> - Charlie
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>