is there a chance to partially compile MCSTL on MSVC (especially multiway_merge)?
If not - why? What are the main difficulties regarding OMP. Can you give me some light on that?
The main problems consisted in transparently integrating the library into the MSVC STL. Compiling single routines should work with MSVC. The OpenMP functionality should also be compatible, I just don't know about the performance. So give it a try.
Thank you for clarification.
So MCSTL modifies the STL provided by the GNU toolchain.
GPL prohibits use of MCSTL in commercial projects!
Therefore commercial projects won't benefit from the mc optimizations in the STXXL library.
As you stated in your article about asynchronous pipelining io processing becomes
more CPU bound with MC-CPU's and larger disks/ssd's. My naive approach e.g. using
a classical mt-quicksort in the stream sort already shows a significant performance boost
compared to the sequential stl variation.
So it would be -:) if MCSTL would support MSVC too or provides a basic interface in a
separate non-std namespace.
The libstdc++ parallel mode integrates closely with the GCC STL (libstdc++), the MCSTL (former version) does not, and is also dual-licensed under the permissive Boost license. Futhermore, for the libstdc++, there exists a special "runtime exception", i. e. commercial software does not have to be GPL just because of including (compiled) libstdc++ code.
So what would you suggest how to efficiently integrate stxxl with mc concurrency support for MSVC projects?
I don't know. The options are:
1. Convince MS of providing a parallel STL.
2. Take the MCSTL / parallel mode code and port it (partly) to MSVC (find out about possible copyleft issues for parallel mode in detail).
3. Take some other code/library (and port it to MSVC).
4. Write your own parallel routines.
1. With VC10 MS starts introducing a new concurrency model (namespace Concurrency) and a Parallel Patterns Library (PPL.h). So far I haven't try it. On the first sight it is very limited i.e. it provides parallel_for and parallel_for_each. Perhaps PPL.h will be extended in the future i.e. supporting other algorithms like parallel_sort … (VC15?). Currently it is not an option for me.
2. Best option I think.
4. That's not an easy task and seems to be a lengthy one too -:)