-
Notifications
You must be signed in to change notification settings - Fork 181
Improve Int{Map,Set} construction from asc lists #1123
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
That allocated number for IntSet is strangely high. Logically, the fusion and non-fusion cases should have the same allocations, like IntMap does. I'll check what's happening. Edit: Updated the description so preserving the old results here:
|
So here's what's happening. First, Show Core
But the one in the benchmark loop isn't as good. Show Core
The Then I realized that But wait, why does tasty-bench specialize the loop at all? This doesn't seem desirable for benchmarking, you would instead want it to not specialize, and apply the unknown function to the unknown argument every iteration. I'll open an issue on tasty-bench to see if there's a reason for this. |
Double wacky. |
Did you play around with |
Yes, it did not help sadly. I've made it NOINLINE in the benchmarks for now. tasty-bench issue: Bodigrim/tasty-bench#66 |
@treeowl any comments? |
af7981f
to
418f96a
Compare
* Switch to an explicit stack based approach, like we had before 77c8e5f, and like we have for Set and Map today. * This is a little faster (-13%) on in-memory lists, but much faster (-43%) when list fusion applies because we are now a good consumer. For a dense IntSet in the fusion case it is greatly faster (-81%). * Avoid a case of undefined behavior in IntMap.fromDistinctAscList due to calling branchMask on equal keys if the caller did not follow the distinct precondition. * Add property tests for the functions
418f96a
to
319d0b9
Compare
Alright, merging. |
Closes #951
Benchmarks on GHC 9.10.1:
IntSet:
IntMap: