Basically, the title explains it all; I'm looking to make a game in C++ and I want to use multithreading for stuff like the physics engine and keeping the animation smooth on the loading screen. I've seen a few multithreading libraries, but I'm wondering which is best for my application, which will work well on Windows Mac and Linux. Does such a library exist?
You probably want boost::thread or Intels' Thread Building Blocks. I'd recommend TBB but it's not free, I think, so boost::thread for the free option.
If you can use c++0x threads, then use that.
If not, boost::thread is the best free multi-platform library.
My favourite is QThread. Part of Qt library.
Currently my recommendation would be OpenMP (libgomp on g++, IBM XlC++, MSVC++ all support it)
OpenMP offers a simple way of exploiting parallelism without interfering with algorithm design; an OpenMP program compiles and operates correctly in both parallel and serial execution environments. Using OpenMP's directive-based parallelism also simplifies the act of converting existing serial code to efficient parallel code.
See msdn
And GOMP
for starting points
Random quote:
To remain relevant, free software development tools must support emerging technologies. By implementing OpenMP, GOMP provides a simplified syntax tools for creating software targeted at parallel architectures. OpenMP's platform-neutral syntax meshes well with the portability goals of GCC and other GNU projects
Another nice library that includes cross platform threads is poco
Related
I am a beginner of c++ parallel computing. However, my project requires that I would need to use c++98 (stdlibc++) for it. I search online and it seems most of the tutorials is based on c++11 thread. I noted that boost_thread is an implementation for c++98 but there seems to be much less available tutorial. So I would like to ask what is the best way for me to learn and implement parallel computing for my project.
Eventually, my project would require calculations based on hundreds of cores and computing nodes. Would multi-threading be sufficient or do I have to use Boost_MPI? Thank you.
If you are limited to c++98 that means that you won't have all the thread managing and locking mechanisms as part of the language.
Therefore you will have to implement them by yourself based on available OS APIs.
There are different APIs for Windows and Linux.
Here is an example of C++ wrapper for Linux pthread library.
And this is an example of C++ wrapper for Windows Threads.
So your project won't be portable unless you create (or find somewhere) a class which hides these libraries behind a common interface under which it implements the same logic for Windows and Linux differed by #ifdef WINDOWS / #ifdef LINUX.
Regarding
what is the best way for me to learn and implement parallel computing
for my project.
There is no a correct answer for this. Look for some basic Multi Threading tutorials. Try to implement few simple programs (before you move to a big project) and come back when you face difficulties with more specific questions.
I have heard about boost but never used it so I can't provide any feedback on that. But again, you need to ask specific question. You can provide some specific requirements from your project and ask question based on them.
Anyway dive into boost documentation, you can find there threads related libraries (also pay attention for boost usage license).
I would like to parallelize a Qt/C++ program with OpenMP, so I can compare against Qt threading tools. I have some questions.
What do I have to include, both in code and in project files to have OpenMP working properly?
Would it be painful to use OpenMP in a deliverable software project? Should each versions include updates for OpenMP and much maintenance?
What do you experienced as performance with OpenMP?
Is nested parallel work with OpenMP trustworthy?
Is OpenMP supported on the same platforms as Qt?
Any references would be appreciated. Thanks a lot!
What do I have to include, both in code and in project files to have OpenMP working properly?
You'll have to introduce OpenMP pragmas in the code, and possibly to link against the OpenMP runtime library (which will introduce limited changes in your build system).
Would it be painful to use OpenMP in a deliverable software project? Should each versions include updates for OpenMP and much maintenance?
I'm not sure what you mean by "painful". I know a lot of projects successfully using OpenMP. There might be some maintenance needed from time to time (but I guess this is also true for Qt).
What do you experienced as performance with OpenMP?
More or less what should be expected of any good thread-based parallelization tool. If the workload is sufficiently heavy, OpenMP in itself should not add much overhead to your code and Amdahl's law will be your limit.
Is nested parallel work with OpenMP trustworthy?
Yes
Is OpenMP supported on the same platforms as Qt?
Unlike Qt, which is a framework, OpenMP support is mostly done by compilers. You might find platforms on which Qt is compilable, but where the C++ compilers don't support OpenMP. Of course, it depends on what type of platforms you target.
In my previous question I've asked, I touched the parallel_for subject from ppl.h provided by Microsoft.
But shortly after I've realized that by using it one makes his application unportable (if I'm right it is specific to Microsoft (the ppl.h header)).
In my opinion this breaks very important aspect of programming in C++ - portability, and I'm just not prepare to do it.
So my questions are:
1. Am I right in saying that using parallel_for from ppl makes your code unportable (by unportable I mean that it cannot be compiled by other compiler than the one from MS)
2. Am I right in saying that if on later stage I want to provide UI (done in Qt) for the application I'm working on at the momment, using parallel_for in my code will be an obstruction which would mean that either I'll replace parallel_for with some other (portable) alternative or I won't be able to do UI in Qt and core in VS?
3. What are the (portable) alternatives to ppl?
You may want to consider Intel's Thread Building Blocks. Unlike OpenMP, TBB actually uses C++, rather than simply compiling under a C++ compiler (ie: being a C library that can compile as C++). It has many of the things you see in PPL, but it is cross-platform.
There is also Boost.Thread, which is C++ (though not quite as direct as TBB is), and it is cross-platform.
The people working on the Casablanca project have been making a portable version of PPL, called PPLX. It's licensed under an Apache 2.0 license.
They previously have said they are working closely together with the PPL team to keep both versions in sync feature and bugfix wise (see last post in this thread).
Whether you use PPL or TBB (or HPX) ... something very similar is going to be standardised. For instance see: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4411.pdf
Am I right in saying that using
parallel_for from ppl makes your code
unportable (by unportable I mean that
it cannot be compiled by other
compiler than the one from MS)
Unportable if you switch the platform itself. May be portable on Windows, if you want to use other compilers. But know that PPL is part of Concurrency Runtime, which is placed in MSVCRT100.DLL, and you need to link to this (or statically link, without needing DLL at runtime). I am not sure how this can be done with other compilers/linkers, but I do believe it is doable.
Am I right in saying that if on later
stage I want to provide UI (done in
Qt) for the application I'm working on
at the momment, using parallel_for in
my code will be an obstruction which
would mean that either I'll replace
parallel_for with some other
(portable) alternative or I won't be
able to do UI in Qt and core in VS
You can write your core-framework in using PPL/VC++, and other GUI counterpart in QT/other-compiler. For this just make a DLL which would use PPL, and your GUI application would use the DLL. I do believe you understand what I mean here. This also reduces burden from your head about portability (on Windows).
What are the (portable) alternatives to ppl?
Many, but I prefer using PPL on Windows/VC++. You may consider using Intel's TBB. OpenMP is troublesome, and doesn't give advantages as compared to TBB/ConcRT
I want to learn multi-threading in C++ but I'm not sure what type would be most useful. The ones I've seen tutorials on are:
Windows native calls
OpenMP
Boost
(I'm sure that there are probably more.)
What is each one's key features and what are they best used for?
Note: I've already done some multi-threading in C# by manually creating the threads, and more complexity of the threading will just make it more fun. :)
I'd start with pthreads if you have more of a C background, or Boost Thread if you are accustomed to more idiomatic C++. Either is reasonably portable and widely used.
How about TBB? It is portable and has easy to use parallel template patterns, concurrent containers, task scheduler and scalable memory allocaturs. TBB will let you manage threads directly, but that is not necessary in most of the cases.
Personally I would stay away from platform specific threads, unless there an urgent need to do something, well, platform specific.
Boost threads is portable and easy to use, but does have neither parallel patterns nor concurrent containers. You would need to manager threads manually, which can get ugly pretty quickly.
PThreads isn't available on Windows and its C. You really want to do multi-threading in C++, not C. RAII mixes well with mutexes and scoped locks.
Another option is PPL in Visual C++ 2010. It is similar to TBB, but as you may guess available for Windows only.
OpenMP is easy to use, but not very flexible. Since you already learned C++, you should use something more serious, such as TBB or PPL. For some strange reason Visual C++ 2010 doesn't support OpenMP 3. Too bad.
If you want to be portable, learn Posix threads. You know, all thread libraries provide more or less the same set of features, so it's up to you, but Posix will give you the basis.
openMP isn't exactly "multi-threading" as you mean it.
WinThreads (Windows) and pthreads (Linux) are POSIX threads and represent probably your best choice to get started. It is important to learn the distinction between processes and threads, then learn about the various memory access models that are associated with them. Next, try concurrency approaches like OpenMP and MPI "threads".
There are some basic concepts that will get repeated. Learn them well.
Been doing mostly Java and smattering of .NET for last five years and haven't written any significant C or C++ during that time. So have been away from that scene for a while.
If I want to write a C or C++ program today that does some multi-threading and is source code portable across Windows, Mac OS X, and Linux/Unix - is PThread a good choice?
The C or C++ code won't be doing any GUI, so won't need to worry with any of that.
For the Windows platform, I don't want to bring a lot of Unix baggage, though, in terms of unix emulation runtime libraries. Would prefer a PThread API for Windows that is a thin-as-possible wrapper over existing Windows threading APIs.
ADDENDUM EDIT:
Am leaning toward going with
boost:thread - I also want to be able
to use C++ try/catch exception
handling too. And even though my
program will be rather minimal and not
particularly OOPish, I like to
encapsulate using class and namespace
- as opposed to C disembodied functions.
Well, pthreads is the old posix standard for writing threaded programs. Its the lowest level threading routines, so its a good choice for cross-platform threading.
However, there are alternatives:
boost::thread - an STL style
threading library
Intel's Thread
Building Blocks
OpenMP -
both these are a higher-level way of
writing threaded apps without needing
to do any threading calls.
As the latter are all fully supported on all platforms, (pthreads requires a bit of compiler settings as its only part of Windows posix subsystem, unless you want to use Pthreads-w32), then perhaps the latter ones are a better choice. boost::threads are more like a threading library, the other 2 are high-level ways of achieving parallelism without needing to code 'threads', they allow you to write loops that run concurrently automatically (subject to common-sense conditions)
Boost::thread is not a C compatible library though.
edit: cross-platform abilities of the above:
Intel TBB is cross-platform (Windows*,
Linux*, and Mac OS* X), supports
32-bit and 64-bit applications and
works with Intel, Microsoft and GNU
compilers.
OpenMP depends on the compiler you want to use, but GCC and/or Intel compilers have supported OpenMP Windows, Linux and MacOS.
If you need your code to be truly portable then it may be best to stay away from the various libraries that scatter the internet. At some point you'll find a platform they don't support and will then have to create your own branch.
This is also not a hard problem to solve and can be a good exercise for creating cross-platform code.
I'd suggest you create a class, e.g. CThread, that has separate .cpp implementations for each platform and a pure-virtual execute() function that is called after your thread is constructed/run.
That allows all of your thread-creation and sleep/shutdown/priority code to be implemented using the most appropriate API for the platform. You may also need a header (e.g. ThreadTypes.h) that contains defines/typedefs for each platform.
E.g.
// ThreadTypes.h
#if defined(PLATFORM_WIN) || defined(PLATFORM_XBOX)
typedef DWORD ThreadID
#elif defined(PLATFORM_PS3)
// etc etc
#endif
This is how I have written all my cross-platform threading code for platforms such as PC/PS2/PS3/360/Wii. It is also a good pattern to follow for things like mutex's and semaphores, which if you have threads you're certain to need at some point :)
Nope, pthreads aren't normally available on Windows. (There are a few attempts at implementing it, but it's not supported by the OS directly, at least.)
If you're writing C++, Boost is, as usual, the answer. Boost.Thread has a portable (and safer) threading library.
In C, the simplest solution is probably to wrap write a common wrapper for both pthreads and the Windows threading API.
I will bet on ZThread
Simple API, easier to use than PThreads and FREE
Have a look at ting also:
http://code.google.com/p/ting/
It is cross platform between Windows and Linux. No Mac OS support yet.