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

MNT: Move constructors to a direct style #773

Merged
merged 4 commits into from
Sep 16, 2024
Merged

MNT: Move constructors to a direct style #773

merged 4 commits into from
Sep 16, 2024

Conversation

mtsokol
Copy link
Collaborator

@mtsokol mtsokol commented Sep 12, 2024

Hi @hameerabbasi,

This PR moves MLIR constructors to the direct style (with: sparse-assembler{direct-out=true}).
I think it's more concise with this approach - _constructors.py LOC reduced by 50%, to 250.

Now all Tensors created from NumPy arrays or SciPy sparse arrays are owned and freed by the python side.

The ones that are results of MLIR ops (like add right now) are allocated by MLIR and owns_memory in Tensor class is set to False.

I haven't figured out yet how to correctly free MLIR allocated memrefs, (tried with libc.free) as I think there's still a memory leak after sparse.add(tensor_a, tensor_b).

@mtsokol mtsokol self-assigned this Sep 12, 2024
Copy link
Collaborator

@hameerabbasi hameerabbasi left a comment

Choose a reason for hiding this comment

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

Thanks @mtsokol! LGTM so far!

  1. Let's make all members of Tensor private.
  2. Let's store a list of free-able memref strs. So, for example, in to_sps let's store ["data"] for dense, then we will need to call libc.free on data.allocated. This will apply when we take ownership from MLIR only.
  3. We need to store a reference to NumPy/SciPy objects when we create Tensors from them, as we were doing before. The pattern for _hold_self_ref_in_ret will apply still in this case, except we can just use Tensor._base which can be the SciPy or NumPy object, or None.

Copy link

codspeed-hq bot commented Sep 12, 2024

CodSpeed Performance Report

Merging #773 will degrade performances by 51.96%

Comparing direct-style (ef3e62e) with main (47b246b)

Summary

❌ 2 (👁 2) regressions
✅ 338 untouched benchmarks

Benchmarks breakdown

Benchmark main direct-style Change
👁 test_index_fancy[side=100-rank=1-format='coo'] 680 µs 1,415.4 µs -51.96%
👁 test_index_slice[side=100-rank=2-format='gcxs'] 2.2 ms 2.5 ms -12.61%

@mtsokol
Copy link
Collaborator Author

mtsokol commented Sep 16, 2024

@hameerabbasi I applied all your review comments.

Copy link
Collaborator

@hameerabbasi hameerabbasi left a comment

Choose a reason for hiding this comment

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

A simplification to the memory logic: We can do most of this in __del__, check for self._owns_memory and then call libc.free on the constituent memrefs if so.

Copy link
Collaborator

@hameerabbasi hameerabbasi left a comment

Choose a reason for hiding this comment

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

Thanks for the 🥚-cellent work, @mtsokol! LGTM.

@hameerabbasi hameerabbasi enabled auto-merge (squash) September 16, 2024 12:47
@hameerabbasi hameerabbasi merged commit f97fa03 into main Sep 16, 2024
17 checks passed
@hameerabbasi hameerabbasi deleted the direct-style branch September 16, 2024 14:59
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.

2 participants