std.benchmark is in reviewable state

Robert Jacques sandford at jhu.edu
Mon Sep 26 08:14:20 PDT 2011


On Mon, 26 Sep 2011 09:56:27 -0400, Jens Mueller <jens.k.mueller at gmx.de> wrote:

> Andrei Alexandrescu wrote:
>> On 9/25/11 11:56 PM, Robert Jacques wrote:
>> >On Sun, 25 Sep 2011 23:06:01 -0400, Andrei Alexandrescu
>> ><SeeWebsiteForEmail at erdani.org> wrote:
>> >>>So, std.benchmark should
>> >>>[ ] Set the affinity to a single thread at start (i.e. use
>> >>>SetProcessAffinityMask, etc)
>> >>
>> >>I think that won't influence most measurements measurably.
>> >
>> >First, a core jump is guaranteed to, essentially, poison the cache.
>> >Which, at least in my eyes, invalidates that particular timing run.
>>
>> Well it will be one of many runs. The questions are if (a) core
>> jumps are likely to happen during a benchmark run, (b) many enough
>> will happen to influence a 500ms time window.
>
> 500?
> To me it looks as if the time window is 10ms long (line 447)?
>
> Jens

The minimum, automatic time window is 10 ms. Given the scaling factor, the actual time window will be between 10 ms and 100 ms. IIRC A context switch occurs every 15 ms or less. And given that you'd be starting the time window at a random point inside the active time slice, at the minimum (i.e. 10 ms time window) you have a 66% chance of a switch happening.


More information about the Digitalmars-d mailing list