On 22/10/2021 8:21 pm, David Crayford wrote:
I wouldn't consider a drag race using a prime number sieve a good
indication of the overall performance of Java on z/OS. That's a very
specific use case and not one that anybody would ever use on the
mainframe.
That's true, and that's the reason it's referred to as a drag race. A
test of speed at a particular task without much greater meaning.
But I would have expected it to favour C++. Everything is machine code
in the end, so I am sure that you could write faster C++ than Java for
almost anything. But I think it shows that it is wrong to assume Java is
slow, and it is fast enough that choice of algorithms and data
structures have more influence than the language.
IBM also talks a lot about RNI and processor cache... it turns out
garbage collection is good for cache efficiency too. It moves all the
active data into a smaller chunk of memory, which makes better use of
processor cache and is good for your RNI.
That sounds far fetched! Java's stop the world GC cycles are not good
for performance. Java doesn't support reference types so all of it's
data even if it's local is on the heap.
I understand the JIT compiler will use the stack for local objects i.e.
where they cannot escape a limited scope.
New/delete, GETMAIN/FREEMAIN etc. all have overhead. How much? Can you
measure it? GC just moves the overhead to one point where it can be
measured. The pause is a problem for some work, but for e.g. batch it
doesn't matter.
Locality of reference for memory does have a big influence on speed (IBM
even gives numbers for the cache levels) so I would expect compacting
the heap should make the program faster. Potentially much faster,
depending on allocation patterns.
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
