[Jython-users] Re: [JPython] HP HotSpot JIT vesus JPython?

[<bc...@wo...>]

On Sat, 13 Jan 2001 23:21:02 -0800 (PST), you wrote:

>Thanks for the benchmark.   Here's what i got on Linux and HP. 
>Interesting HP result.
>
>Linux:
>
> Linux: /home/mudd[1]  finn.benchmark.py
>0.484000 sys.path
>2.210000 System.getProperties()
>1.231000 [].append
>2.069000 [].pop
>1.276000 [].__len__
> Linux: /home/mudd[1]

The fact that the numbers for append and pop are so close together show
that the java.lang.reflect.Method implementation is very fast on this
JVM.

[John fixes an unstable baseline]

>Here we go one more time...
>
>HP HotSpot:
>
>$ /opt/java1.3/bin/java -server -version
>java version "JavaVM-1.3.0.00"
>Java(TM) 2 Runtime Environment, Standard Edition (build
>jinteg:11/28/00-11:08)
>HotSpot VM (build 1.0.1fcs jinteg:11/28/00-13:54 PA2.0, mixed mode)
>$ finn.benchmark.py
>2.173000 sys.path
>13.505000 System.getProperties()
>1.677000 [].append
>11.210000 [].pop
>1.137000 [].__len__
>$

And here the huge difference between append and pop indicate that there
might be room for improving the implementation of Method.invoke().

JPython is very depending on the performance of reflection. It totally
depends on reflection for calling methods in java classes. Barry have
done a lot of work by optimizing most of the often used methods (like
len() and append() above) but there are still some internal & builtin
methods which are using reflection.

I would say that this is reason for the general performance slowness you
have seen on HP.

>HP classic JIT:
>
>$ /opt/java1.3/bin/java -classic -version
>java version "JavaVM-1.3.0.00"
>Java(TM) 2 Runtime Environment, Standard Edition (build
>jinteg:11/28/00-11:08)
>Classic VM (build jinteg:11/28/00-13:54, build jinteg:11/28/00-13:54,
>native threads, HP)
>$ finn.benchmark.py
>6.491000 sys.path
>13.045000 System.getProperties()
>7.310000 [].append
>14.966000 [].pop
>7.868000 [].__len__

Here the difference between append and pop is reduced. This is as I
would expect (but perhaps somewhat more pronounced than I had expected)
because the optimization that avoids using reflection are now executing
more pure java code.

>HP interpretter:
>
>$ /opt/java1.3/bin/java -Xint -version
>java version "JavaVM-1.3.0.00"
>Java(TM) 2 Runtime Environment, Standard Edition (build
>jinteg:11/28/00-11:08)
>HotSpot VM (build 1.0.1fcs jinteg:11/28/00-13:54 PA2.0, interpreted
>mode)
>$ finn.benchmark.py
>10.043000 sys.path
>21.941000 System.getProperties()
>7.364000 [].append
>21.474000 [].pop
>7.250000 [].__len__

Here the reflection calls are going through the roof while the java code
are about the same. I have no explanation for that!

>Hey...  I expected your benchmark to speed up as I transitioned from
>HOTSpot to interpretter like my application does.  The number for your
>benchmark make sense as far as the interpretter being slow compared
>to HotSpot.
>
>But that just makes me more frustrated that my application has the
>opposite result.  Maybe it the threads I have running.  I have maybe
>five threads running in parallel, passing lots of 15 KB octet strings
>back and forth via queues built on dictionaries.

I assume there are some synchronization done by wait() and notifyAll().
IIRC the sync mechanisme is also changed significantly by hotspot. A
benchmark of the time to call synchronized & non-synchronized methods
might show something interesting (or might not). Again it is a
difference between the two that is interesting and a comparison of this
difference when using the clasic jit and hotspot.

Such test would probably have be in pure java. Otherwise the result
might drown in the jpython overhead.

>Also...
>
>Yes, I'm already using both JPython source code and jpythonc jar files.
> No difference that I've noticed.

That's good. Then the bytecode created by the jpython compiler are just
as good and fast as the bytecode created by the javac compiler.

>Yes, I agree that's it's unlikely for HP to make any sort of quick fix.
> For now I'd be happy for some sort of explanation. 

While you have the contact, do not miss the change to tell them that
their Method.invoke() is slower than other jdk1.3 implementations. That
is making their java offering look worse than it actually is when using
script languages.

>I may pursue trying to reproduce the "problem" with HotSpot hurting
>performance by writing a siple script to create some relatively simple
>threads to simulate what the application does. 

Yes. Breaking down the application to pinpointing the performance
characteristics is the only way to go.

regards,
finn