On 23/10/2021 6:52 am, Andrew Rowley wrote:
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.
When I ran the drag race on our full capacity enterprise class machine
Java was always faster than C++ and the GCPs run at the same speed as
the zIIPs. And Python also beat C++ and I couldn't get my head around
the veracity of that result.
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?
z/OS OMEGAMON for JVM is one of our products and provides nice insights
into the JVM. The application I'm working on is a Spring Boot server and
we use Prometheus/Grafana to monitor it
https://grafana.com/grafana/dashboards/10280. The Java heap hierarchy is
quite complicated as you would expect to optimize GC.
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.
GC on our z15 is performed using pause-less GC hardware assist. I've
have never seen a "stop-the-world" cycle over a couple of microseconds
in the Grafana dashboard. I agree with you about Java's excellent
performance on z/OS. It's a fast horse that needs a couple of laps to
warm up. I also notice that new release of COBOL
have significantly improved the interop with Java which is a great way
to modernize the legacy code. For example, to send a record to a Kafka
topic etc.
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.
The brainiacs at IBM have just invented some revolutionary new cache
tech for the new z16 chip. It's great to see IBM back to what they do
best, top notch R&D. https://www.youtube.com/watch?v=z6u_oNIXFuU.
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
