Open Source at Google: Introducing CityHash

I'm not seeing any benchmarks: since they tout speed as a major selling point, that surprises me.<p>Edit: For instance, the blog post mentions being inspirsed by MurmurHash, which touts its performance on its site along with benchmarks (<a href="http://sites.google.com/site/murmurhash/" rel="nofollow">http://sites.google.com/site/murmurhash/</a>):<p><pre><code> OneAtATime - 354.163715 mb/sec FNV - 443.668038 mb/sec SuperFastHash - 985.335173 mb/sec lookup3 - 988.080652 mb/sec MurmurHash 1.0 - 1363.293480 mb/sec MurmurHash 2.0 - 2056.885653 mb/sec </code></pre> In fact, it looks like the author of MurmurHash also developed a test suite for hash functions which includes performance testing: <a href="http://code.google.com/p/smhasher/wiki/SMHasher" rel="nofollow">http://code.google.com/p/smhasher/wiki/SMHasher</a>

From <a href="http://code.google.com/p/cityhash/source/browse/trunk/src/city.h" rel="nofollow">http://code.google.com/p/cityhash/source/browse/trunk/src/ci...</a><p>// WARNING: This code has not been tested on big-endian platforms!<p>// It is known to work well on little-endian platforms that have a small penalty<p>// for unaligned reads, such as current Intel and AMD moderate-to-high-end CPUs.<p>//<p>// By the way, for some hash functions, given strings a and b, the hash<p>// of a+b is easily derived from the hashes of a and b. This property<p>// doesn't hold for any hash functions in this file.

what does this do: #define LIKELY(x) (__builtin_expect(!!(x), 1))<p>oh, to answer myself, is to help predict the branch direction - it indicates which is likely the common case in the test. <a href="http://kerneltrap.org/node/4705" rel="nofollow">http://kerneltrap.org/node/4705</a>

I just finished created a PHP PECL extension for CityHash. Email me if you'd like to beta-test it before I submit it to the PECL dev list.

Middle click not working as expected? <a href="http://code.google.com/p/chromium/issues/detail?id=67844" rel="nofollow">http://code.google.com/p/chromium/issues/detail?id=67844</a>