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

add Tree implementation #694

Closed
wants to merge 14 commits into from
Closed

add Tree implementation #694

wants to merge 14 commits into from

Conversation

matthiasdiener
Copy link
Collaborator

based on #350 / #690

@inducer
Copy link
Owner

inducer commented Oct 18, 2022

The authorship information on the commits is incorrect. For the tree, this should show Kaushik as the author, and you as the committer. For the tests, that should show you as the author, i.e. you need a minimum of two commits.

@matthiasdiener
Copy link
Collaborator Author

The authorship information on the commits is incorrect. For the tree, this should show Kaushik as the author, and you as the committer. For the tests, that should show you as the author, i.e. you need a minimum of two commits.

I think this should be fixed now.

@matthiasdiener
Copy link
Collaborator Author

This is ready for review

@@ -0,0 +1,269 @@
__copyright__ = "Copyright (C) 2022 Kaushik Kulkarni"
Copy link
Owner

Choose a reason for hiding this comment

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

It's hard for me to see here how this was changed vs. the original.

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've split up the commits into Kaushik's original implementation (7f50179), followed by my changes on top of that initial commit. Does that make the changes clearer?

Copy link
Owner

Choose a reason for hiding this comment

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

Thanks!

@inducer
Copy link
Owner

inducer commented Aug 19, 2024

I will absorb this into #785, closing here.

@inducer inducer closed this Aug 19, 2024
inducer added a commit to a-alveyblanc/loopy that referenced this pull request Aug 19, 2024
inducer#694

Co-authored-by: Matthias Diener <mdiener@illinois.edu>
Co-authored-by: Andreas Kloeckner <inform@tiker.net>
@matthiasdiener matthiasdiener deleted the tree branch August 20, 2024 18:26
@matthiasdiener
Copy link
Collaborator Author

If you want, you can also cherry-pick the memoization PR we are using in our production version: illinois-ceesd@e886189 (illinois-ceesd#4).

@@ -164,34 +164,31 @@ def replace_node(self, node: NodeT, new_id: NodeT) -> "Tree[NodeT]":

# {{{ update child to parent

new_child_to_parent = (self._child_to_parent.delete(node)
.set(new_id, parent))
child_to_parent_mut = self._child_to_parent.mutate()
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Because of mutate, this now requires the use of immutables.Map. Could you just use a normal dict for the mutation?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Since the internal immutables.Maps don't seem to be exposed to the user, maybe it is sufficient to just use dict everywhere in this class?

Copy link
Owner

Choose a reason for hiding this comment

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

With dict, $O(N)$ modifications of size $O(1)$ of a tree of size $O(N)$ lead to $O(N^2)$ complexity. immutables allows this to remain $O(N)$ (give or take a few $O(\log N)$. So, to my mind, this is the one use case of which I'm aware, where the use of immutables is justified (whereas just about everywhere else, it's just a glorified read-only dict, which is total overkill).

@inducer
Copy link
Owner

inducer commented Aug 20, 2024

If you want, you can also cherry-pick the memoization PR we are using in our production version: illinois-ceesd@e886189 (illinois-ceesd#4).

Could you talk about how important those are in terms of cost?

@matthiasdiener
Copy link
Collaborator Author

If you want, you can also cherry-pick the memoization PR we are using in our production version: illinois-ceesd@e886189 (illinois-ceesd#4).

Could you talk about how important those are in terms of cost?

We had seen a ~5% speedup of overall compile time with that PR on a prediction run.

inducer added a commit that referenced this pull request Aug 24, 2024
#694

Co-authored-by: Matthias Diener <mdiener@illinois.edu>
Co-authored-by: Andreas Kloeckner <inform@tiker.net>
inducer added a commit that referenced this pull request Aug 24, 2024
#694

Co-authored-by: Matthias Diener <mdiener@illinois.edu>
Co-authored-by: Andreas Kloeckner <inform@tiker.net>
@inducer
Copy link
Owner

inducer commented Aug 24, 2024

I'll add those.

inducer added a commit that referenced this pull request Aug 25, 2024
#694

Co-authored-by: Matthias Diener <mdiener@illinois.edu>
Co-authored-by: Andreas Kloeckner <inform@tiker.net>
inducer added a commit that referenced this pull request Aug 25, 2024
#694

Co-authored-by: Matthias Diener <mdiener@illinois.edu>
Co-authored-by: Andreas Kloeckner <inform@tiker.net>
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