Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Good hash for pointers Date: Sat, 15 Jun 2024 20:32:23 -0700 Organization: A noiseless patient Spider Lines: 71 Message-ID: <86h6dtlfzs.fsf@linuxsc.com> References: <86fru6gsqr.fsf@linuxsc.com> <8634q5hjsp.fsf@linuxsc.com> <86le3wfsmd.fsf@linuxsc.com> <86ed9ofq14.fsf@linuxsc.com> <20240605005916.00001b33@yahoo.com> <86le3dlh24.fsf@linuxsc.com> <20240610151453.000027ef@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sun, 16 Jun 2024 05:32:24 +0200 (CEST) Injection-Info: dont-email.me; posting-host="582f9e6093daba5cc619f698edf5f43e"; logging-data="4066624"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+N1rRE3JF0S74g629cFlkrAmyJeHUvKVE=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:I4eu715dlzXTfueqCBoEV8gTOJ8= sha1:evYFbKlOpiAEa/WG65G7d26lEVw= Bytes: 4395 Michael S writes: > On Sun, 09 Jun 2024 18:31:15 -0700 > Tim Rentsch wrote: > >> Malcolm McLean writes: >> >>> On 09/06/2024 12:35, Bonita Montero wrote: >>> >>>> uint64_t MichaelsHash( uint64_t key ) >>>> { >>>> __m128i xkey = _mm_set_epi64x( key, 42 ); >>>> using bar_t = pair; >>>> static bar_t const bars[8] = >>>> { >>>> { 0xBB09BBCC90B24BF2, 0x825C622FF2792A01 }, >>>> { 0x94F0535CB06D4060, 0x939C756246DBFD1D }, >>>> { 0x5B835E01A7E14CA1, 0xAC2BDAFC023CDD06 }, >>>> { 0xE0B6A4735B774AEC, 0x9CAFB43E7DDE494C }, >>>> }; >>>> for( bar_t const &bar : bars ) >>>> xkey = _mm_aesenc_si128( xkey, _mm_set_epi64x( bar.second, >>>> bar.first ) ); >>>> return xkey.m128i_u64[0]; >>>> } >>>> >>>> Now the code is about six times faster and I get a eight times >>>> speedup over single-threaded processing with the same code. Of >>>> course the results are still the same. >>> >>> I have your permission to drop that in? >> >> Note that this code was cribbed from Michael S. > > I don't permit to use my name in variant, modified by Bonita. > I prefer if my name is not used even on my own variant. > This code was never intended for production use. It is intended for use > as reference, as something that is "certainly random enough and then > many billions times more than enough". It is much much slower than > necessary for non-crypto hash. [...] The problem with using the posted AES code (of either version) is that it is not sufficiently portable nor does it comply with C90 rules. How fast or slow the code runs might be a reason not to use it, but it is not necessarily a reason not to use it - that depends on a variety of factors, not the least of which is how fast it actually is in the environments under consideration. >> If you >> think it's important to ask permission, I think he is >> the one you should be asking. >> >> By the way, I thought you were looking for code that works >> in standard C, and acceptable under C90 rules. Have you >> changed your mind about that? The code above is a far >> cry from C, let alone C90. > > Exactly. > I think that all methods that are both good and fast rely on 64-bit > unsigned integer arithmetic. And it seems to me that C90 does not > provide it in portable manner. > So, under portable C90 constraints one has to choose between good and > fast. I am confident that C90 can support defining a suitable hash function portable to any system that has a C90 implementation appropriate to that system's environment. That said, unless some sort of objective measure is given for the terms good and fast, the last quoted sentence is pretty much meaningless.