For example, `xxhsum -b1 -b2` will benchmark XXH32 in both aligned and unaligned mode.
Also : modified default list,
now only test main variants (XXH32, XXH64, XXH3 and XXH128).
Also : -bi0 makes it possible to generate a very quick (though inaccurate) evaluation.
replace 2 functions : XXH3_64bits() and XXH3_64bits_withSeed()
new target : make dispatch
compiled with -mavx2 by default
compiles fine with -mavx512f, but then crash at runtime detection
Following comments from @koraa :
- fix endianess issue, by using canonical representation
- all segments are derived from first one, in order to reduce dependency chain
- all derived segments use a seed, which is a combination raw custom seed content and segNb
- updated documentation
This variant breaks the possibility for an actor
to derive the entire secret from the knowledge of one of its segments
since it requires the seed, which is derived from original custom seed,
which is not present anywhere, condensed in the scrambling operation.
update 128-bit scrambler at each 16-bytes round.
ensure there is no delta-correlation possible between segments,
even when the initial custom seed is poor (<= 16 bytes, or full of `\0` characters).
as this architecture offers decent performance for unaligned memory accesses (like x86/x64).
This circumvent the problem described in #383,
as the direct read path using `const xxh_u32*` will not be generated by default.
Note however that this does not go at the root of the problem,
which is a possibility of strict-aliasing issue
when using the direct read path _and_ inlining xxh32.
This issue however is more difficult to solve without a reproduction case.
I also used this opportunity to fix or reinforce documentation.
Streaming implementation of XXH3/XXH128 could fail, reporting an incorrect hash value,
for certain specific ranges of length, and providing input in segments of random length.
issue reported by @WayneD
fix#378
updated test case to catch this issue