On 03/14/2015 08:08 PM, Coda Highland wrote: > I've worked on an ARM system with a crypto coprocessor that did CRC > slower in HW than in SW unless you were checksumming huge amounts of > data. It's not often as big of a win as it sounds. Sure, you need to probe for it. For Core 2 style processors the win is 29.78 vs 46.80 cycles/hash for 10-byte keys. Murmur needs 30, FNV 40 cycles. The win is bigger the larger the keys are. Only a super-simple sdbm-like hash is faster, but leads to more collisions. For more security and optimizations I would recommend https://github.com/lemire/StronglyUniversalStringHashing (Paper: http://arxiv.org/abs/1202.4961) > On Sat, Mar 14, 2015 at 11:20 AM, Юрий Соколов <funny.falcon@xxxxxxxxx> wrote: >> May be cause not all cpu have such instruction? Not all servers and desktop >> have latest Intel cpu and even later Amd. company i work in has hundreds of >> servers old enough to have no crc32c instruction. >> >> 14.03.2015 16:17 пользователь "Reini Urban" <reini@xxxxxxxxxx> написал: >>> >>> On 03/14/2015 01:27 PM, Юрий Соколов wrote: >>>> https://gist.github.com/funny-falcon/f36851422ab05475d6fd >>>> >>>> It is evolution of khash design. >>> >>> Nice. >>> >>> But why is still nobody using the faster and better iSCSI CRC32-C hash >>> function which is builtin into hardware on modern intel processors for a >>> decade or now also armv7. You cannot beat 5 cycles and the much better >>> characteristics of CRC32-C vs. fnv, murmur or city. >>> >>> Implementation e.g. at >>> https://github.com/rurban/smhasher/blob/master/crc32_hw.c >>> >>> It is also in some zlib libs, which is better for larger keys >>> (threaded). Not on macports though. >>> You really need to probe for a zlib with HW CRC support. >>> >>> >> > [Disclaimer: The views expressed in this letter are my own, and do not represent those of my employer.] -- Reini Working towards a true Modern Perl. Slim, functional, unbloated, compile-time optimizable
Attachment:
signature.asc
Description: OpenPGP digital signature
