>From Rémi
Anyway, you can optimize the last instructions, <= should return a
boolean
so the sequence should be:
ldc 4100
aload 1
indy <= (ILObject;)Z
if_eq LABEL 1
I am not sure how to handle this in a Smalltalk envrionment. All of the
objec
>From Rémi
Without the descriptors of invokedynamic and the code of the BSM,
it's
hard to tell.
Yes but they have no invoke dynamics and I was just wondering if my indy
part was causing the
issue. Your answer told me that I should be OK so that was helpful. This
same code was
>From charles
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?
FWIW, I have done experiments with using enumerators instead of
integer loops
T
from Rémi
if you know it will never escape,you should use an int directly.
Well I am trying to build a Smalltalk system which has no static types so
I have to box the ints. Since the code I showed was programmer entered I
need to stay with the boxes.
There are cases where the compiler ge
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 t
On 02/01/2012 10:44 PM, Mark Roos wrote:
> This may be a little much to ask but... These bytecodes take about
> 20ns per cycle to run on
> my 2.8 GHz mac using jdk8-B23 without TieredCompile. Does this seem
> reasonable given the number of indy calls?
> The GWT depth on the method sends is 1
>
On 02/01/2012 10:44 PM, Mark Roos 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 prim
This may be a little much to ask but... These bytecodes take about 20ns
per cycle to run on
my 2.8 GHz mac using jdk8-B23 without TieredCompile. Does this seem
reasonable given the number of indy calls?
The GWT depth on the method sends is 1
thanks
mark
LABEL <56> LABEL 1
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
Thanks
Adding
-XX:-TieredCompilation
made the run time consistent at 21ms. Still not as fast as b20 ( 5ms )
but faster than 7u4
which is 29ms.
mark
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/m
On Tue, Jan 31, 2012 at 6:52 PM, Mark Roos 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
On Feb 1, 2012, at 9:34 AM, Rémi Forax wrote:
> On 02/01/2012 01:52 AM, Mark Roos wrote:
>> I just loaded about 250K lines of Smalltalk code into my jvm
>> implementation so now I can start
>> some real benchmarks using our application. All of this was done on a
>> Mac.
>>
>> My first try was
On 02/01/2012 01:52 AM, Mark Roos wrote:
> I just loaded about 250K lines of Smalltalk code into my jvm
> implementation so now I can start
> some real benchmarks using our application. All of this was done on a
> Mac.
>
> My first try was a object load which takes about 20 files and creates
>
13 matches
Mail list logo