Moved SuperFastHash function from base/hash.cc to base/third_party.

base/third_party/superfasthash/superfasthash.c

Index: base/third_party/superfasthash/superfasthash.c
diff --git a/base/third_party/superfasthash/superfasthash.c b/base/third_party/superfasthash/superfasthash.c
new file mode 100644
index 0000000000000000000000000000000000000000..6e7687e13193aa3eb46cae1df62b6f60bdce616c
--- /dev/null
+++ b/base/third_party/superfasthash/superfasthash.c
@@ -0,0 +1,84 @@
+// Copyright (c) 2010, Paul Hsieh
+// All rights reserved.
+//
+// Redistribution and use in source and binary forms, with or without
+// modification, are permitted provided that the following conditions are met:
+//
+// * Redistributions of source code must retain the above copyright notice, this
+//   list of conditions and the following disclaimer.
+// * Redistributions in binary form must reproduce the above copyright notice,
+//   this list of conditions and the following disclaimer in the documentation
+//   and/or other materials provided with the distribution.
+// * Neither my name, Paul Hsieh, nor the names of any other contributors to the
+//   code use may not be used to endorse or promote products derived from this
+//   software without specific prior written permission.
+//
+// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+// AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+// IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+// ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+// LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+// CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+// SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+// INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+// CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+// ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+// POSSIBILITY OF SUCH DAMAGE.
+
+#include <stdint.h>
+#include <stdlib.h>
+#undef get16bits
+#if (defined(__GNUC__) && defined(__i386__)) || defined(__WATCOMC__) \
+  || defined(_MSC_VER) || defined (__BORLANDC__) || defined (__TURBOC__)
+#define get16bits(d) (*((const uint16_t *) (d)))
+#endif
+
+#if !defined (get16bits)
+#define get16bits(d) ((((uint32_t)(((const uint8_t *)(d))[1])) << 8)\
+                       +(uint32_t)(((const uint8_t *)(d))[0]) )
+#endif
+
+uint32_t SuperFastHash (const char * data, int len) {
+uint32_t hash = len, tmp;
+int rem;
+
+    if (len <= 0 || data == NULL) return 0;
+
+    rem = len & 3;

[jln (very slow on Chromium), 2014/02/27 04:37:17]

I know it's not your code, but compilers would optimize this correctly if we
used the more legible:
rem = len % 4;
len /= 4;

[Matt Giuca, 2014/02/27 05:25:29]

I agree, but there is no harm in leaving it as-is (see email).

On a side note: it is frustrating when someone writes ">>= 2" instead of "/= 4"
when it is, by definition in the C/C++ spec, identical. But sadly, the same
cannot be said for % of signed ints versus &, which has different (slower and
less ideal) behaviour for negative numbers.

[jln (very slow on Chromium), 2014/02/27 19:02:13]

Ahh, good point!

+    len >>= 2;
+
+    /* Main loop */
+    for (;len > 0; len--) {
+        hash  += get16bits (data);
+        tmp    = (get16bits (data+2) << 11) ^ hash;
+        hash   = (hash << 16) ^ tmp;
+        data  += 2*sizeof (uint16_t);

[jln (very slow on Chromium), 2014/02/27 04:37:17]

The code is already assuming that this is exactly 4. If chat weren't 8 bits
long, it wouldn't work anyways because of "data + 2" above.

[Matt Giuca, 2014/02/27 05:25:29]

Again, I agree, but no harm in leaving.

+        hash  += hash >> 11;
+    }
+
+    /* Handle end cases */
+    switch (rem) {
+        case 3: hash += get16bits (data);
+                hash ^= hash << 16;
+                hash ^= ((signed char)data[sizeof (uint16_t)]) << 18;

[jln (very slow on Chromium), 2014/02/27 04:37:17]

why the cast, it's already signed
Also, same remark with sizeof(uint16_t); this doesn't make the code more
generic, the assumption that it's "2" is already hardwired here.

[Matt Giuca, 2014/02/27 05:25:29]

The cast is actually necessary because it isn't defined whether char is signed
or unsigned (it's unsigned on ARM, apparently). (The cast was actually
introduced in http://crrev/9375011 and at some point ended up in the upstream
code -- not sure if inspired by Chromium or just by coincidence.)

See http://crbug.com/90659, particularly comment #3, where it was decided to
keep treating the last char as signed, despite the fact that all of the other
chars are treated as unsigned.
Again, I agree, but no harm in leaving.

+                hash += hash >> 11;
+                break;
+        case 2: hash += get16bits (data);
+                hash ^= hash << 11;
+                hash += hash >> 17;
+                break;
+        case 1: hash += (signed char)*data;
+                hash ^= hash << 10;
+                hash += hash >> 1;
+    }
+
+    /* Force "avalanching" of final 127 bits */
+    hash ^= hash << 3;
+    hash += hash >> 5;
+    hash ^= hash << 4;
+    hash += hash >> 17;
+    hash ^= hash << 25;
+    hash += hash >> 6;
+
+    return hash;
+}