- Notifications
You must be signed in to change notification settings - Fork 15
Compute translation_classes_data if not given #117
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
Conversation
2fde1ff to aa51f8d Compare | Thx! |
sumpy/fmm.py Outdated
| with cl.CommandQueue(self.tree_indep.cl_context) as queue: | ||
| translation_classes_data = SumpyTranslationClassesData(queue, | ||
| self.traversal) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this work? Doesn't the queue get destroyed when it exits the context manager leaving SumpyTranslationClassesData holding an invalid reference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the queue completes and gets destroyed, but the data itself doesn't get destroyed. i.e. the data has queue=None. When a new queue needs this data, they are accessed with .with_queue(queue)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lines 244 to 249 in a2c830a
| def __init__(self, queue, trav, is_translation_per_level=True): | |
| # FIXME: Queues should not be part of data. | |
| self.queue = queue | |
| self.trav = trav | |
| self.tree = trav.tree | |
| self.is_translation_per_level = is_translation_per_level |
Hm, but the constructor doesn't do any work. The actual work is being done when calling some of those memoized methods below, which should be after the context manager exits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests don't seem to crash and burn, so this is probably just some misunderstanding on my side. Hm..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, you are right. I guess since the constructor keeps a reference to the queue, it doesn't get destroyed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try to come up with a way to make PyOpenCL warn if a reference to the queue continues to be held past __exit__.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be really cool!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed the implementation to build the data objects eagerly instead of lazily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't speak for the eager vs lazy, but the queue stuff makes sense to me now 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| LGTM, thanks! |
Adds a
_disable_translation_classeshidden option so that we can check the non translation classes kernel.