On Tue, Oct 21, 2014 at 12:31 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
The only way for a JVM to fully utilize a multi-core system
is to run multiple JVM / application server instances, and to deploy your
applications across each instance.
This isn't true in general. If this is true for JVM on IBM i, then
that is an IBM-specific thing, not a Java-specific thing.
IBM schentist Ronald Luijten commented in the September 2014
issue of IBM Systems Magazine, "We also have the multi-core
programming wall. All of our computer science students learn
how to program in Java, which doesn't support multi-cores at all.
Intel may put 128 cores on a chip, but people coming out of
universities are only going to use one of them."
I'm not sure if he was quoted out of context, or if he was talking
about Java only on the i. (And I'm still not convinced that it's even
a limitation for Java on the i.) But you sure as hell can use
multiple cores in Java:
http://embarcaderos.net/2011/01/23/parallel-processing-and-multi-core-utilization-with-java/
Note the above link is from 2011. It demonstrates how to utilize
multiple cores on a Windows PC using Java.
The quote about "people coming out of universities are only going to
use one of [the available cores]" I think is mostly true, but not
because of any limitation of Java. It's because multithreading and
multiprocessing are relatively difficult concepts, intrinsically, and
not everyone is going to pick these up in school. Not every school is
going to even bother teaching them, because there is actually a lot of
very useful, productive programming you can do without it.
There are currently quite few languages that make it easy to write
programs which explicitly utilize multiple cores (though this number
is increasing). Java is at least average in this regard, and probably
above average. The holy grail of multicore programming is to get to a
point where compilers, CPUs, and the operating system handle all of
that for us, and we just program the way we traditionally have for
single-processor systems.
For "big" systems, like IBM midrange, I think the idea is still the
same as it always has been: The server is designed to serve multiple
users and multiple processes, and the way to increase utilization is
to serve enough users and enough "single-processor" processes that the
system is taxed (without being overtaxed).
All of which is to say that I agree with the final conclusion, which
is to keep using RPG on the i wherever practical, because RPG is very
well optimized to run on the i.
John Y.
midrange.com
