SwitchToThread vs Sleep(0)

[qWord]

Results look pretty stable now

Probably you have happily ignore the literature I've referenced, but your method is only stable as long as no one change the timer resolution. Also the values vary tremendously from the theoretical values (assuming no CPU throttling applies). The attached testbed shows the influence of the current timer resolution on the slice/quantum length. Remarks that you will only see a different, if no other application has already requested a timer resolution of 1ms (default values for the resolution are 10 or 15ms).

Code: [Select]

actual timer resolution : 0.01s , CPU frequency: 2294 MHz
clocks/quantum: 7.64667E+006
Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz (SSE4)
9       valid tests, 90789      avg kCycles
9       valid tests, 91772      avg kCycles
9       valid tests, 91738      avg kCycles
9       valid tests, 91776      avg kCycles
9       valid tests, 91796      avg kCycles
9       valid tests, 91827      avg kCycles
9       valid tests, 91797      avg kCycles
10      valid tests, 91540      avg kCycles
9       valid tests, 91812      avg kCycles
10      valid tests, 91622      avg kCycles

set timer resolution to 1ms
actual timer resolution : 0.001s , CPU frequency: 2294 MHz
clocks/quantum: 764667
Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz (SSE4)
9       valid tests, 73421      avg kCycles
9       valid tests, 73454      avg kCycles
9       valid tests, 73433      avg kCycles
9       valid tests, 73450      avg kCycles
9       valid tests, 73420      avg kCycles
9       valid tests, 73473      avg kCycles
9       valid tests, 73437      avg kCycles
10      valid tests, 73413      avg kCycles
10      valid tests, 73359      avg kCycles
10      valid tests, 73324      avg kCycles
ok
qWord

[jj2007]

Results look pretty stable now

Probably you have happily ignore the literature I've referenced

My apologies.

but your method is only stable as long as no one change the timer resolution

So I would suggest not to change the timer resolution in the middle of a timing exercise. The goal of this thread is to determine how many test loops can be squeezed into one time slice, in order to get a) high loop counts but b) no (or very few) context switches that could influence the precision of the cycle count.

[qWord]

The goal of this thread is to determine how many test loops can be squeezed into one time slice, in order to get a) high loop counts but b) no (or very few) context switches that could influence the precision of the cycle count.

Sorry that I've waste you time.

[jj2007]

Sorry that I've waste you time.

In general, I read your posts carefully as you are a very knowledgeable person. I can learn from you.