[concurrency-interest] j.u.c/backport performance on Windows

Peter Kovacs peter.kovacs.1.0rc at gmail.com
Sun Apr 1 17:00:31 EDT 2007

I haven't tried it, because I got worried about Doug Lea's comment
that it may be less scalable that LinkedBlockingQueue. I will probably
try it anyway.

In more concrete terms: you can find the problematic backport-based
implementation here:
. "outputQueue" is the variable where I am using LinkedBlockingQueue.
And yes, my case falls into the multiple-producer-one-consumer

I am still interested to know (in more general terms): to what extent
can I abstract away from the OS/hardware platform which my solution is
running on?

Which one do I have to be more worried about: differences in the
application logic (e.g. single-consumer vs. multiple consumer) or
differences in the hardware/OS platform?

In fact, this question is more general than j.u.c/backport. My old
database import implementation already takes 50% more time to execute
on Linux than on Windows on the same hardware. (See PS.) Or is it that
the implementation is not "smart enough" to perform equally well on
any platform?

I've seen in jcpip the results of several performance tests run in
Sun's lab. Has anyone done any tests to compare performance on
different platforms? Java is much about platform independence after

Any comment appreciated.


I am having a hard time explaining a significant performance
difference observed between runs of the same Java application on Linux
and on Windows. The application consists of two components: a
concurrent Java producer and a database consumer. The database itself
is about 10% percent slower on Linux than Windows (if the Java
producer is running on another machine). The Java producer routines
perform the same on Windows and on Linux (if the database runs on
another machine). There is a difference of about 40% I cannot explain
when both application components run on the same Linux or Windows
system. My primary suspect currently is the Linux scheduler which
excessively prefers I/O-bound tasks over CPU-bound tasks on serveral
counts: it gives I/O-bound tasks higher dynamic priority and gives
them longer time-slice as well. (The ideology behind this is that
interactive tasks have to be more responsive than non-interactive (ie.
background) tasks. The scheduler considers a process "interactive", if
it is waiting long enough on I/O. There is also some sense of
fairness/compensation behind this policy.) Thus the I/O bound database
process may still be waiting on I/O, while the Java producer has
already consumed its time-slice and is waiting idly in the expired
priority array of the run queue. The upshot being the CPU sitting idly
while there is work to be done. (Conversely, the Windows scheduler
might be smart enough to know that disk I/O is not a sign of
interactivity.) This hypothesis seems to be supported by the fact that
CPU utilization is much lower on Linux than on Windows, but running
the database on a different machine significantly increases CPU
utilization (obviously by the Java producer) on Linux and performance
becomes about the same as on Windows.

A not performance-related observation but belongs here: after
seemingly clean tests on dual processor Intel platforms with Windows,
Linux and HP-UX, I regularly discover new concurrency-related bugs in
my implementation on a single core Opteron with Solaris. And this
reinforces my experience so far: the hardware/OS platform counts a

On 4/1/07, Szabolcs Ferenczi <szabolcs.ferenczi at gmail.com> wrote:
> On 01/04/07, Peter Kovacs <peter.kovacs.1.0rc at gmail.com> wrote:
> ...
> > application. I already reported on March 20 that I observed
> > significant performance degradation compared to an old implementation
> > which makes use exclusively of "primitive" Java language concurrency
> > constructs (http://altair.cs.oswego.edu/mailman/private/concurrency-interest/2007-March/003784.html).
> I am curious whether you have checked the proposal that you have
> received for that mail. (Using the combination of semaphores and
> ConcurrentLinkedQueue.)
> Anyway, some more details would be very interesting in order to say
> anything about your problem. Can you give some hints about the applied
> synchronization constructions in your program?
> Best Regards,
> Szabolcs

More information about the Concurrency-interest mailing list