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

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


I think Doug's comment's on reduced scalability is when I first
proposed the use of a semaphore+LinkedBlockingQueue many months ago.

The current version of ConcurrentLinkedBlockingQueue, however, is NOT
using any semaphore and is in fact totally lock-free.

Cheers,
Hanson Char

On 4/1/07, Hanson Char <hanson.char at gmail.com> wrote:
> 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