Hey, What exact test did you do?
Well to be honest I've been wanting to swap in xxhash for a long time, but in my own profiling other things show up higher than murmur so I keep deprioritizing it :) One big problem with the hash algo is mc keys can be short and are hashed one at a time. xxhash is more optimized for longer data (kilobytes to megabytes). The original author tries to address this with an updated algorithm: https://fastcompression.blogspot.com/2019/03/presenting-xxh3.html xxhash makes significant use of instruction parallelism, such that if a key is 8 bytes or less you could end up waiting for the pipeline more than murmur. Other algos like cityhash/farmhash are better at short keys IIRC. Also xx's 32bit algo is a bit slower on 64bit machines... so if I wanted to use it I was going to test both 32bit and 64bit hashes and then have to do compile time testing to figure out which to use. It's also heavily x86 optimized so we might have to default something else for ARM. Sorry, not debated on the list, just in my own head :) It's not quite as straightforward as just dropping it in. If you're willing to get all the conditions tested go nuts! :) -Dormando On Sat, 16 Mar 2019, eamonn.nugent via memcached wrote: > Hi there, > I started using memcached in prod a week or two ago, and am loving it. I > wanted to give back, and took a look through the issues board, > but most of them looked solved. So, in my usual "it's never fast enough" > style, I went and profiled its performance, and had some fun. > > After seeing that MurmurHash3 was taking a good amount of the execution time, > I decided to run a test integrating one of my old favorite > hash functions, xxhash. My guess is that Memcached could benefit from using > the hash function, as it is faster than MMH3 and has several > native variants. I ran some of my own tests, and found roughly equal > performance, but with no tuning performed on xxhash. For example, > using an assembly (x86/arm/etc) version could likely speed up hashing, along > with properly implementing it in memcached. However, I was > also running this on a much older Nehalem CPU, so there could be unseen > advantages to one or both of the algorithms by running them on a > newer CPU. I'm in the process of fighting with my newer systems to get > libevent installed properly, so I'll report back with more > up-to-date tests later. > > I did a cursory search, but didn't find any mention of the algo in the > mailing list. If this has been discussed, though, apologies for > bringing it up again. On the other hand, I would be happy to write a PR to > add it, using the `hash_algorithm` CLI arg. > > Thanks, > Eamonn > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to memcached+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
