forked from OSchip/llvm-project
5e334b516b
Summary: This commit adds a check-pstl CMake target that will run the tests we currently have for pstl. Those tests are not using LLVM lit yet, but switching them over should be a transparent change. With this change, we can start relying on the `check-pstl` target for workflows and CI. Note that this commit purposefully does not support the pre-monorepo layout (with subprojects in projects/), since LLVM is moving towards the monorepo layout anyway. Reviewers: jfb Subscribers: mgorny, jkorous, dexonsmith, libcxx-commits, mclow.lists, rodgert Differential Revision: https://reviews.llvm.org/D55963 llvm-svn: 349919 |
||
---|---|---|
.. | ||
build | ||
cmake | ||
include/pstl | ||
test | ||
.arcconfig | ||
.clang-format | ||
CMakeLists.txt | ||
CREDITS.txt | ||
LICENSE.txt | ||
ParallelSTLConfig.cmake.in | ||
README.md |
README.md
Parallel STL
Parallel STL is an implementation of the C++ standard library algorithms with support for execution policies, as specified in ISO/IEC 14882:2017 standard, commonly called C++17. The implementation also supports the unsequenced execution policy specified in Parallelism TS version 2 and proposed for the next version of the C++ standard in the C++ working group paper P1001R1. Parallel STL offers efficient support for both parallel and vectorized execution of algorithms. For sequential execution, it relies on an available implementation of the C++ standard library.
Prerequisites
To use Parallel STL, you must have the following software installed:
- C++ compiler with:
- Support for C++11
- Support for OpenMP* 4.0 SIMD constructs
- Threading Building Blocks (TBB) which is available to download in the GitHub repository
Known Issues or limitations
unseq and par_unseq policies only have effect with compilers that
support '#pragma omp simd' or '#pragma simd'.
Parallel and vector execution is only supported for the algorithms
if random access iterators are provided, while for other iterator
types the execution will remain serial.
The following algorithms do not allow efficient SIMD execution:
includes, inplace_merge, merge, nth_element, partial_sort,
partial_sort_copy, set_difference, set_intersection,
set_symmetric_difference, set_union, sort, stable_partition,
stable_sort, unique.
The initial value type for exclusive_scan, inclusive_scan,
transform_exclusive_scan, transform_inclusive_scan shall satisfy
the DefaultConstructible requirements. A default constructed-instance
of the initial value type shall be the identity element for binary_op.
For max_element, min_element, minmax_element, partial_sort,
partial_sort_copy, sort, stable_sort the dereferenced value type of
the provided iterators shall be DefaultConstructible.
For remove, remove_if, unique the dereferenced value type of the provided
iterators shall be MoveConstructible.
The following algorithms require additional O(n) memory space for parallel
execution: copy_if, inplace_merge, partial_sort, partial_sort_copy,
partition_copy, remove, remove_if, rotate, sort, stable_sort, unique,
unique_copy.