[llvm-dev] Default hashing function for integers (DenseMapInfo.h)

[Bruce Hoult via llvm-dev]

llvm is not multithreaded.

On Tue, Jan 10, 2017 at 6:35 PM, Francois Fayard via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> > It is not clear what the test-case is (what source, what compiler
> options). My suspicion is that your differences are in the noise, and most
> of the time is spent doing other things than hashing. Did you profile the a
> run, and check how much of the total time is spent in the hash-function
> [you may need to tweak the code a bit to not inline the actual hash
> function]. Also publishing the RANGE for each set of tests, since the
> variation between "best and worst" may be more important than the overall
> best time.
>
> I agree that I did not present a clear test case, which was just a random
> .cpp file that benchmarks different hash tables from LLVM/Google/STL
> compiled with -O3 option. I’ll try to make it better tomorrow, but I can
> assure you that it was not the noise. I have disabled turboboost and
> hyper-threading on my machine and ran the benchmark 10 times for every test
> and the difference was way larger than the observed standard deviation. But
> anyway, for the time being, the winner for hashing pointers is the current
> one from of LLVM.
>
> > Counting the number of collisions or some such would probably also help.
>
> Yes, I could do that. If I want to report all the collision, I might do
> that in the destructor of DenseMap. Sorry for my ignorance, but is
> clang/llvm multithreaded? Is it safe to write to a file in a destructor for
> logging purposes?
>
> François Fayard
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170110/84c6b5ed/attachment.html>