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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

--- John Mudd <joh...@ya...> wrote:
> Date: Sat, 13 Jan 2001 23:21:02 -0800 (PST)
> From: John Mudd <joh...@ya...>
> Subject: Re: [JPython] HP HotSpot JIT vesus JPython?
> To: Finn Bock <bc...@wo...>
> 
> 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]
> 
> 
> 
> 
> 
> 
> 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
> 1.321000 sys.path
> 11.558000 System.getProperties()
> -0.319000 [].append
> 11.154000 [].pop
> -0.814000 [].__len__
> $
> 
> 
> Hmmm... the baseline value is not stable.  Here's what I get when I
> run
> just the baseline repeatedly using HP's HotSpot:
> 
> 2.66  
> 0.73  <-- OK, now HotSpot is helping on 2nd pass.
> 0.93
> 0.53
> 0.86
> 0.53
> 0.73
> 0.54
> 0.69
> 0.53
> 0.66
> 0.54
> 0.64
> 0.54
> 0.61
> 0.54
> 0.59
> 0.54
> 0.57
> 0.54
> 0.54
> 0.75
> 0.54
> 0.75
> 0.53
> 1.13  <-- Is this normal??  The occasional extra pause w/ HotSpot?
> 0.54
> 0.74
> 0.53
> 0.73
> 0.53
> 0.74
> 0.53
> 0.74
> 0.54
> 0.74
> 0.53
> 0.74
> 0.53
> 0.74
> 0.54
> 0.74
> 0.53
> 0.75
> 0.53
> 0.74
> 0.54
> 1.15   <-- again, another pause.
> 
> 
> 
> The negative numbers are the result of an invalid value for the
> baseline.  I changed your benchmark program to ignore the first
> couple
> of baseline values as follows:
> 
> for i in range(3):
>     baseline = test(f1)
> 
> 
> 
> 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__
> $
> 
> 
> 
> 
> 
> 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__
> $
> 
> 
> 
> 
> 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__
> $
> 
> 
> 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.
> 
> 
> 
> 
> Also...
> 
> Yes, I'm already using both JPython source code and jpythonc jar
> files.
>  No difference that I've noticed.
> 
> 
> 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. 
> 
> 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. 
> 
> 
> 
> 
> 
> --- Finn Bock <bc...@wo...> wrote:
> > [John Mudd]
> > 
> > >I have a large (5,000 line) JPython disk server that's running too
> > slow
> > >on a HP machine using 1.3 Java & HotSpot.  It has several
> > components. 
> > >I benchmark all of the components but, surisingly, when I combine
> > the
> > >whole server the overall performance is only half of the slowest
> > >(bottleneck) component.  It's as if really complex multi-threaded
> > code
> > >is a recipe for trouble on HP in terms of performance.
> > >
> > >For one benchmark that I've selected I can actually double
> > performance
> > >by switching to pure interpreted (-Xint) mode.  If I try that on
> > Sun,
> > >the performance is cut in half (which makes sense).  So... why
> > doesn't
> > >HotSpot help on HP??
> > >
> > >I've used the verbose option to trace GC operations.  That's not
> the
> > >source of the problem.  I'm pretty sure about this.
> > >
> > >On one hand, I'm tempted to say that JPython generated Java code
> is
> > >complicated and/or special in some way as to interfere with
> HotSpot
> > >technology.  If so, that's a shame.  On the other hand, it doesn't
> > >interfere on Sun's version of java.
> > 
> > In itself not surprising, because JimH was using different versions
> > of
> > javasoft JVM's. One naturally uses whatever works and works fast.
> > 
> > The byte code created by the dynamic code generator is of course
> > different from the byte code created by java compilers. If a JIT
> make
> > many assumptions about the ordering or frequency of the byte codes,
> > it
> > may be surprised when it turns out that jpython doesn't fulfill the
> > assumptions. But I don't think that it what is happening here.
> > 
> > If your application is of such a type that it can be compiled with
> > jpythonc, you can use this route to insure that the byte code is
> > created
> > by a traditional java compiler. Generally the overall running time
> > should be close to the same. (jpythonc'ed application may have a
> > slight
> > performance edge because the proxies have been precompiled. For a
> > longer
> > running application the difference should be very small).
> > 
> > Coming up with a guess, I would say the performance difference with
> > calling reflected methods and fields are far more important that
> the
> > actual byte code. A JVM which have optimized the
> > java.lang.reflect.Method implementation will enjoy a huge
> performance
> > gain when used with jpython. That is even more true if the python
> are
> > making direct use of java packages and classes, but it also holds
> for
> > some non-java use of jpython.
> > 
> > >I have HP Java technicians on hand to respond to the situation but
> > I'm
> > >wondering if this is more than they can be held responsible for. 
> Is
> > >JPython beyond the realm of "normal" Java code or should I press
> HP
> > for help?
> > 
> > What ever the reason turns out to be, I somehow doubt that HP can
> do
> > anything on the short term. You can try to do some bench marking to
> > find
> > where it is HP comparably slower that your other JVMs.
> > 
> > Here is a starting point:
> > 
> > from time import time
> > import sys
> > 
> > def test(f):
> >      t1=time();
> >      for i in range(100000):
> >          f()
> >      return time()-t1
> > 
> > def f1():
> >     pass
> > 
> > def f2():
> >     sys.path
> > 
> > from java.lang import System
> > def f3():
> >     System.getProperties()
> > 
> > def f4():
> >     [].append(0)
> > 
> > def f5():
> >     [0].pop()
> > 
> > def f6():
> >     [].__len__()
> > 
> > baseline = test(f1)
> > print "%6f sys.path" % (test(f2) - baseline)
> > print "%6f System.getProperties()" %  (test(f3) - baseline)
> > print "%6f [].append" %  (test(f4) - baseline)
> > print "%6f [].pop" %  (test(f5) - baseline)
> > print "%6f [].__len__" %  (test(f6) - baseline)
> > 
> > 
> > 
> > My numbers are:
> > 
> > 1.042000 sys.path
> > 3.484000 System.getProperties()
> > 0.791000 [].append
> > 4.116000 [].pop
> > 0.721000 [].__len__
> > 
> > The sys.path are using Field reflection. Optimizing the sys.path so
> > it
> > avoid field reflecttion, the number becomes:
> > 
> > 0.070000 sys.path
> > 3.615000 System.getProperties()
> > 0.842000 [].append
> > 4.026000 [].pop
> > 0.711000 [].__len__
> > 
> > The pop() test only works on jython, but it is IMO quite
> interesting
> > as
> > a comparison to append(). The append() is optimized so it does not
> > use
> > reflection, while the jython pop() uses reflection. With an
> > optimization
> > change to jython, so pop() works similar to append(), the numbers
> > are:
> > 
> > 0.071000 sys.path
> > 3.355000 System.getProperties()
> > 0.921000 [].append
> > 1.192000 [].pop
> > 0.902000 [].__len__
> > 
> > Calling through reflection is very expension, even on JDK1.3.
> > 
> > regards,
> > finn
> > 
> > _______________________________________________
> > JPython-Interest maillist  -  JPy...@py...
> > http://www.python.org/mailman/listinfo/jpython-interest
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail. 
> http://personal.mail.yahoo.com/
> 

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/