Hello Marco (and Ruben & Friends)! On Sun, Mar 8, 2015 at 7:20 AM, Marco Costalba <[email protected]> wrote: > I am one of the developer of a chess engine called Stockfish: > > https://github.com/official-stockfish/Stockfish > > A chess engine is a high performance piece of multi-thread software, where > even a small sub-optimal code path immediately translates in a sensible slow > down. > ... > Recently we started to switch to C++11 for various reasons, but especially > due to library support for std::thread and friends. This allows us to > greatly simplify the code and getting rid of all the platform specific > wrappers. > > While on Linux and on MSVC 2013 we have similar performance between C++11 > and C++03 versions, under Windows with mingw there is a huge performance gap > when run in SMP mode (around 30% slower), when we run in single thread mode > speed is similar. This is particularly unfortunate because our release > version is compiled with gcc for all the platforms because currently gcc > gives the best speed. > > After some analysis we realized the speed difference is all due to thread > library implementation on mingw that is based on POSIX instead of native > Win32 threads. > ... > So I would like to ask: > > 1. There exists somewhere a mingw-w64 build supporting native win32 > std::thread? > > 2. There is some plan to develop it?
I can give you some historical background. Please note, this is now several years out of date. Here is a thread on some experimental work I did on a semi-native std::thread implementation: http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/2091 Here is some (out-of-date and unrealistic) timing information: http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/3550 Note that in these timings (unrealistic use cases), mutex contention was much, much worse in the winpthreads implementation than in the semi-native implementation, while condition variables were significantly better. (This appears consistent with the mutex slowdown you noticed.) Here is a stackoverflow thread touching on some of the same issues: http://stackoverflow.com/questions/19250008/mingw-stdthread-with-windows-api Historically, I think the following considerations entered into mingw-w64's choices for implementing std::thread: 1) Support for pre-Vista rules out using windows CONDITION_VARIABLES. 2) Although not part of standard C++ (nor C), and not part of windows, pthreads is the posix standard, and therefore important to support. It therefore makes sense to build std::thread on top of pthreads (avoiding duplicative effort and easing mixing of pthreads code with std::thread code), although this is not a firm requirement. 3) Licensing concerns and the the fact that an integral value is the de facto standard (but not part of the posix requirement) for a pthreads handle led to the development of winpthreads. One would expect to be able to make std::thread faster by dropping support for older versions of windows and by not basing std::thread on winpthreads, but it seems like either of these two changes would be giving up too much. On the other hand (but I can't speak for the mingw-w64 team), I would think that suggestions for improvements in winpthreads -- that would then lead to greater std::thread efficiency -- would be very welcome here. > Thanks for your help and support > > Marco Happy Multi-Threaded Hacking! K. Frank ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
