Repository navigation
actx.tag() comes too late to benefit eager mode execution #5
Description
For lazy mode, actx.tag(MyTag(), 2*x+3) works great. For eager mode, this doesn't help at all, as the result will already be computed (i.e. the kernel whose transformation would have benefited from the metadata was already executed). Is there a tagging interface that can work for both eager and lazy?
cc @alexfikl @thomasgibson @nchristensen @kaushikcfd
x-ref: inducer/meshmode#176
Activity
thomasgibson commentedon May 1, 2021
This is more or less kinda what I was trying (albeit rushed/incomplete) in inducer/meshmode#170 --- Based on your comments there, I can imagine that one would tag information to a loopy program "as you go", which can then be transformed based on said information in transform_loopy_kernel. This is assuming that, when doing any kind of eager evaluation, it always ends up going through actx.call_loopy.
Obviously with eager this would be somewhat limited (since results are computed as you go), but some level of code transformation can and should happen along the way.
With lazy, this information just gets propogated through until evaluation is needed, and so I imagine these transformations will occur at the pytato level.
thomasgibson commentedon May 1, 2021
In short, I think tagging can still work for eager.
Update: Unless I am fundamentally misunderstanding something. I guess what I'm wondering is, if all expressions (whether eager or lazy) go through
transform_loopy_kernel, then what can we do to potentially take advantage of this?inducer commentedon May 3, 2021
My thought was that lazy would bypass
transform_loopy_kernelmostly. And much of eager (specifically the array arithmetic) also directly uses PyOpenCL array arithmetic and bypassestransform_loopy_kernel.inducer commentedon May 3, 2021
I agree that it can, but what this issue is about is the method
actx.tag, whose job it is to apply a tag to an array result. The complaint is that it'll only work for lazy.