[concurrency-interest] LBQ vs CLBQ

Hanson Char hanson.char at gmail.com
Tue Apr 3 21:30:50 EDT 2007


Hi Trustin,

Actually I think you are right.  According to Jcip, the optimal thread
pool size should be

    NumberOfCpu * TargetCpuUtilization * (1 + W/C)

where W/C is the ratio of wait time to compute time.  Currently W/C is
set to zero and TargetCpuUtilization is set to 1 in the q-test.jar.
However, since the compute time is near zero, the number of threads
for the optimal pool size should be much larger.

I'll add a configurable system property such that the W/C can be
specified for running the test, and see how it goes.

Thanks for pointing this out.

Hanson Char

ps: Hope you don't mind I cc this to the concurrency forum.

On 4/3/07, Hanson Char <hanson.char at gmail.com> wrote:
> Hi Trustin,
>
> The tests suite checks the number of processors available and add 1 to
> it for the number of threads for the producers.  This is the
> recommended approach in Jcip which I just follow.
>
> The test result I've collected so far vary widely depending on whether
> there are real processors vs hyper-threading, and Windows vs Linux,
> and jdk5 vs jdk6.
>
> Hanson
>
> On 4/3/07, Trustin Lee <trustin at gmail.com> wrote:
> > Hi,
> >
> > On 4/4/07, Hanson Char <hanson.char at gmail.com> wrote:
> > > Thanks, Trustin.  In this result, LBQ is 5% faster than CLBQ.
> > >
> > > Is it running jdk1.6.0 ?  Is the "-server" switch on ?  Is it a linux os ?
> >
> > I used JDK 1.6.0 with the switches you suggested.  I guess 5 threads
> > are not enough to get advantage of CLBQ.
> >
> > Trustin
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> > --
> > PGP Key ID: 0x0255ECA6
> >
>


More information about the Concurrency-interest mailing list