Boost logo

Boost :

Subject: Re: [boost] [Boost.Interprocess] conditions variables get 10 times faster when opening a multiprocess browser
From: Gav Wood (boost_at_[hidden])
Date: 2013-08-21 07:14:22


The default 'blind' prior is a simple exponential expectation whereby
we assume for any given duration of waiting 't', that the expected
completion time is 2t; i.e. we expect to wait as long as we have
already been waiting. As such, the optimum time to start with the
'sleep(1)' strategy (which from my tests sleeps for a full 20ms
timeslice) is after 20ms, (only after which point the prior leads us
to assert that the completion will probably take at least another
20ms).

In my patch, I found the 20ms 'optimum' value to be considerably
higher than 1000, and that was on hardware circa 2010.

Gav.

On 21 August 2013 08:07, Ion Gaztañaga <igaztanaga_at_[hidden]> wrote:
> El 21/08/2013 7:39, Marcello Pietrobon escribió:
>
>> Thank you for the last fix Ion.
>>
>> I've run some tests on it and it has improved the performance, but not
>> completely.
>>
>> Clearly this problem is not limited to your interprocess library so I
>> thought to open a different thread discussion for it:
>>
>> http://boost.2283326.n4.nabble.com/Problems-with-yield-k-workaround-Still-too-slow-td4650929.html
>>
>> I've done some profiling plus some tests and so it's clear to me that the
>> test program is still slowed down around the ::sleep(1) instruction.
>>
>> I am personally content with replacing the value 32 with a value above
>> 1000,
>> so the resolution to this is not urgent for me (just to take some pressure
>> of you ;)).
>
>
> Thanks for the test. It's definitely hard to tell if 1000 will be OK for
> everyone, as it might depend on the CPU speed or waiter count (in your
> example there is a lot of waiting between the same two processes, which is
> not same use case as hundreds of threads waiting for a single resource).
>
> There is a *very experimental* support for native synchronization primitives
> on windows if you comment the line:
>
> #define BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION
>
> on boost/interprocess/detail/workaround.hpp
>
> It tries to create Windows native named semaphores on the fly with a unique
> name and implements Alexander Terekhov's 8a algorithm to implement a
> condition variable. I don't know if it could be faster on your application,
> but it should use less CPU as it does not use busy waiting.
>
> Best,
>
> Ion
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk