Towards unified device & host tasks

[devreal]

We now template the ttg::device::Task on the ExecutionSpace so that we can determine whether it's a host or device task based on the space. We can then optimize away the select and kernel-wait suspension points. We could remove the send suspension point but we use coroutines for storing the final sends anyway and we don't have access to the task return type in ttg::device::send().

This allows tasks to be written once for both host and device without duplicating much of the code. Host tasks that are not coroutines will continue to be supported.

[devreal]

I should also mention that this could allow us to take multiple callables in ttg::make_tt and identify their execution space by the return type, laying the ground work for multi-implementation tasks in the future.

[evaleev]

I think it looks fine. The only concern is the terminology ... dev-host is awkward ... perhaps this is the right time to revise the terminology (e.g. ttg::device::Task<> -> ttg::coTask<>?)

[devreal]

perhaps this is the right time to revise the terminology (e.g. ttg::device::Task<> -> ttg::coTask<>?)

I'm not sure about that. We probably don't want to make coroutine tasks the default. So what are they? For me, these tasks are still device tasks but now we have the ability to execute the same task structure on the host. I agree that the naming is a bit funny though.

[therault]

AsyncTask? Just to make it independent of the technique/implementation used, and try to convey that it can be used for something else than devices?

That being said, coTask (or co_task to keep a coroutine-like syntax?) conveys the idea that the task itself is a coroutine, which is maybe more helpful for the user.

[evaleev]

I'm not sure about that. We probably don't want to make coroutine tasks the default. So what are they? For me, these tasks are still device tasks but now we have the ability to execute the same task structure on the host. I agree that the naming is a bit funny though.

I agree we don't want to make coTask the default. But it's extremely confusing to refer to them as device task. I would prefer a name that does not refer to device to avoid misleading ppl.

[evaleev]

AsyncTask? Just to make it independent of the technique/implementation used, and try to convey that it can be used for something else than devices?

To me the word "task" already implies "asynchrony" of execution, by decoupling statement of what to do from when to do it (i.e. after submitting task there is no way to ensure that work has completed unless you await for the result/completion). So AsyncTask sounds a bit redundant to me.

That being said, coTask (or co_task to keep a coroutine-like syntax?) conveys the idea that the task itself is a coroutine, which is maybe more helpful for the user.

I like co_task ... and we are not the only ones who thought of it: e.g. https://llvm.org/devmtg/2024-04/slides/QuickTalks/Saxena-MitigatingLifetimeIssues.pdf ... google c++ "co_task" for more.

Perhaps what we need is to make cotasks and tasks more symmetric?

using Task = void;

make_tt([]() -> Task, ...)

[devreal]

Proposal from the EPEXA meeting: ttg::CoTask<ttg::ExecutionSpace::CUDA> for CUDA or ttg::CoTask<ttg::ExecutionSpace::Host> for host execution.

[abouteiller]

What's the difference between CHAIN_CUDA/HIP and ENABLE_CUDA/HIP?

[abouteiller]

Naming is inconsistent, TTG_ENABLE_CPU ?

[abouteiller]

shouldn't that be TTG_ENABLE_CUDA, or CHAIN_CUDA?

[abouteiller]

key parameter moves from 2nd to first parameter depending on level.