Hi -
The existing runtime code puts task functions into a table and assigns
each an ID (a chpl_fn_int_t). I think if it were me, I'd try to
arrange for the Futures module to create task functions similarly
to what happens for 'begin'. But doing that might amount to doing
a bunch of the Futures TODOs to make them more integrated with the
language/compiler.
The code you showed has a problem in that the Chapel compiler
doesn't guarantee that tuple elements are stored consecutively
in memory. (I don't want to guarantee that about records either,
so that things like Apan's SoA <-> AoS can be legal transformations).
As a result, it might work some of the time, but other times you
might not see the arguments you expected hanging off of the
pointers.
Anyway, the shortest path here might be to add some minimum
amount of extra information/tracking to the compilation process
for the tasks that the Futures module creates. What information/arguments
do you want the chpl_task_addToTaskList call (or related thing) to
use that it doesn't right now?
-michael
>Hi,
>
>I am trying to write a custom tasking layer in Chapel that uses our ATMI
>runtime (tasking layer on top of AMD’s ROCm runtime stack); one of the
>use cases being able to re-implement the Futures package using ATMI.
>Eventually, I want to be
> able to translate Futures.async to atmi_task_launch and translate
>Futures.andThen to atmi_task_launch with the dependent tasks as
>arguments. ATMI is better equipped to build task graphs, and hence this
>exploration.
>
>
>externproc chpl_task_launch(fn: c_fn_ptr, num_args:
>int, args_sizes: [] int(64),
>args...?numvals);
>
>proc async(taskFn, args...) {
>
>var f: Future;
>
>//get fn ptr to taskFn, which itself can be taking variable arguments
>
>//get fn args list
> f = chpl_task_launch(c_ptrTo(taskFn), n, sizes,
>(...args));
>
>return f;
>}
>
>To this end, I would need to pass custom Chapel procedures and lambdas as
>{function id, arg1, arg2, …} to the ATMI C runtime layer. How can I use
>the existing Chapel-to-C interop to do the following:
>1)
>Pass a user-written proc/lambda with any number arguments.
>2)
>Pass the incoming variadic arguments as an argument region or any other
>way in which it can be retrieved by the runtime.
>
>It would have been easier if there was a C++ interoperability layer to
>Chapel, but we only have a C interoperability layer for now, so we will
>have to make do with that. Right now, I am trying to get to the above in
>a somewhat convoluted
> way like this:
>
>pragma"no doc"
>proc getArgs(arg) {
>
>return (arg,);
>}
>
>pragma"no doc"
>proc getArgs(arg, args...) {
>
>return (arg, (...getArgs((...args))));
>}
>
>externproc chpl_task_launch(fn: c_fn_ptr, num_args:
>int, args_sizes: [] int(64),
>args: c_void_ptr); //args...?numvals);
>
>proc async(taskFn, args...) {
>
>var args_list = getArgs((...args));
>
>var f = chpl_task_launch(c_ptrTo(taskFn), n, sizes,
>c_ptrTo(args_list));// (...args));
>
>return f;
>}
>
>But we are not sure if the above is the cleanest approach or if there are
>holes in this approach. Any thoughts/suggestions?
>
>
>Regards,
>Ashwin
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
