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
* Remove --quiet and "Loading ..." from manpage
* Remove "Loading ..." from markdown manpage
* Removing "Loading..." from code
* Update tests for "Loading..."
* Remove the remaining "Loading..." from source
Forgot about this one
* Test error message on non-existing file
* Fix a typo in a test (xxhsum vs ./xxhsum)
* Fix a typo for real. noneexistent -> nonexistent
Tested.
- Every symbol, typedef, and macro is prefixed with XXH or xxh.
- For compatibility with legacy code that messes with the internals,
XXH_OLD_NAMES can be defined to wrap the old names in macros. This
also brings back U32 and friends.
- Replace '-present' with '-2020' (fixes#329)
- Use correct format: Copyright (C) <year> <name of author>
- Fix some obviously incorrect years from copy/paste i.e. avoid time travel
- 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
This new test doesn't use any Unicode in the source files, instead
encoding all UTF-8 and UTF-16 as hex.
The test script will be generated from a C file, in which both a shell
script and a batch script will be generated, as well as the Unicode file
to test.
On Cygwin, MinGW, and MSYS, we will automatically bail from the shell
script to the batch script, as cmd.exe has more reliable Unicode
support, at least on Windows 7 and later.
When the make rule is called, it first checks if `$LANG` contains UTF-8,
defining the (overridable) ENABLE_UNICODE flag. If so, it will skip the
test with a warning.
Also fixed an issue with printf in multiInclude.c causing warnings on
old MinGW versions which expect %I64, and updated the .gitignore.
- Unicode filenames should now work, with a method that works with
and without Unicode mode on Windows.
- Added a test in the Makefile
- Use unbuffered stderr output on Windows, fixes output not updating
immediately on MinGW.
- Fix some missing $(EXT)s in the Makefile, causing Clang to emit
xxhsum instead of xxhsum.exe on Windows, as well as xxhsum's rule
ignoring $(FLAGS).
Inlining hash functions is generally beneficial for performance.
It becomes extremely beneficial whenever input size is a compile-time constant.
To inline xxhash functions, one just needs to include it this way :
One potential issue is that "xxhash.h" may have already been included previously,
typically as part of another included `*.h` .
In which case, the second `#include` statement will have no effect.
This patch fixes this situation :
now, when XXH_INLINE_ALL is defined, all identifiers are renamed,
in order to avoid name collision and confusion with already included indentifiers.
The renaming process uses XXH_NAMESPACE.
XXH_NAMESPACE must be available (i.e. not already used) for renaming to work.
A test has been added in `tests/` to ensure this scenario works correctly.
which do not work using c90 strict mode,
due to the (incorrect) presence of `inline` keyword
in some standard library's header files.
The previous method was disabling the `inline` keyword,
but this introduces other problems with more complex multi-files project,
such as benchHash, which has been recently added as part of `make test`.
Added a new environment variable to disable the c90 compatibility test :
NO_C90_TEST=true
note : apparently, Appveyor doesn't like comments inside () sub-blocks :(
instead of xxhash.c .
This seems preferable for some build systems,
which don't like the `#include "xxhash.c"` statement
when inlining xxhash, as reported by @pdillinger .
Note that `xxhash.c` still exists,
it just includes the implementation and instantiates it.
because gcc is pretty bad at vectorization with -O2.
Also : documented the clang problem with XXH32 auto-vectorization
which must be prevented for better performance.
