Re: JVM CPU queueing

On Tue, Oct 21, 2014 at 6:21 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Thanks for the reference, John. And I agree that Java can run pools of
parallel tasks via the "Callable" interface and "consume" CPU on multiple
cores. But it appears that even your reference illustrates the futility of
that interface.

In the example cited:

A "Task" appends a character to a string in a loop 20K times order to
consume CPU. When running a pool of 50 tasks sequentially each instance
completes in an elapsed time of 1.27 seconds which includes 1 second of
"sleep" time. When run in parallel, each instance of the pool completes in
approximately 11 seconds.

Why would a programmer consciously "throttle" tasks which ordinarily
require essentially .27 seconds of CPU time and make them take longer
(effectively 40+ times longer) to complete, just to prove a point about
Java's ability to allocate work to multiple cores?

I'm not clear what you are referring to as "throttling". The 1-second
delay is a deliberate artifice to simulate a remote call. Basically,
in the real world, few applications are anywhere near 100% pure CPU.
They have to wait for I/O, they have to wait for other resources to
become available, etc. He was just trying to make the example more
realistic.

I don't know what the "effectively 40+ times longer" is supposed to
mean. Where do you get that from? 11 seconds is about 40+ times
longer than .27 seconds, but I believe he's saying that running all 50
tasks in parallel took a total of 11 seconds. Running them serially
took about 65 seconds. So using 8 cores produced a speed-up of a
little less than 6 times over using a single core.

In the example cited, it took a pool of 50 Callable (submitted) Tasks to
drive 8-cores to 100% utilization. Why couldn't Java drive 8 cores to 100%
with a pool of just 8 Callable Tasks?

It absolutely could. He spent some of the article talking about how
the exact nature of the tasks affects how you'll want to configure
your pools. At the extreme of a completely CPU-bound, perfectly
8-way-parallelizable application, 8 threads for 8 cores would indeed
be the way to go.

Should application programmers take responsibility for allocating work to
multi-core servers? Isn't that the responsibility of the OS?

The traditional way has been for the OS to do all the allocation.
It's still the most efficient if all you have on the system are
single-threaded batch jobs. Giving the application programmer the
ability to do work allocation is for flexibility and finer control
over resources. In principle, the application programmer knows what
parts of the application can run in parallel, what parts need to wait
for other parts, etc.; things which would be difficult or impossible
for the OS to know without the programmer telling it.

Regarding Ronald Luijten's comment about Java not supporting multi-cores at
all, no that didn't have anything to do with IBM i. It was just an
observation about Java.

Then his observation was just plain wrong.

I understand that the total elapsed time to complete 50 Task instances is
greater when run sequentially, than in parallel (submitted). But how might
that apply to the question at hand, in Tim's original post?

I don't know. I really latched onto what I found were
misunderstandings of the capabilities of Java, and wanted to correct
them.

I don't know exactly what "CPU queuing" means, in the OP's context.

All benchmarks of Java web workloads indicate that you must run multiple
application server instances to fully utilize multiple cores. The ratio is
pretty much one to one, even though the application server may be
configured with say 100 active threads.

I don't doubt this, but I also don't see the relevance to CPU queuing.
(Again, maybe I would if I knew what it was.)

John Y.