On 22.05.2012 21:01, Stefan Fuhrmann wrote: > Am 21.05.2012 12:38, schrieb Julian Foad: >> Stefan Fuhrmann wrote: >>> Julian Foad wrote: >>>>> URL:http://svn.apache.org/viewvc?rev=1333326&view=rev >>>>> Introduce private API functions that wrap apr_hash_make_custom >>>>> and return hash tables that are 2 to 4 times faster than the >>>>> APR default. >>>> Would it be sensible to propose these (the hash-functions) for >>>> inclusion in APR itself? >>> Certainly. The question would be whether Apache is >>> meant to run on CPUs without a decent MUL. >> I don't understand why that question is relevant. > > APRs implementation uses 33 as multiplier which > can conveniently be implemented as shift & add. > My code uses factors up to 33^4 where that > optimization / workaround would no longer be > useful. A non-pipelined MUL operation may take > as much as 40 ticks (i386) instead of 2 .. 6 ticks for > shift&add.
I'd really like to see you explain why this change of yours (33 -> 33^4) is relevant in practice. It's not at all clear that this multiplier gives a better key distribution than the time-honoured 33. It's my considered opinion that this fiddling around with hash function implementations is way overboard. Just use apr_hashfunc_default already. Unless you can prove that using your "optimized" version results in siginificant savings in space and/or time, anything else is just piling on more lines of code that need to be maintained for no good reason. -- Brane
