Towards array context (2025 merge)

[inducer]

Resumed from #139.

---

Relevant parts of summary from #139 follow:

Remaining porting issues

• Move caching to the array context from KernelCacheMixin. (now Move caching to the array context from KernelCacheMixin #257)
• Handle kernel optimizations. (now Rewire how kernel optimizations work #258(
  • 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. (now also Rewire how kernel optimizations work #258)
  • 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? (now Make an array context to handle timing #259)

[inducer]

FYI: As in boxtree, I've moved towards annotating with ArrayContext instead of PyOpenCLArrayContext. I like that direction because it conveys the ambition (cough) that all this will work with any actx. It also prevents having to splatter actx-type asserts everywhere downstream. If you hate it, it's a single commit that could be unwound.

[inducer]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

[alexfikl]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

Definitely! I'm fine with continuing the work here too, whatever's more convenient.

[inducer]

Uh-oh. I think I may have force-pushed over two commits of yours just now:

Do you still have those? Could you reapply them?

[alexfikl]

Do you still have those? Could you reapply them?

Done! 😁

EDIT: I think the pytential job is confused because we're now pointing to boxtree main?

[inducer]

Resumed from #139.

---

Relevant parts of summary from #139 follow:

Remaining porting issues

• Move caching to the array context from KernelCacheMixin. (now Move caching to the array context from KernelCacheMixin #257)
• Handle kernel optimizations. (now Rewire how kernel optimizations work #258(
  • 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. (now also Rewire how kernel optimizations work #258)
  • 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? (now Make an array context to handle timing #259)

[inducer]

FYI: As in boxtree, I've moved towards annotating with ArrayContext instead of PyOpenCLArrayContext. I like that direction because it conveys the ambition (cough) that all this will work with any actx. It also prevents having to splatter actx-type asserts everywhere downstream. If you hate it, it's a single commit that could be unwound.

[inducer]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

[alexfikl]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

Definitely! I'm fine with continuing the work here too, whatever's more convenient.

[inducer]

Uh-oh. I think I may have force-pushed over two commits of yours just now:

Do you still have those? Could you reapply them?

[alexfikl]

Do you still have those? Could you reapply them?

Done! 😁

EDIT: I think the pytential job is confused because we're now pointing to boxtree main?

[inducer]

Resumed from #139.

---

Relevant parts of summary from #139 follow:

Remaining porting issues

• Move caching to the array context from KernelCacheMixin. (now Move caching to the array context from KernelCacheMixin #257)
• Handle kernel optimizations. (now Rewire how kernel optimizations work #258(
  • 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. (now also Rewire how kernel optimizations work #258)
  • 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? (now Make an array context to handle timing #259)

[inducer]

FYI: As in boxtree, I've moved towards annotating with ArrayContext instead of PyOpenCLArrayContext. I like that direction because it conveys the ambition (cough) that all this will work with any actx. It also prevents having to splatter actx-type asserts everywhere downstream. If you hate it, it's a single commit that could be unwound.

[inducer]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

[alexfikl]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

Definitely! I'm fine with continuing the work here too, whatever's more convenient.

[inducer]

Uh-oh. I think I may have force-pushed over two commits of yours just now:

Do you still have those? Could you reapply them?

[alexfikl]

Do you still have those? Could you reapply them?

Done! 😁

EDIT: I think the pytential job is confused because we're now pointing to boxtree main?

[inducer]

Resumed from #139.

---

Relevant parts of summary from #139 follow:

Remaining porting issues

• Move caching to the array context from KernelCacheMixin. (now Move caching to the array context from KernelCacheMixin #257)
• Handle kernel optimizations. (now Rewire how kernel optimizations work #258(
  • 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. (now also Rewire how kernel optimizations work #258)
  • 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? (now Make an array context to handle timing #259)

[inducer]

FYI: As in boxtree, I've moved towards annotating with ArrayContext instead of PyOpenCLArrayContext. I like that direction because it conveys the ambition (cough) that all this will work with any actx. It also prevents having to splatter actx-type asserts everywhere downstream. If you hate it, it's a single commit that could be unwound.

[inducer]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

[alexfikl]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

Definitely! I'm fine with continuing the work here too, whatever's more convenient.

[inducer]

Uh-oh. I think I may have force-pushed over two commits of yours just now:

Do you still have those? Could you reapply them?

[alexfikl]

Do you still have those? Could you reapply them?

Done! 😁

EDIT: I think the pytential job is confused because we're now pointing to boxtree main?

[inducer]

Resumed from #139.

---

Relevant parts of summary from #139 follow:

Remaining porting issues

• Move caching to the array context from KernelCacheMixin. (now Move caching to the array context from KernelCacheMixin #257)
• Handle kernel optimizations. (now Rewire how kernel optimizations work #258(
  • 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. (now also Rewire how kernel optimizations work #258)
  • 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? (now Make an array context to handle timing #259)

[inducer]

FYI: As in boxtree, I've moved towards annotating with ArrayContext instead of PyOpenCLArrayContext. I like that direction because it conveys the ambition (cough) that all this will work with any actx. It also prevents having to splatter actx-type asserts everywhere downstream. If you hate it, it's a single commit that could be unwound.

[inducer]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

[alexfikl]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

Definitely! I'm fine with continuing the work here too, whatever's more convenient.

[inducer]

Uh-oh. I think I may have force-pushed over two commits of yours just now:

Do you still have those? Could you reapply them?

[alexfikl]

Do you still have those? Could you reapply them?

Done! 😁

EDIT: I think the pytential job is confused because we're now pointing to boxtree main?

[inducer]

Resumed from #139.

---

Relevant parts of summary from #139 follow:

Remaining porting issues

• Move caching to the array context from KernelCacheMixin. (now Move caching to the array context from KernelCacheMixin #257)
• Handle kernel optimizations. (now Rewire how kernel optimizations work #258(
  • 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. (now also Rewire how kernel optimizations work #258)
  • 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? (now Make an array context to handle timing #259)

[inducer]

FYI: As in boxtree, I've moved towards annotating with ArrayContext instead of PyOpenCLArrayContext. I like that direction because it conveys the ambition (cough) that all this will work with any actx. It also prevents having to splatter actx-type asserts everywhere downstream. If you hate it, it's a single commit that could be unwound.

[inducer]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

[alexfikl]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

Definitely! I'm fine with continuing the work here too, whatever's more convenient.

[inducer]

Uh-oh. I think I may have force-pushed over two commits of yours just now:

Do you still have those? Could you reapply them?

[alexfikl]

Do you still have those? Could you reapply them?

Done! 😁

EDIT: I think the pytential job is confused because we're now pointing to boxtree main?

[inducer]

Resumed from #139.

---

Relevant parts of summary from #139 follow:

Remaining porting issues

• Move caching to the array context from KernelCacheMixin. (now Move caching to the array context from KernelCacheMixin #257)
• Handle kernel optimizations. (now Rewire how kernel optimizations work #258(
  • 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. (now also Rewire how kernel optimizations work #258)
  • 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? (now Make an array context to handle timing #259)

[inducer]

FYI: As in boxtree, I've moved towards annotating with ArrayContext instead of PyOpenCLArrayContext. I like that direction because it conveys the ambition (cough) that all this will work with any actx. It also prevents having to splatter actx-type asserts everywhere downstream. If you hate it, it's a single commit that could be unwound.

[inducer]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

[alexfikl]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

Definitely! I'm fine with continuing the work here too, whatever's more convenient.

[inducer]

Uh-oh. I think I may have force-pushed over two commits of yours just now:

Do you still have those? Could you reapply them?

[alexfikl]

Do you still have those? Could you reapply them?

Done! 😁

EDIT: I think the pytential job is confused because we're now pointing to boxtree main?

[inducer]

Resumed from #139.

---

Relevant parts of summary from #139 follow:

Remaining porting issues

• Move caching to the array context from KernelCacheMixin. (now Move caching to the array context from KernelCacheMixin #257)
• Handle kernel optimizations. (now Rewire how kernel optimizations work #258(
  • 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. (now also Rewire how kernel optimizations work #258)
  • 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? (now Make an array context to handle timing #259)

[inducer]

FYI: As in boxtree, I've moved towards annotating with ArrayContext instead of PyOpenCLArrayContext. I like that direction because it conveys the ambition (cough) that all this will work with any actx. It also prevents having to splatter actx-type asserts everywhere downstream. If you hate it, it's a single commit that could be unwound.

[inducer]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

[alexfikl]

FYI2: The local tests are now passing here, so maybe this can become #139? (I.e. I would push this code there?) Does that sound OK?

Definitely! I'm fine with continuing the work here too, whatever's more convenient.

[inducer]

Uh-oh. I think I may have force-pushed over two commits of yours just now:

Do you still have those? Could you reapply them?

[alexfikl]

Do you still have those? Could you reapply them?

Done! 😁

EDIT: I think the pytential job is confused because we're now pointing to boxtree main?