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

Hanson Char hanson.char at gmail.com
Sun Apr 1 17:31:31 EDT 2007

Hi Peter,

> 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.

I don't think Doug ever commented that the proposed
ConcurrentLinkedBlockingQueue is any less scalable than the existing
LinkedBlockingQueue.  I would think the opposite is true.

Or did I miss out his comment ?

Hanson Char

On 4/1/07, Peter Kovacs <peter.kovacs.1.0rc at gmail.com> wrote:
> 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:
> http://www.chemaxon.com/shared/pkovacs/concurrent/processors/InputOrderedWorkUnitProcessor.java
> . "outputQueue" is the variable where I am using LinkedBlockingQueue.
> And yes, my case falls into the multiple-producer-one-consumer
> category.
> 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
> all.
> Any comment appreciated.
> Peter
> PS:
> 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
> lot.
> 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
> >
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list