Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PytatoArrayContext.freeze: support container freezes #158

Merged
merged 3 commits into from
Jun 9, 2022

Conversation

kaushikcfd
Copy link
Collaborator

@kaushikcfd kaushikcfd commented May 1, 2022

Freezing across containers can potentially re-use common sub-expressions.

Draft because:

  • Pass CI by correctly pointing the meshmode branch in the downstream CI.
  • DROP final commit before merge

@@ -533,6 +533,9 @@ def freeze(

See :meth:`ArrayContext.thaw`.
"""
if actx is not None and actx.supports_freezing_containers:
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should just deprecate these then (and expect all array contexts to support container freezes).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that the freeze logic is specific to the containers (freeze is a single-dispatch function), deprecating this won't be possible.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should also be added to meshmode.dof_array then?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a side note, I really don't recall why we made this singledispatch-ed and can't think of a reason for it now. Anyone remember something?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't. Array container freeze seems completely generic.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't recall why we made this singledispatch-ed and can't think of a reason for it now. Anyone remember something?

IIUC, array container initialization might be specific to the container type, and instead of forcing any constructor API we ask the container's writer to also provide a freeze. For example, DOFArray takes in a .array_context argument during initialization that must be set to None on getting frozen.

This should also be added to meshmode.dof_array then?

Yep!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, array container initialization might be specific to the container type, and instead of forcing any constructor API we ask the container's writer to also provide a freeze. For example, DOFArray takes in a .array_context argument during initialization that must be set to None on getting frozen.

And using deserialize_container doesn't work because the template arg isn't necessarily frozen. Hm.. annoying..

Thanks for the reminder!

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Revisiting this: given the new logic, I think we ought to just deprecate the stand-alone freeze in favor of actx.freeze. (same for thaw) I don't see a strong rationale for keeping them.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They do make it easy to just call freeze(container) as the actx is automatically inferred, if possible. If this is something that seems unnecessary, happy to deprecate it.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In view of #162, I'd prefer to reduce our dependence on these, so deprecating them now seems like a good move. I know that this is will be super noisy on the application end, but I think it's a necessary (if painful) step.

I'd welcome feedback though. (cc @MTCam)

arraycontext/container/traversal.py Outdated Show resolved Hide resolved
arraycontext/container/traversal.py Outdated Show resolved Hide resolved
@inducer
Copy link
Owner

inducer commented May 6, 2022

Discussed with @alexfikl a bit regarding the issue of how to set DOFArray.array_context to None as part of a context-driven freeze. While, at the time, we agreed that we should get rid of that attribute entirely (discussion in #162), but that's a total non-starter in the short term for the amount of breakcage it causes (and possibly in the long term, too).

So the second-best solution we came up with is to deprecate arraycontext.container.traversal.{freeze,thaw} and make them aliases of the respective methods in the array context (which are now defined to allow containers). In addition, introduce a new @singledispatch interface arraycontext.container.with_array_context (used by the array context's freeze and thaw) that returns a new array with the corresponding array context stored inside of it.

How does that sound?

@kaushikcfd
Copy link
Collaborator Author

How does that sound?

Yep, this sounds like a cleaner approach. I've implemented the suggestions, however back-compatibility seems challenging (unachievable?). For ex. meshmode needs inducer/meshmode#327.

@inducer
Copy link
Owner

inducer commented May 9, 2022

back-compatibility seems challenging (unachievable?).

Yep, that's understood. But IMO DOFArray is the only container affected (for now), so I think that's OK. This is fixing (papering over?) a genuine design mistake, so I'd rather deal with it than be locked into a dumb interface forever.

arraycontext/container/traversal.py Show resolved Hide resolved
arraycontext/container/traversal.py Show resolved Hide resolved
@@ -533,6 +533,9 @@ def freeze(

See :meth:`ArrayContext.thaw`.
"""
if actx is not None and actx.supports_freezing_containers:
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Revisiting this: given the new logic, I think we ought to just deprecate the stand-alone freeze in favor of actx.freeze. (same for thaw) I don't see a strong rationale for keeping them.

Copy link
Owner

@inducer inducer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! A few things to do here, but hopefully nothing onerous or disruptive. LGTM once these are take care of.

arraycontext/container/traversal.py Outdated Show resolved Hide resolved
@@ -533,6 +533,9 @@ def freeze(

See :meth:`ArrayContext.thaw`.
"""
if actx is not None and actx.supports_freezing_containers:
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In view of #162, I'd prefer to reduce our dependence on these, so deprecating them now seems like a good move. I know that this is will be super noisy on the application end, but I think it's a necessary (if painful) step.

I'd welcome feedback though. (cc @MTCam)

arraycontext/container/traversal.py Outdated Show resolved Hide resolved
@inducer
Copy link
Owner

inducer commented Jun 9, 2022

LGTM, thanks! Force-merging based on success of previous CI.

@inducer inducer merged commit b0d70e6 into inducer:main Jun 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants