slow java on Itanium 1.6GHz in SuperDome 9000?

[Everhard Faas]

Compare the results of a benchmark scimark2.

My 3 GHz AMD desktop: 600
vPar on Itanium 2 with HP-UX 11i v2 and java 1.5.0.06: 139

Can anyone explain the difference?

[Duncan Edmonstone]

Yes.

A 3GHz AMD desktop if a different computer from a HP-UX vPar.

Why would you expect them to be in any way similar?

I don't know this benchmark (and looking at the siteb it comes from it doesn't look like its been maintained in quite some time), but I'd point you at a couple of items on the FAQ for it here:

http://math.nist.gov/scimark2/faq.html

Why is my system so slow?
Most often, the underlying Java environment does not have a JIT (Just-In-Time) compiler. Make sure you have a recent version of the browser or Java envrironment in which SciMark is being run.

Currently, PCs have some of the better execution environments (and hence most of the high scores) but various projects are developing even better JITs/compilers for Java.


Are the SciMark kernels multithreaded?
No. SciMark 2.0 focuses on single-processor performance. Multithreaded kernels may be included in future versions.

So its a single threaded test - in that situation its not uncommon for a higher GHz CPU to be faster. Might be different if you ran 10 of these at the same time...

You might also want to look at using jconfig:

http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPJCONFIG

and jmeter:

http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPJMETER

to help tune your performance on HP-UX

What (if anything) are you actually trying to determine here?

HTH

Duncan

[Steven E. Protter]

Shalom,

Your comparison is not very meaningful.

The Java compile for HP-UX is different, and its likely your desktop isn't running a bunch of virtual machines (vpar).

If you must compare, whats the memory in the vpar, how many processors does it have?

I would suggest:
1) Updating the java to the latest version which I think is update 12.
2) Checking the system has recommended OS patches for Java
3) Checking the vpar systems general patch state with the most recent bi-annual patch set being to focus.

SEP

[Dennis Handly]

>SEP: its likely your desktop isn't running a bunch of virtual machines (vpar).

HPVM isn't the same as VPAR. In fact, I don't think you can run HPVM on VPARs yet.

[Everhard Faas]

> Why would you expect them to be in any way similar?
Our new application is doing 99% of the time xml-parsing. The number of messages per second is too low on our Superdome, compared to the development environment on a simple laptop...
The current programmer told me that xml-parsing is done by a very efficient 'Woodstox' parser.

The application is not (yet) capable of doing things in parallel; the messages should be processed in sequence...

Besides the application, the vPar is idle. vPars are not sharing hardware resources. The target platform has 2 cores and 16GB.

I will check the benchmark with a newer java version and OS patches for java.

> What (if anything) are you actually trying to determine here?
Check if the performance difference between the development- and target platform is because of the application software or the platform itself. So I tried a benchmark. Good idea?

Thanks for the links for extra help!

Regards,
Everhard Faas

[Steven E. Protter]

Dennis, again, parsing my posts.

He said vpar. Re-read my statement and try and understand it prior to a reflexive inaccurate parse.

Everhard,

To your new questions:

>>>>
> Why would you expect them to be in any way similar?
>>>>
OS is so very different. Apples to peanuts comparison. One sweet, one salty.



Our new application is doing 99% of the time xml-parsing. The number of messages per second is too low on our Superdome, compared to the development environment on a simple laptop...
The current programmer told me that xml-parsing is done by a very efficient 'Woodstox' parser.

The application is not (yet) capable of doing things in parallel; the messages should be processed in sequence...
>>>>
Besides the application, the vPar is idle. vPars are not sharing hardware resources. The target platform has 2 cores and 16GB.
>>>>>>
Normal. Applications and I/O if any use the majority of resources on many computer systems.

16 GB and two cores tells me its a Java patching or bug issue. Update 12 is out there for Java 1.5


>>>>>
I will check the benchmark with a newer java version and OS patches for java.
>>>>>
A real benchmark would be helpful here. I agree with this suggestion.

>>>>
> What (if anything) are you actually trying to determine here?
Check if the performance difference between the development- and target platform is because of the application software or the platform itself. So I tried a benchmark. Good idea?
>>>>>

Development and production should be the same OS. Maybe not the same memory and CPU but the same OS. As a development and test environment the AMD system is invalid and potentially dangerous.

SEP

[Duncan Edmonstone]

If the application has to do everything in serial (i.e. single threaded), and you can only run one instance of it - you may as well run it on a fast (i.e. high GHz) single processor system rather than on HP-UX. To take advantage of HPUX you need to either be running multiple copies of your app or have the app multi-threaded.

People look at big iron (like Superdomes) and think 'that will run my code fast', when really what they should be thinking is 'that will run a lot of my code'. It's a throughput vs. latency thing... the analogy I like to use is a single track road vs. a multi-lane highway. A single car might get somewhere just as fast (or even faster) on a single track road if its the only car on the road - however once there are other cars on the road, the highway will always be faster.

HTH

Duncan

[Dennis Handly]

>SEP: He said vpar.

Exactly. You said "virtual machine" and seemed to try to equivalence or create an analogy with VPAR. This is not a good comparison for Integrity since one is software and the other hardware.
Nor I suppose for AMD. I would suggest a better statement would be multiple cores.

>Re-read my statement and try and understand it prior to a reflexive inaccurate parse.

You didn't add any new info, so I would still be confused.
Basically my objection is that a virtual machine isn't the same as a virtual partition.