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

Peter Kovacs peter.kovacs.1.0rc at gmail.com
Mon Apr 2 06:32:18 EDT 2007


Thank you, Hanson, for the clarification! That really makes a
difference. (I didn't realize this part of Doug's comment was based on
a detail [of substance] which has been changed in the mean time.)

I am going to try using ConcurrentLinkedBlockingQueue for sure.

Thanks
Peter

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