You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The executor should be a container object, which contains all types and objects, which are required to launch a vikunja algorithm. His task is it to simplify the API.
The complete definition and properties are not fixed yet.
It should be still possible to use all possibilities of alpaka. The executor object should only simplify the default case.
The text was updated successfully, but these errors were encountered:
SYCL is a bit more low-level than vikunja (it doesn't provide host-side algorithms like reduce). What @psychocoderHPC was talking about today is the distinction SYCL makes between different objects. Memory is separate from queues and queues are separate from devices... they are not combined into god-like objects.
I like your proposed API. For reference, this is how the C++ executor proposal looks like:
executor auto ex = /* ... */;
std::reduce(std::execution::par.on(ex), /* first */, /* last */, /* init */, /* op */);
std::transform(std::execution::par.on(ex), /* first */, /* last */, /* out */, /* op */);
I believe we can achieve something similar with vikunja executors.
The executor should be a container object, which contains all types and objects, which are required to launch a vikunja algorithm. His task is it to simplify the API.
Possible implementation for the basics:
executor.hpp
reduce.hpp
main.cpp
The complete definition and properties are not fixed yet.
It should be still possible to use all possibilities of alpaka. The executor object should only simplify the default case.
The text was updated successfully, but these errors were encountered: