More executor changes

[hkaiser]

After merging the first batch of changes related to executors (see #1510), there is a list of things to implement to finalize their design and integration with the rest of the code base:

• allow dataflow to be used with executors (Integrate executors with dataflow #1545)
• allow .then() to be used with executors (Adding support for executors to future.then #1547)
• remove .on() functionality from the existing 'shim' execution policies (inhibit chaining of .on() calls) (Executor algorithms #1556)
  • This will have to be re-added for the .with() functionality. We need to investigate if disable chaining .on() only is possible (and sensible to do).
• enable all existing parallel algorithms to be usable with execution policies generated by .on() (Removed const from algorithms #1567)
• create a NUMA aware executor (run tasks on this NUMA domain) (Os executors #1741)
• integrate executors with hpx::partitioned_vector and hpx::unordered_map to enable seamless SPMD style of execution
• integrate executors with distribution policies (e.g. run tasks on this locality, etc.) (Add distribution_policy_executor #1701, Fixed distribution policy executors #1713)
• inhibit generic execution_policy from being instantiated by 'shim' execution policies (Working on 1544: More executor changes #1679)
• make use of executor traits' bulk functionality in each of the partitioners
  • for_each_partitioner: Executor partitioners #1622
  • static_partitioner: Converting partitioners to use bulk async execute #1685
  • scan_partitioner: Modified Scan Partitioner for Algorithms #1696
• Extend executor interface to support timed scheduling (Implemented timed executors #1709, Timed executor traits for thread-executors #1717)
• Add .with() to execution policies allowing attaching an executor_parameter_traits<Executor> which customizes various scheduling parameters, like chunking (Executor parameters #1700)
• Add this-thread-executor (needed to support HPXRx) (Add this_thread_executors #1669, This thread executors #1695)
• Unify parallel_executor and parallel_fork_executor (Unifying parallel executors, initializing from launch policy #1721)

[sithhell]

create a NUMA aware executor (run tasks on this NUMA domain)

This will be a tough one, not only do we want to confine tasks to run on
this NUMA domain only, we also want to be able to partition a set of
tasks over different NUMA domains. This needs to be closely coordinated
with the GSoC project. I think proper resource sharing of the available
hardware resources is a mandatory pre condition to that.

integrate executors with hpx::vector and hpx::unordered_map to enable seamless SPMD style of execution integrate executors with distribution policies (e.g. run tasks on this locality, etc.)

Another important aspect is to associate actions with executors.

[hkaiser]

Another important aspect is to associate actions with executors.

That's what I meant when I wrote 'integrate executors with distribution policies'

[sithhell]

Another important aspect is to associate actions with executors.

That's what I meant when I wrote ' integrate executors with distribution policies'

Distribution policies would take care of this at the caller site indeed. A challenge will be heterogeneous systems.
What I had in mind was choosing a executor at the callee site (for example a component could decide where the action is run, aligned with the policy engine for example).

[hkaiser]

What I had in mind was choosing a executor at the callee site (for example a component could decide where the action is run, aligned with the policy engine for example).

Sure, but this is not what the executor_traits are meant to be used for. They are used for selecting the proper agent at the call site.

[sithhell]

What I had in mind was choosing a executor at the callee site (for example a component could decide where the action is run, aligned with the policy engine for example).

Sure, but this is not what the executor_traits are meant to be used for. They are used for selecting the proper agent at the call site.

One could think of a component as an executor. They already have a
schedule_thread function after all. Using executor_traits for that as
well makes sense to me.

[hkaiser]

One could think of a component as an executor. They already have a schedule_thread function after all. Using executor_traits for that as well makes sense to me.

You will have to elaborate (help). Even after thinking about it some more I was not able to make the concepts fit.

[hkaiser]

@heller I realized that we have an example demonstrating how to bind the execution of all actions of a particular component to a specified executor: https://github.com/STEllAR-GROUP/hpx/blob/master/examples/quickstart/component_with_executor.cpp

Would this be what you were looking for?

[hkaiser]

@sithhell see above, pls

[sithhell]

It still seems very low level, but a start. What's missing is a way to select executors on an action by action basis.

[sithhell]

Moving this to 1.0.0.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed. Please re-open if necessary.