Re: [boost] Any interest in Compile Time Hash Containers library?

Subject: Re: [boost] Any interest in Compile Time Hash Containers library?
From: John Maddock (jz.maddock_at_[hidden])
Date: 2019-01-24 08:49:24

While I don't personally have a use for it, I can see that someone will, 
and besides, it's kind of cool that you can do that ;)

Question: would the interface be better specified with a constexpr 
initializer-list constructor rather than templating on an array of 
data?  That way you would have complete control of memory layout as 
well?  Or am I misinterpreting things?

Best, John.

On 21/01/2019 13:39, Ivan Matek via Boost wrote:
> Hi everybody, my first message, I hope I do not mess this up.
>
> I was contemplating writing a Compile Time Hash Containers library and I
> wrote a test implementation for sets and benchmarked it against mostly
> ska:: sets since they are the best.
>
> Document is here:
>
> https://docs.google.com/document/d/1IsUiWl3K0h2pgttYgMt67CxgJ3zeXBKZEA7hvAQ5JcY/
>
> It is quite long, but it aims to provide a introduction to the problem for
> people unfamiliar with details of hashing, and also it goes into a lot of
> discussions, if you care just about the numbers you can skip the "boring
> parts".
>
> My interpretation of benchmarks is that it performs very well in some
> cases, decently in others, but I am biased. :)
>
> Code is not available online since I do not want to dump a test project
> online without extensive documentation, but if somebody has a problem that
> may be benefited by this test implementation feel free to let me know, I
> would be happy to get some real world feedback on prototype.
> Limitations is that test implementation only works for sets, so no maps and
> if your objects are not integers you will probably not get much speedup.
> Also if your set has more than 100ish items GCC will run out of memory and
> VC++ does not compile code at all, so clang is the only way for most use
> cases today.
>
> One more disclaimer is that I do not want this library to be some beast
> like ranges that takes years to implement, so if after reading the document
> you consider implementation quite basic I won't be offended :) In other
> words I feel that library like this although relatively simple compared to
> regular Boost libraries can provide quite a lot of benefit for some
> usecases where people really really care about performance of hash
> containers where values are known during compile time.
>
> I know you can not predict the future of an unimplemented library, but I
> would be happy with some general feedback, and if you think this library
> would be nice boost proposal I would be interested in some pointers wrt how
> to proceed.
>
> If somebody wonders how user code looks at the moment:
>
> #include "cxhash_set.h"
> // also could be a result of constexpr function, no need for initializer
> list
> static constexpr std::array<int, 20>
> ints{0,1,2,3,5,8,21,34,64,128,256,512,1024,1701,1729,2048,4096,12345,123456,1234567};
> int main()
> {
>      cxhash_set<ints> ints_set;
>      // contains could(should be?) static, but for now it is "normal" member
> fn
>      std::cout << std::boolalpha << ints_set.contains(21) << std::endl;
>      std::cout << std::boolalpha << ints_set.contains(22) << std::endl;
> }
>
> P.S. feel free to comment in the google doc, I actually find mailing lists
> quite limited when it comes to prolonged and or detailed discussions.
> Maybe we can ping Alexandrescu for an instance of dlang forums, so we get a
> better discussion tools, and he gets a way to convert us to D. :)
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus