@@ -790,120 +790,15 @@ Parallel algorithms
790790 * Implements loop functionality over a range specified by integral or iterator bounds.
791791 * ``<hpx/include/parallel_for_loop.hpp> ``
792792
793- .. _executors :
794-
795- Executors and executor traits
796- =============================
797-
798- The existing Version 1 of the Parallelism TS (|cpp11_n4104 |_) exposes parallel
799- execution to the programmer in the form of standard algorithms that accept
800- execution policies. A companion executor facility both provides a suitable
801- substrate for implementing these algorithms in a standard way and provide a
802- mechanism for exercising programmatic control over where parallel work should be
803- executed.
804-
805- The algorithms and execution policies specified by the Parallelism TS are
806- designed to permit implementation on the broadest range of platforms. In
807- addition to preemptive thread pools common on some platforms, implementations of
808- these algorithms may want to take advantage of a number of mechanisms for
809- parallel execution, including cooperative fibers, GPU threads, and SIMD vector
810- units, among others. This diversity of possible execution resources strongly
811- suggests that a suitable abstraction encapsulating the details of how work is
812- created across diverse platforms would be of significant value to parallel
813- algorithm implementations. Suitably defined executors provide just such a
814- facility.
815-
816- An executor is an object responsible for creating execution agents on which work
817- is performed, thus abstracting the (potentially platform-specific) mechanisms
818- for launching work. To accommodate the goals of the Parallelism TS, whose
819- algorithms aim to support the broadest range of possible platforms, the
820- requirements that all executors are expected to fulfill are small. They are also
821- consistent with a broad range of execution semantics, including preemptive
822- threads, cooperative fibers, GPU threads, and SIMD vector units, among others.
823-
824- The executors implemented by |hpx | are aligned with the interfaces proposed by
825- |cpp11_n4406 |_ (Parallel Algorithms Need Executors).
826-
827- Executors are modular components for requisitioning execution agents. During
828- parallel algorithm execution, execution policies generate execution agents by
829- requesting their creation from an associated executor. Rather than focusing on
830- asynchronous task queuing, our complementary treatment of executors casts them
831- as modular components for invoking functions over the points of an index space.
832- We believe that executors may be conceived of as allocators for execution agents
833- and our interface's design reflects this analogy. The process of requesting
834- agents from an executor is mediated via the
835- :cpp:class: `hpx::parallel::executor_traits ` API, which is analogous to the
836- interaction between containers and allocator_traits.
837-
838- With ``executor_traits `` clients manipulate all types of executors uniformly::
839-
840- executor_traits<my_executor_t>::execute(my_executor,
841- [](size_t i){ // perform task i },
842- range(0, n));
843-
844- This call synchronously creates a group of invocations of the given function,
845- where each individual invocation within the group is identified by a unique
846- integer ``i `` in ``[0, n) `` Other functions in the interface exist to create
847- groups of invocations asynchronously and support the special case of creating a
848- singleton group, resulting in four different combinations.
849-
850- Though this interface appears to require executor authors to implement four
851- different basic operations, there is really only one requirement:
852- ``async_execute() ``. In practice, the other operations may be defined in terms
853- of this single basic primitive. However, some executors will naturally
854- specialize all four operations for maximum efficiency.
855-
856- For maximum implementation flexibility, ``executor_traits `` does not require
857- executors to implement a particular exception reporting mechanism. Executors may
858- choose whether or not to report exceptions, and if so, in what manner they are
859- communicated back to the caller. However, all executors in |hpx | report
860- exceptions in a manner consistent with the behavior of execution policies
861- described by the Parallelism TS, where multiple exceptions are collected into an
862- __exception_list__. This list is reported through ``async_execute() `` s returned
863- future, or thrown directly by ``execute() ``.
864-
865- .. note ::
866-
867- Please note that the executor interface as described above has now been
868- deprecated. It has been replaced by separate executor customization points,
869- one for each of the exposed functions. Please see __cpp20_p0443__ for more
870- details. The old interface based on ``executor_traits `` will be supported for
871- some time, you might have to enable the ``HPX_WITH_EXECUTOR_COMPATIBILITY ``
872- configuration setting, however.
873-
874- In |hpx | we have implemented the following executor types:
875-
876- * :cpp:class: `hpx::parallel::execution::sequenced_executor `: creates groups of
877- sequential execution agents which execute in the calling thread. The
878- sequential order is given by the lexicographical order of indices in the index
879- space.
880- * :cpp:class: `hpx::parallel::execution::parallel_executor `: creates groups of
881- parallel execution agents which execute in threads implicitly created by the
882- executor. This executor uses a given launch policy.
883- * :cpp:class: `hpx::parallel::execution::service_executor `: creates groups of
884- parallel execution agents which execute in one of the kernel threads
885- associated with a given pool category (I/O, :term: `parcel `, or timer pool, or
886- on the main thread of the application).
887- * :cpp:class: `hpx::parallel::execution::local_priority_queue_executor `,
888- :cpp:class: `hpx::parallel::execution::local_queue_executor `,
889- :cpp:class: `hpx::parallel::execution::static_priority_queue_executor ` create
890- executors on top of the corresponding |hpx | schedulers.
891- * :cpp:class: `hpx::parallel::execution::distribution_policy_executor ` creates
892- executors using any of the existing distribution policies (like
893- :cpp:class: `hpx::components::colocating_distribution_policy ` et.al.).
894-
895793.. _executor_parameters :
896794
897795Executor parameters and executor parameter traits
898796-------------------------------------------------
899797
900- Executors as described in the previous section add a powerful customization
901- capability to any facility which exposes management of parallel execution.
902- However, sometimes it is necessary to be able to customize certain parameters of
903- the execution as well. In |hpx | we introduce the notion of execution parameters
904- and execution parameter traits. At this point, the only parameter which can be
905- customized is the size of the chunks of work executed on a single |hpx |-thread
906- (such as the number of loop iterations combined to run as a single task).
798+ In |hpx | we introduce the notion of execution parameters and execution parameter
799+ traits. At this point, the only parameter which can be customized is the size of
800+ the chunks of work executed on a single |hpx |-thread (such as the number of loop
801+ iterations combined to run as a single task).
907802
908803An executor parameter object is responsible for exposing the calculation of the
909804size of the chunks scheduled. It abstracts the (potential platform-specific)
0 commit comments