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).
Related
Background
this documentation says that it is possible to adapt the library to new (unsupported) operation system. Because the OS (a real time OS) I would like to support is close to Win32, I would expect little code changes. I have no experience with Boost Thread and Boost Interprocess .
Questions
Would you recommend to use Boost's Thread and Boost's Interprocess, if the
plattform is not supported?
What are the benefits and drawbacks?
Which alternatives would you consider?
All this depend on your needs. Using a portable library has the obvious advantages. Stabilizing a new platform could take some time.
I would suggest you to create tickets for each one of the features that doesn't work for the specific platform and work closely with the Boost authors.
I am porting some Java code to C++ and wanted to find something that worked like Java's ThreadPoolExecutor. I saw a few posts suggesting threadpool but after reading a few other forums I have read about problems(memory leaks, etc..) and browsing the code base I see the last update was over 3 years ago. So my problem is, I'm not quite up to speed to make my own thread-pool library but I don't want to use something that is not actively maintained.
Upon looking around there's a few threadpool projects but they don't seem heavily used(I'm basing it on how family favorites/watches on github/code.google). I was wondering what other people are using for threadpools in production environments? I'm looking for 2 types of thread-pools, one fixed and one that grows dynamically.
Which platform ? If windows and can use ppl using Visual C++ compiler, then take
a look at task_group and make_task methods to create tasks. Intel TBB is
another option.
If you can use boost, then boost concurrent programming APIs
can be useful.
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
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
I have a C# prototype that is heavily data parallel, and I've had extremely successful order of magnitude speed ups using the Parallel.For construct in .NETv4. Now I need to write the program in native code, and I'm wondering what my options are. I would prefer something somewhat portable across various operating systems and compilers, but if push comes to shove, I can go with something Windows/VC++.
I've looked at OpenMP, which looks interesting, but I have no idea whether this is looked upon as a good solution by other programmers. I'd also love suggestions for other portable libraries I can look at.
If you're happy with the level of parallelism you're getting from Parallel.For, OpenMP is probably a pretty good solution for you -- it does roughly the same kinds of things. There's also work and research being done on parallelized implementations of the algorithms in the standard library. Code that uses the standard algorithms heavily can gain from this with even less work.
Some of this is done using OpenMP, while other is using hand-written code to (attempt to) provide greater benefits. In the long term, we'll probably see more of the latter, but for now, the OpenMP route is probably a bit more practical.
If you're using Parallel.For in .Net 4.0, you should also look at the Parallel Pattern Library in VS2010 for C++; many things are similar and it is library based.
If you need to run on another platform besides Windows the PPL is also implemented in Intel's Thread Building Blocks which has an open source version.
Regarding the other comment on similarities / differences vs. .Net 4.0, the parallel loops in the PPL (parallel_for, parallel_for_each, parallel_invoke) are virtually identical to the .Net 4.0 loops. The task model is slightly different, but should be straightforward.
You should check out Intel's Thread Building Blocks. Visual Studio 2010 also offers a Concurrency Runtime native. The .NET 4.0 libraries and the ConcRT are designed very similarly, if not identically.
if you want something that is versatile, as in portable across various OS and environments, it would be very difficult to not to consider Java. And they are very similar to C# so it be a very easy transition.
Unless you want to pull out your ninja scalpel and wanting to make your code extremely efficient, I would say java over VC++ or C++.