Cache kernels in array context

[alexfikl]

TODOs:

• Is FMMLibRotationDataInterface necessary? It seems to be just a to_numpy(RotationClassesInfo), but it's also used in pytential in some places..

[inducer]

• Is FMMLibRotationDataInterface necessary? It seems to be just a to_numpy(RotationClassesInfo), but it's also used in pytential in some places..

I'd say no. One ugly aspect that hopefully this can resolve is that all arrays used to be, by convention, CL arrays. This was pretty unfortunate for FMMLib, because it doesn't work with CL arrays. In the "brave new world of array context", FMMLib would simply run on the Numpy array context (inducer/arraycontext#190), and only on that.

[alexfikl]

I'd say no. One ugly aspect that hopefully this can resolve is that all arrays used to be, by convention, CL arrays. This was pretty unfortunate for FMMLib, because it doesn't work with CL arrays. In the "brave new world of array context", FMMLib would simply run on the Numpy array context (inducer/arraycontext#190), and only on that.

As a end goal, I definitely agree with that. However, since a lot of small pieces in here go either through loopy or through pyopencl kernels, I imagine it'll take quite a bit more work than this to get it nicely agnostic.

Once boxtree, sumpy and pytential sort of work on the array context branches, we can probably revisit this a bit and see what's what.

[inducer]

I agree. I think boxtree will retain a hard dependency on pyopencl for the foreseeable future, so in that sense the actx support will be skin-deep. Sumpy and the FMM are loopy-only, so I think that'll be easier to make "truly actx-ish". Pytential in turn does significant tree/geometry processing, leaving it back in "skin-deep" territory.

[inducer]

Saw you closed this. Did this turn into commits in inducer#56? Or is it just game over here?

[inducer]

And if the latter: would it make sense to dump this into a draft PR in the upstream repo?

[alexfikl]

@inducer I closed it the intention of calling it "game over". The branch is still around, but rebasing this on inducer#56 is probably a pain and it's only going to get worse when we remove some of that manual event handling.

The stuff here can be done more progressively and in a backwards compatible way once inducer#56 is in, so that's the plan.

And if the latter: would it make sense to dump this into a draft PR in the upstream repo?

If you want, sure, but it's probably easier to just do it from scratch instead of resolving the conflicts :\

[inducer]

OK, thanks for explaining. Let's leave it here then.