Hi Etienne!
On Mon, Jun 30, 2014 at 4:09 AM, Etienne Sandré-Chardonnal
Post by Etienne Sandré-ChardonnalPost by K. Frank...
It's not entirely clear to me what your problem is. (In your original
question
you asked whether you could detect pthreads vs. win32 threads with the
preprocessor at compile time.)
Why not use g++ / pthreads on linux, and mingw-w64's g++ / winpthreads
on windows and just use pthreads for your threading code? I would expect
(expect, but don't know for certain) that the Qt's QThreads end up getting
mapped to native pthreads on linux and to win32 threads on windows. But
unless you try to synchronize your own "user" pthreads with QThreads, I
think you should be able to use both pthreads and QThreads in the same
application both on linux and windows.
Could you sketch out the precise use case that you're concerned about?
I will probably do that (or even use std::thread).
The concern I had were about these posts & articles stating that mingw-w64
posix threads have a significant lower performance than win32 threads. As
I'm writing a monte-carlo integration, which is running on clusters, and for
which 5% perf drop is a money loss, I was thinking of writing a win32-thread
specific code and use the win32 only mingw-w64 build for that. Hence the
preprocessor question.
I would recommend that you use std::thread (assuming that you can
use c++11). I have used std::thread in a Qt application without any
problem. (I should note that it was a small, experimental application,
so it was never really stress-tested, and it did not use QThreads.)
In terms of performance, I would make the following comments:
I would imagine that your Monte Carlo integration parallelizes quite nicely.
Once you get your calculation threads spawned and running, there should
not be any performance difference between pthreads and win32 threads (or
std::threads and QThreads for that matter). You would only expect to see
possible performance differences when spawning the threads or synchronizing
them (e.g., waiting on a mutex or condition variable). Given that I believe
that all the different brands of threads end up being implemented in terms
of the "native" OS threads (pthreads on linux and win32 threads on windows),
I would not even expect to see any performance difference when context
switching the threads.
In your use case I imagine that you spawn a handful of calculation threads
(one for each core in the cluster?), let them calculate for a long time, and
then synchronize the threads so that you can collect the partial results
together. So in my imagination, the calculation dominates, and the cost
of spawning and synchronizing the threads doesn't really matter. So the
relative performance of spawning and synchronizing the threads also
doesn't matter.
Second, I played around with implementing std::thread for mingw-w64 in
terms of both win32 threads and pthreads (as implemented in mingw-w64's
winpthreads library). For some things the win32 threads were faster (I think
spawning), and for some things the pthreads were faster (I think, if I remember
correctly, mutex contention).
So even if the performance of spawning / synchronization does matter to
you, I don't think that it goes without saying that win32 threads would be
faster for your use case. If you really care, you would want to benchmark.
(One last comment: If you do use win32 threads, you should not use
win32 mutexes. These are heavy, expensive, interprocess synchronization
structures. You should use instead win32 critical sections which are much
lighter weight -- intraprocess only -- unless, of course, you need to
synchronize
processes, not just multiple threads within a single process.)
Good luck.
K. Frank