Hello List!
I have run some timings on a couple of my std::thread test programs
using the following three std::thread implementations:
native windows implementation, mingw-w64 4.5.2, a sezero build
pthreads-win32 implementation, mingw-w64 4.5.2, a sezero build
winpthreads implementation, mingw-w64 4.7.0, Ruben's std::thread build
I list the timings, in seconds, in the above order (native, pthreads-win32,
winpthreads):
Test "c2" (parallel accumulate):
15.40 (0.09) 15.43 (0.05) 18.79 (0.07)
Test "d" (mutex contention):
2.12 (0.02) 2.62 (0.08) 40.41 (0.06)
Test "e" (condition variables):
3.18 (0.04) 3.31 (0.10) 0.74 (0.04)
The numbers in parentheses are the estimated errors ("standard error")
of the measured times. (Each timing test was run ten times. The
reported timing is the average of the ten runs, and the standard error
is one third of the standard deviation of the ten runs.)
Some comments on the timings:
First, the timings are wall-clock timings (i.e., elapsed times, not cpu-usage
times). They are timings for running the entire test program, not just the
thread-specific parts.
The timings are not entirely apples-to-apples comparisons: The first two
implementations (native and pthreads-win32) use the same compiler (and
standard libraries) and std::thread library code -- i.e., that from sezero
4.5.2 build. But the third (winpthreads) uses a different compiler (and
libraries) and std::thread library -- Ruben's 4.7.0 build. So the compiler
may be doing things differently, or there may have been changes in the
std::thread code that changes the timings. So, presumably, the differences
in the native and pthreads-win32 timings are, in fact, due to the low-level
threading implementation (i.e., native vs. pthreads-win32), but the differences
shown by the winpthreads timings may or may not be due to the winpthreads
implementation, because the compiler and std::thread code may also have
changed in ways that matter for the timings.
I ran the tests on a 2-core, 1.6 GHz, 64-bit machine (and the test programs
are compiled as 64-bit executables). The os is 64-bit windows 7. When
the machine is "not doing anything," cpu usage runs from about 8% to
20%, averaging about maybe 12%. (This is from the windows task manager.
100% usage means that both cpu cores are saturated.)
The most noteworthy timing difference -- the winpthreads time for test "d"
(mutex contention) -- had the following feature: The native and pthreads-win32
test programs pretty much saturated the cpu's -- essentially 100%. But the
winpthreads test program ran ranging from only about 35% to 45% cpu usage.
(I don't have any thoughts on why this might be.)
In test "e" (condition variables), one thread runs in a loop that acquires
the mutex used by the condition variable, updates some variables, and
notifies the condition variable (cv.notify_one()). In both the native and
pthreads-win32 implementations, that thread frequently reacquires the
mutex perhaps 99 time out of 100, rather than having one (of the twenty)
threads waiting on the condition variable acquire the mutex. But in the
winpthreads implementation, the notifying thread reacquires the mutex
after notifying the condition variable only about one time in ten. (I don't
know what to make of this, or have any speculation on what the cause
might be, but from a practical perspective, the winpthreads behavior
seems to be much more what one would want.)
Best.
K. Frank
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
