On 22/10/2021 3:51 pm, Andrew Rowley wrote:
On 22/10/2021 2:46 am, A T & T Management wrote:
Java, it has to be translated each time it run, provided you know
the language and it's been debugged. Schools may teach it but they
too want to make money and look good because they can say it's modern
and that is what they push. Any CEO or executive who doesn't look at
the total cost is doomed to fail.
Don't write off Java too quickly. I previously posted about Software
Drag Racing, which was a competition to test the speed of different
languages.
In the initial test on z/OS, Java was over 3 1/2 times faster than
C++. With some tweaking, C++ ran as fast as Java, but not
significantly faster.
The results are written up here:
https://www.blackhillsoftware.com/news/2021/08/10/java-vs-c-drag-racing-on-z-os/
Disclaimer. I've been writing 90% of my code in the last couple of years
using Java. I really like it and having a language specification with no
undefined behavior is awesome. It's also brilliant for multi-threaded
code and the open source frameworks and libraries are endless. Having
said that, 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. I've been playing around with IBMs new port of golang and in
lots of benchmarks it beats the JVM as does C++. Our machines all run
full-capacity so Java has a huge advantage for sub-capacity customers.
If you have a zIIP and your general purpose CPs are not full speed,
Java might be the fastest language on your system by a big margin...
and it doesn't count against general purpose CP usage.
+1M
Java will compile to machine code where it makes a difference to
performance. Just in Time compilation has some performance advantages:
- it can optimize for the exact hardware
- it can leave out infrequently used code paths and compile them later
if they are actually required, making the machine code smaller and
more efficient
- it can monitor the code execution and recompile the hottest parts
with extra optimizations
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.
If you have well defined, well understood programs that are big CPU
users, it certainly could be worth rewriting them in Java.
(Knowing the language and debugging programs applies to any
language... and I'm not denying you can write large programs and
inefficient code in Java as much as in any other language.)
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
