User customizable collection with GAT - #33
Conversation
|
I think we could simplify this so I removed fnv as well. This means hashbrown for no_std, and std hash for normal circumstances. Almost zero change in code surface |
|
The reason I also added heapless because I want to run it on the context of extreme environment like in a smart contract kernel where we can't afford to have dynamic memory allocation, I also want to experiment this on GPU using rust-cuda as well, and memory allocation is not recommended on GPU programming. |
|
Interesting, thanks so much for your contribution! This looks really thoughtfully implemented but I'm not sure I can review all the code at this time as it's a bit of a rewrite in scale / quantity. If you have a fork though, happy to publicize it in the README as an alternative. |
I needed this because I'm writing a C compiler and I want to use a new approach to the type checking & semantic analysis part of it. Basically, if I can encode the types as constraints, then we can use something like prolog to find violation and even things like strict aliasing rather than pumping out a manual check with memory boundaries every time.
However that compiler is written in no_std first approach and so I cannot guarantee that std hash collection is always there. So instead I think we should inverse the control
Interesting findings: I added a benchmark and noticed that std collection hash map/hash set is significantly slower than hashbrown hash map/hash set, and hashbrown is also significantly slower than fnv when the collection gets larger. That's also a reason we want to introduce user customizable collection because the default hash map performance sucks