what about ppl?

Feb 12, 2015 at 7:59 PM
Hi,

I am curious about the future of PPL or at lest the parallel_for and related algorithms once this project makes it into the STL.
  1. Do you plan to keep both? That will be confusing...
  2. Do you plan to do any GPU based implementation of this library? For example if a GPU is detected, run on that, else fall back on threads on CPU.
  3. For the implementation do you use Concrt or do you go directly to Windows treads (maybe the thread pool in windows)?
Thanks,

G.
Feb 13, 2015 at 12:14 AM
Hi G.

While I am not with Microsoft I think that PPL and other parallel libraries would be that in some form in the future. It might be the underlining technology in Microsoft's implementation of parallel stl and remember PPL is not portable on other systems.

Also, there is nothing is the standard that says the could or could not be used on GPUs, FPGAs, or other hardware or could computing devices. My guess that is this were needed then the execution polices would be responsible for determining the code

My only issue with parallel stl is that they really need to put concurrency containers (preferably lock-free) into the library for better use.
Feb 13, 2015 at 1:36 AM
...................
My only issue with parallel stl is that they really need to put concurrency containers (preferably lock-free) into the library for better use.
...................
Well they are in PPL, at least I used 'concurrent_queue' & 'concurrent_vector'. I think they are lock free.

Anyway, once this new parallel STL is accepted in the standard and released, MS must do some adjustments to their PPL, otherwise it will be very confusing to have two 'parallel_for', etc.

Besides, I am curios if they decided to implement parallelSTL in terms of concurrency run-time, or going directly to the Windows thread pool?

G.
Feb 14, 2015 at 1:06 AM
Hi G again:

I have check and there is no 'parallel_for' in parallel stl. These implementations mimic the standard algorithms library in C++ most of which requires a data container and iterators until C++ concepts (with the C++ 17 standard hopefully) are introduced.

As for 'concurrent_queue' and 'concurrent_vector' the are not portable exactly except for through third party libraries like tbb. If they are in the standard they are more helpful to use because they can append vectors an queue without worrying data races. Specifically std containers like std::vector, std::deque, and std::list are not thread safe.

Also the other thing I would like is to apply the parallel stl execution policy to range based for loops. Like so:
for( std::experimental::parallel::par, auto& x : dataset)
     doSomething(x);
Finally in the current implementation uses neither the concurrency run-time, nor "Windows thread pool" but rather std::threads to form a task scheduler and thread pools.
Feb 14, 2015 at 2:14 AM
I have check and there is no 'parallel_for' in parallel stl.
OK but for example there is a sort(par, ....) to sort in parallel and there is a parallel_sort in PPL. So those kinds of things will be confusing! The simple question will be 'which implementation do we use"?

..............
Finally in the current implementation uses neither the concurrency run-time, nor "Windows thread pool" but rather std::threads to form a task scheduler and thread pools.
..............
Are you sure? Yesterday I saw a Channel 9 video on this subject and someone was saying that they go directly to Windows thread pool...

Anyway so they have created a new task scheduler and a thread pool based on std::thread! Funny that they have another great project (Casablanca or REST SDK) where they did create a new thread pool and tasks, in Windows, Linux, iOS, Android. In this case in Windows they use Windows thread pool API. Why didn't this project just took that already done implementation?

G.
Feb 16, 2015 at 7:39 PM
Edited Feb 17, 2015 at 2:27 PM
Hi G:
Did you check the current code base? I am using it on a project and do not see and windows thread pool in the base although I did see #include <Windows.h> in the implementation file but the appear to be only for defining locks and callbacks I do no see them doing anything with "Windows thread pools" API. I might try removing the later and replacing them with standard lock for portability under non window OSs. My guess would be because this is going into the C++ 17 standard they do want to avoid the use Windows specific APIs which might change by the time the standard is released. also this give an equal comparison under Windows, Linux, and MacOS.

If this library feature becomes part of the standard I could see PPL still remain but used in a different form to use this feature.

I hope you can say that PPL's parallel_sort is not the same as std::sort done in parallel. The function std::sort uses a modified mergesort. while parallel_sort uses quicksort as the base implementation. Microsoft's PPL sorting implementation may have many great features as three different sorting algorithms but three major flaws.
  1. PPL are for window only and cannot be used on other operating systems without modification.
  2. PPL do not support the full standard algorithms like find, count, copy, etc. and therefore has limited functionality
  3. Even PPL's sorting three sorting algorithms are not the stable with user defined data sets.
Even with these flaws PPL has some strengths than Parallel STL
  1. PPL has some function that have no equivalent in the current standard these include parallel_for, parallel_invoke, and parallel_reduce.
  2. PPL has three different sorting routines that provide and defined specialize sorting with better defined definition how they are implemented.
Finally to answer which you question "implementation do we use?" I will use the old round about answer "it depends." A good rule of thumb might be if there in an implementation of the standard algorithms and you do not particularly care about how the algorithm runs use parallel stl. If you care about how the algorithm runs or have raw loops use PPL.