Transition to arraycontext

[alexfikl]

Get sumpy on array contexts as well! This eats up the first commit from #118.

Porting individual files

• Pass tests!
  • test_codegen
  • test_cse
  • test_distributed
  • test_fmm
  • test_kernels
  • test_matrixgen
  • test_misc
  • test_qbx
  • test_tools
• Port examples!
  • curve-pot
  • curve
  • expansion-toys
  • fourier
  • sym-exp-complexity

Remaining porting issues

• Move caching to the array context from KernelCacheMixin.
• Handle kernel optimizations.
  • Currently it uses get_cached_executor(), which branches on OPT_ENABLED, but we need to move to actx.call_loopy.
  • Move to transform_loopy_program? Would need to also add some fancy tags or something to customize it?
• Need to move e.g. register_optimization_preambles to the array context somehow too.
  • The kernels no longer have a context or device, so they can't do that.
  • Probably need to move this to actx.transform_loopy_program somehow?

Upstream / downstream PRs

• Depends on Transition to arraycontext boxtree#56
• Depends on Fix TranslationUnit._hash_value disappearing during pickling loopy#677
• Depends on: Updated sumpy and boxtree to arraycontext branches pytential#179

Speculative TODOs

• Should some classes clone the actx? Here e.g. SumpyTreeIndependentDataForWrangler but also in boxtree.
  • The big worry is that cloning throws away any caches on the actx.
  • Pretty much all *Builder classes can be functions + all other memoized kernels can be functions, but should leave that for later since it can be done without breaking the world.
• Rip out the timing stuff (not sure, just mentioned by @inducer at some point).
  • This would also need to be done in boxtree?
• Add an array context to do the timing stuff? (likely for a future PR)

[isuruf]

Hmm. What's the recommended way to get the timing data?

[alexfikl]

Not quite sure. I briefly talked about that with @inducer and it should be baked into the array context somehow so it doesn't clutter the wrangler interface.

However, that probably needs a bit of effort to get back into a working state, so not quite sure what a timeline would be..

[alexfikl]

Just to write out some questions about that to get an idea (from you and @inducer). I don't really use it so this has been a brutal delete sort of thing..

• Do you rely on that interface to get results?
• Can this be merged without it?
• Who's going to do the work to put it back? 😢

[isuruf]

Do you rely on that interface to get results?

Yes, I use it to get results for a paper.

Who's going to do the work to put it back?

I can try if there's an outline of how to reintroduce it. I have not much experience on arraycontexts, so I have no idea what needs to be done.

[alexfikl]

I can try if there's an outline of how to reintroduce it. I have not much experience on arraycontexts, so I have no idea what needs to be done.

Yeah, I don't have a good overview either, so that probably needs some discussion. There's a profiling array context here
https://github.com/illinois-ceesd/mirgecom/blob/f9cf0f3557b7d5c89f58e8362ebf50820261219f/mirgecom/profiling.py
but not sure if a similar interface will work for gathering timings on the FMM.

Yes, I use it to get results for a paper.

Ok, then definitely either revert or hold off on merging.

At the moment, the timing code and the manual event handling are not particularly compatible with the arraycontext stuff (as it is) and removing both is pretty breaking.