Re: [boost] [Boost.Interprocess] Chronic performance on Win7

Subject: Re: [boost] [Boost.Interprocess] Chronic performance on Win7
From: Gav Wood (boost_at_[hidden])
Date: 2011-08-20 05:53:47

Hi again,

I've done some graphs for your perusal. The reason an adaptive
strategy (such as that which I already proffered) must be used is
quite simple: there's no way of knowing, in advance, how long a thread
must send itself to sleep for.

Windows provides only two choices for yielding:
  Return immediately if nothing else is to be done (Sleep(0)/SwitchToThread()).
  Return in 20ms, even if another process was scheduled, ran, and
potentially freed us in the meantime (Sleep(1)).

For forced-process-switches of frequency >> 20ms, the second
(Sleep(1)) is an acceptable yield strategy; made ever-so-slightly
better by checking first whether another process can be scheduled in
the meantime and early exiting if so (ala Check strategy). It works
effectively when there are fewer cores than processes which can work.

Unfortunately, this becomes far from optimal for
forced-process-switches of frequency < 20ms, especially when the
number of cores becomes >= the number of processes that can work. This
is because a process, having determined that it cannot continue, must
decide how to yield. Assuming it's symbiotic counterpart is running on
a different core and that no other work needs to be done on the
system, Sleep(0) will return immediately and SwitchToThread will
return immediately stating that no other processes could be scheduled.
Sleep(1) will return only after 20ms. Assuming the symbiotic
counterpart completes after, say, 200us, then the slowdown factor will
be around 99% for any strategy that involves Sleep(1); therefore such
a call needs to be made only once it is probable that the symbiotic
counterpart will complete after another 20ms. My proposal attempts to
implement such a strategy.

As well as the attached graph, I attached the numbers from my
benchmarking. The job was an iterative summation of random numbers.
The benchmarking code is attached. These numbers are not extremely
precise as I wasn't in a pristine environment, but they serve to
illustrate.

Gav

2011/8/20 Ion Gaztañaga <igaztanaga_at_[hidden]>:
> El 20/08/2011 1:39, Ion Gaztañaga escribió:
>
>> Gav Wood (thanks!) has proposed
>
> Obviously, I wanted to write Mathias!
>
> Best,
>
> ion
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>