Conversation
| { obj.data() } -> std::convertible_to<const char*>; | ||
| { obj.size() } -> std::unsigned_integral; | ||
| }; | ||
| } |
There was a problem hiding this comment.
We really need a better place for stuff like this -- even just putting in detail here doesn't protect against against ODR oopsies since it's just in fc::detail still.
There was a problem hiding this comment.
Put in a separate file with a different name space?
| xxh3() = default; | ||
| explicit xxh3(const uint64_t h) : _hash(h) {} | ||
|
|
||
| ///no data() since would that be confusing LE/BE? but that breaks common interface across hash types |
There was a problem hiding this comment.
I don't like how the hash interface is a little different for xxh3 vs other hash types (well, the sha3 one is different too). They really all should conform to an identical interface. This comment explains my hesitancy to put in data(), but the reason for the hash_raw() (that may remember from some earlier PRs like #1719!) is that the single-shot fixed-length hash tends to be about 25% faster in my tests, so I really want that.
| target_include_directories(xxhash INTERFACE .) | ||
| target_compile_definitions(xxhash INTERFACE -DXXH_INLINE_ALL=1) | ||
|
|
||
| install(FILES xxHash/xxhash.h DESTINATION "${CMAKE_INSTALL_FULL_INCLUDEDIR}/springxxhash/xxHash" COMPONENT dev EXCLUDE_FROM_ALL) No newline at end of file |
There was a problem hiding this comment.
The library is used header only now; fwiw in an earlier revision I was compiling it as a library and this allows me to access the "x86dispatch" optimizations,
https://github.com/AntelopeIO/spring/blob/c8edec420f4121ca665ceb3d506608c09f81203f/libraries/libfc/libraries/xxhash/CMakeLists.txt
I might explore that again some time, but the current single-shot performance is around 15ns on my box which is plenty fast enough for our event use case I believe.
3 participants
Adds new non-cryptographic hash type to libfc