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

Performance degradation when using compact instances #1740

Open
MoraruMaxim opened this issue Aug 9, 2024 · 4 comments
Open

Performance degradation when using compact instances #1740

MoraruMaxim opened this issue Aug 9, 2024 · 4 comments

Comments

@MoraruMaxim
Copy link

We tried to decrease the memory footprint of the FleCSI applications by using the Legion compact instances. This resulted in a huge slowdown (e.g. some of our applications have become 3 times slower).

If needed, I can potentially provide some profiling data.

@lightsighter
Copy link
Contributor

I think it would be helpful to describe the number of rectangles in your compact sparse instances and the access patterns (e.g. random access, linear walk, etc.).

I would also describe what kind of accessors you're using. I'm presuming MultiAffineAccessor which at the moment does not support spatial search to discover which piece is needed to access for a random access entry. Therefore unless you hit in the cache, access time looks more like O(N) instead of O(log N).

@apryakhin
Copy link
Contributor

I presume legion implements it's own spatial data structure somewhere? Realm I think builds a form of a kd-tree to optimize intersection testing. That should probably be packaged into some form of public data structure and used everywhere including accessors.

@apryakhin
Copy link
Contributor

This issue looks relevant:

@lightsighter
Copy link
Contributor

I presume legion implements it's own spatial data structure somewhere? Realm I think builds a form of a kd-tree to optimize intersection testing. That should probably be packaged into some form of public data structure and used everywhere including accessors.

Yes, #629 is somewhat relevant, but I don't think we need to expose the acceleration data structure here though. We just need to leverage it in this case for the multi-affine accessor class inside Realm. It would be good to use Realm's existing spatial acceleration data structure rather than rolling a new one. Although, really we should only be doing this if the number of rectangular pieces in the instance is "large" and a linear search over the pieces would be inefficient. It's unclear where that threshold is but it shouldn't be too hard to measure as it should be a property of the number of rectangles and not their shapes.

For now I've encouraged @MoraruMaxim to use Realm's compute covering utility to try to coarsen up his compact sparse instances into fewer pieces that still doesn't waste much memory.

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

No branches or pull requests

3 participants