the summary is merely there to provide some rough guideline
providing comparative performance figures from well known hash algorithms.
highway was just added to please a 3rd party request,
but results are contested by another 3rd party,
this kind of debate is outside the scope of xxhash repository
which merely aims at presenting xxhash in context.
On the other hand, maybe I should consider adding some very well known algorithms
such as md5 or sha1 which are used very often in multiple contexts
in order to provide perspective.
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.
- Remove most remaining spaces before punctuation
- Fix a few missed copyright messages
- Document the timer resolution workaround
- Document XXH_mult32to64
- I compiled GCC 3.2 and 4.2 just to test this, both are affected.
- Make sure we downcast for __emulu
- Other minor fixes
Work in progress.
- Fix many spelling/grammar issues, primarily in comments
- Remove most spaces before punctuation
- Update XXH3 comment
- Wrap most comments to 80 columns
- Unify most comments to use the same style
- Use hexadecimal in the xxhash spec
- Update help messages to better match POSIX/GNU conventions
- Use HTML escapes in README.md to avoid UTF-8
- Mark outdated benchmark/scores
XXH_FORCE_MEMORY_ACCESS==3 will use a byteshift operation. This is
preferred on older compilers which don't inline `memcpy()` or some
big-endian systems without a native byteswap.
Also fix a small typo.
This marks all internal functions as `static`, and gives the compiler
full control over whether to inline functions or not.
This is automatically defined on GCC and Clang when `-O0`, `-Os`, `-Oz`,
or `-fno-inline` is used.
With clang -Oz for AArch64, the .text section goes from 16880 bytes to
8136 bytes.
