<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Jul 17, 2016 at 1:54 PM Arthur O'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Given that this patch is basically Chandler's talk from CppCon 2015 (<a href="https://www.youtube.com/watch?v=nXaxk27zwlk" target="_blank">https://www.youtube.com/watch?v=nXaxk27zwlk</a>), I'm surprised that the commit message isn't explicitly mentioning that; and surprised that Chandler himself isn't weighing in on either the "this is a good idea" or "this is a bad idea" side.</div></blockquote><div><br></div><div>FWIW, I don't follow all of these commits that closely. ;] I didn't know about this until you CC'ed me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br><div>IMHO, if replacing "%" with "fastmod" in general-purpose code like this were a good idea,</div><div>(A) libc++ should introduce a helper function __fastmod(m,n) for the purpose, not repeat the same patch everywhere there's currently a "%" operator; and/or</div><div>(B) someone with authority over the Clang x86 backend (*cough*Chandler*cough*) should look into improving the codegen for "%" by auto-detecting when it might make sense to use this heuristic.</div></div></div></blockquote><div><br></div><div>FWIW, I'm much more interested in the compiler doing this than in source code doing this if there is a general desire to do this kind of thing.</div><div><br></div><div>However, In the specific case of hash tables I can't say I really care. That is because I believe it is a serious mistake to use non-mixed hash functions and prime sized tables where the modulo is a significant cost. Instead, I would very much like to see C++ move toward hash functions which always mix well (pass avalanche tests, etc) and power-of-two size tables where this becomes a mask rather than a modulo operation, and thus dramatically faster.</div><div><br></div><div>My two cents, should it matter to folks in the future. None of this I think changes the reasonable short-term goals Eric is working on -- a change of this magnitude would be quite separate.</div><div><br></div><div>-Chandler</div></div></div>