nickbabcock / highway-rs Goto Github PK

https://doc.rust-lang.org/stable/core/arch/wasm32/index.html.

Exploratory work has already started at https://github.com/nickbabcock/highway-rs/tree/wasm

I've been reviewing the code in portable.rs and I believe there's an opportunity for some refactoring to improve code readability and maintainability, specifically around the bitwise operations.

1. Use Core Ops for Explicit Bitwise Operations: Leveraging core::ops::BitAnd can make the operations more explicit and easier to understand. For example:

use core::ops::BitAnd;

let size_mod4 = bytes.len().bitand(3);
let remainder_jump = bytes.len().bitand(!3);

2. change the operands to better reflect their bitwise nature

const TWO_LSB_MASK: usize = 0x0000_0000_0000_0003;
let size_mod4 = bytes.len().bitand(TWO_LSB_MASK);
let remainder_jump = bytes.len().bitand(!TWO_LSB_MASK);

There is precedent for 2. within this code, for instance

3. Standardize caps for hex representation
   line 136 is all caps, line 166 is no caps etc

If you agree atleast partially, let me know which of the above options seem most sensible to you.
If you leave it up to me, I would likely first introduce the core::ops and introduce consts for only those bitmasks used more than once. I'll prepare a PR upon that, and you could provide further critique on what seems the best readable code

Of course, one could be chosen without the other, or maybe the current code is as readable, understandable and maintainable in your view. Or, this implementation might look the way it does because the original looks that way and you'd like to keep parity. I haven't personally looked into the C/C++ version to have any strong feelings about that.

In anycase, if you'd like the style to stay the way it does, I will look into other avenues of improvement.

If I don't touch the public API in a year, the current version (0.8) will be re-released as 1.0.

Discussed a bit here:

I have another branch with no_std support for the PortableHash

Nice! One thing to note is that SIMD instructions should still be available on core, afaik. What's not available is is_x86_feature_detected so it seems possible that one can continue using AvxHash::force_new on no_std (and have AvxHash::new return None). But we can talk about this more on the PR when you have it situated.

cc @jRimbault

Just creating this issue to track the request so I don't forget about this.

Hi,

Thanks for this awesome crate.
I'm using HighwayHash but I'd like to input u64 instead of u8 without having to use Transmute.

Would it be possible for you to integrate the possibility in your crate? That would be so helpful!

Thank you

The HighwayHasher facade will choose the best hashing implementation at runtime based on the underlying CPU capabilities.

I recently benchmarked the facade. At payloads under 1KB, the facade throughput can be twice as slow as the underlying AVX implementation. Of course, some overhead should be expected from the facade, but this is excessive. And such a large of a caveat shouldn't be present for the main entrypoint of the library.

Doing some profiling, most of the overhead comes from initialization where there is a memcpy of the implementation into HighwayHasher and since the internal implementations weigh ~192 bytes, this memcpy can be significant.

Not sure of the best way to solve this, but if I don't think of a good way, there's always the alternative of creating one-shot functions that can use a more traditional indirect function approach like what is used memchr

The Google implementation now has code for NEON SIMD on aarch64 (and 32 but who cares):
google/highwayhash@ff5f27d

Porting to Rust would likely require adding new intrinsics to rust-simd..

I'm still trying to understand how to host this from a browser. I will continue working towards this; just wondering if there are additional examples to include or suggestions.

Also, there's no discussion tab, so I'm adding it here. I'm interested in 32bit hashes. I understand the highway algorithm is 64bit minimum. It wouldn't need to be highway; something like crc32fast to provide the algorithm for a 32bit hash output? Do I fork and work a separate binding for crc32fast or extend highway or is it not a good idea for some reason?