Add fxhash (Rust)

[dumblob]

https://github.com/cbreeden/fxhash (yeah, it's Rust, but at some point there will anyway be a need to test other Rust hashes as they seem to be quite unique)

[rurban]

Sure. Accidently I looked at this just yesterday, and saw that it's very similar to my new FNV improvement.

I don't care about Rust, just that gcc-9.1.0 is blacklisted

[rurban]

It would be nice if someone does a pull request for rust based hashes like this. I'm too rusty for rust.

I recently added ASM support (for clang and gcc only, no masm), but it's not yet merged. See the aesni-sha1-x86_64 branch.

[sharpobject]

Is it acceptable to use a C++ port of the Rust implementation? This hash is quite small and I recently implemented a similar hash in Zig that differs only in that it does fewer rounds for non-multiple-of-8 input sizes and assumes it can read up to 7 bytes past the end.

const Hasher = struct {
    const K: u64 = 0x517cc1b727220a95;
    hash: u64 = 0,
    pub inline fn add(self: *Hasher, i: u64) void {
        self.hash = (((self.hash << 5) | (self.hash >> 59)) ^ i) *% K;
    }

    pub inline fn write(self: *Hasher, start: [*]u8, len: u64) void {
        const end = start + len;
        var p = start;
        while (@ptrToInt(p + 8) <= @ptrToInt(end)) {
            self.add(std.mem.readIntLittle(u64, p[0..8]));
            p += 8;
        }
        if (@ptrToInt(p) < @ptrToInt(end)) {
            // for this last read,
            // the low bytes are our string and the high bytes are garbage
            const garbage_bytes = @intCast(u6, 8 - (@ptrToInt(end) - @ptrToInt(p)));
            self.add(std.mem.readIntLittle(u64, p[0..8]) << garbage_bytes * 8);
        }
    }
};

This obviously isn't useful, but I can make a more faithful C++ port if that would help.

[rurban]

Sure it is.
linking to the static rust lib would be better, but we take what we get.

[tgross35]

@rurban do you just need the following API, exposed in a staticlib?

void somehash_test(const void *key, uint32_t len, uint32_t seed, void *out);

Looking at Hashes.h it seems like some hashes set out and some do not - I am thinking that any test that doesn't set the out value may be optimized away completely, how is that handled?

I can add tests for a handful of popular Rust hashers if you can give me some pointers on what to expose

[rurban]

Yes, just this is fine, as C or C++.

All hash test functions need to set out, some just do the memcpy in its finalizers, or write directly to it. It's the dest buffer we are writing to

[tgross35]

Thank you for the quick response, I submitted a PR to add this and others in #276. A lot of hash libraries use a common trait interface so it was pretty easy to add quite a few implementations.