GH-37273: [C++] Bump vendored xxhash version

[pitrou]

Bump from 0.8.1 to 0.8.2. It should fix a compilation error seen here, and may come with other improvements:
https://dev.azure.com/ursacomputing/crossbow/_build/results?buildId=53150&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb

• Closes: [C++] Bump vendored xxhash version #37273

[pitrou]

@github-actions crossbow submit -g cpp

[github-actions]

⚠️ GitHub issue #37273 has been automatically assigned in GitHub to PR creator.

[pitrou]

@github-actions crossbow submit -g cpp

[github-actions]

Revision: 6b88733

Submitted crossbow builds: ursacomputing/crossbow @ actions-184ea6a984

Task	Status
test-alpine-linux-cpp
test-build-cpp-fuzz
test-conda-cpp
test-conda-cpp-valgrind
test-cuda-cpp
test-debian-11-cpp-amd64
test-debian-11-cpp-i386
test-fedora-35-cpp
test-ubuntu-20.04-cpp
test-ubuntu-20.04-cpp-bundled
test-ubuntu-20.04-cpp-minimal-with-formats
test-ubuntu-20.04-cpp-thread-sanitizer
test-ubuntu-22.04-cpp
test-ubuntu-22.04-cpp-20
test-ubuntu-22.04-cpp-no-threading

[mapleFU]

Nice, seems new release contains some optimizations about neon, maybe it helps!

[pitrou]

@ursabot please benchmark

[ursabot]

Benchmark runs are scheduled for commit 6b88733. Watch https://buildkite.com/apache-arrow and https://conbench.ursa.dev for updates. A comment will be posted here when the runs are complete.

[pitrou]

Nice, seems new release contains some optimizations about neon, maybe it helps!

I'm not sure we enable Neon at compile-time. In any case, feel free to try it out and benchmark. cc @cyb70289

[mapleFU]

Before

BM_ComputeHash<Int32Type>               33496 ns        33047 ns        21239 items_per_second=495.785M/s
BM_ComputeHash<Int64Type>               39656 ns        38217 ns        18754 items_per_second=428.71M/s
BM_ComputeHash<FloatType>               31851 ns        31729 ns        21467 items_per_second=516.376M/s
BM_ComputeHash<DoubleType>              38029 ns        37922 ns        18432 items_per_second=432.042M/s
BM_ComputeHash<ByteArrayType>           58705 ns        58625 ns        11987 items_per_second=279.471M/s
BM_ComputeHash<FLBAType>                53983 ns        53624 ns        13022 items_per_second=305.537M/s
BM_ComputeHash<Int96Type>               42545 ns        41847 ns        16551 items_per_second=391.52M/s
BM_BatchComputeHash<Int32Type>          16991 ns        16991 ns        41152 items_per_second=964.288M/s
BM_BatchComputeHash<Int64Type>          19473 ns        19473 ns        35910 items_per_second=841.383M/s
BM_BatchComputeHash<FloatType>          16978 ns        16978 ns        41167 items_per_second=965.021M/s
BM_BatchComputeHash<DoubleType>         19470 ns        19470 ns        35928 items_per_second=841.498M/s
BM_BatchComputeHash<ByteArrayType>      45086 ns        45086 ns        15504 items_per_second=363.394M/s
BM_BatchComputeHash<FLBAType>           44769 ns        44769 ns        15627 items_per_second=365.967M/s
BM_BatchComputeHash<Int96Type>          24302 ns        24302 ns        28910 items_per_second=674.172M/s

after

BM_ComputeHash<Int32Type>               31991 ns        31965 ns        21962 items_per_second=512.558M/s
BM_ComputeHash<Int64Type>               35487 ns        35473 ns        19200 items_per_second=461.874M/s
BM_ComputeHash<FloatType>               30803 ns        30795 ns        22698 items_per_second=532.028M/s
BM_ComputeHash<DoubleType>              36394 ns        36386 ns        19212 items_per_second=450.284M/s
BM_ComputeHash<ByteArrayType>           56184 ns        56171 ns        12473 items_per_second=291.682M/s
BM_ComputeHash<FLBAType>                51441 ns        51424 ns        13726 items_per_second=318.609M/s
BM_ComputeHash<Int96Type>               41537 ns        41495 ns        16503 items_per_second=394.839M/s
BM_BatchComputeHash<Int32Type>          17056 ns        17054 ns        40914 items_per_second=960.687M/s
BM_BatchComputeHash<Int64Type>          19548 ns        19547 ns        35786 items_per_second=838.202M/s
BM_BatchComputeHash<FloatType>          17062 ns        17061 ns        41006 items_per_second=960.329M/s
BM_BatchComputeHash<DoubleType>         19548 ns        19547 ns        35854 items_per_second=838.187M/s
BM_BatchComputeHash<ByteArrayType>      45999 ns        45983 ns        15264 items_per_second=356.302M/s
BM_BatchComputeHash<FLBAType>           45968 ns        45955 ns        15225 items_per_second=356.523M/s
BM_BatchComputeHash<Int96Type>          24277 ns        24273 ns        28697 items_per_second=674.978M/s

I've benchmark 3 times on my m1 macos, seems after this patch, ComputeHash would be a bit faster, and BatchComputeHash seems not have remarkable benifits. Maybe it's related to code cache or others

[pitrou]

Perhaps you can try out arrow-compute-scalar-set-lookup-benchmark, arrow-compute-vector-hash-benchmark and arrow-hashing-benchmark as well.

[mapleFU]

#ifndef XXH_VECTOR    /* can be defined on command line */
#  if defined(__ARM_FEATURE_SVE)
#    define XXH_VECTOR XXH_SVE
#  elif ( \
        defined(__ARM_NEON__) || defined(__ARM_NEON) /* gcc */ \
     || defined(_M_ARM) || defined(_M_ARM64) || defined(_M_ARM64EC) /* msvc */ \
     || (defined(__wasm_simd128__) && XXH_HAS_INCLUDE(<arm_neon.h>)) /* wasm simd128 via SIMDe */ \
   ) && ( \
        defined(_WIN32) || defined(__LITTLE_ENDIAN__) /* little endian only */ \
    || (defined(__BYTE_ORDER__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) \
   )
#    define XXH_VECTOR XXH_NEON
#  elif defined(__AVX512F__)
#    define XXH_VECTOR XXH_AVX512
#  elif defined(__AVX2__)
#    define XXH_VECTOR XXH_AVX2
#  elif defined(__SSE2__) || defined(_M_AMD64) || defined(_M_X64) || (defined(_M_IX86_FP) && (_M_IX86_FP == 2))
#    define XXH_VECTOR XXH_SSE2
#  elif (defined(__PPC64__) && defined(__POWER8_VECTOR__)) \
     || (defined(__s390x__) && defined(__VEC__)) \
     && defined(__GNUC__) /* TODO: IBM XL */
#    define XXH_VECTOR XXH_VSX
#  else
#    define XXH_VECTOR XXH_SCALAR
#  endif
#endif

I guess by default we will pick XXH_VECTOR == XXH_NEON in our code. But I'm not sure that neon is used here.

[conbench-apache-arrow]

Thanks for your patience. Conbench analyzed the 6 benchmarking runs that have been run so far on PR commit 6b88733.

There were 13 benchmark results indicating a performance regression:

• Pull Request Run on ursa-thinkcentre-m75q at 2023-08-21 18:57:17Z
  • BM_DefinitionLevelsToBitmapRepeatedAllMissing (C++) with source=cpp-micro, suite=parquet-level-conversion-benchmark
  • BM_ComputeHash (C++) with params=, source=cpp-micro, suite=parquet-bloom-filter-benchmark
• and 11 more (see the report linked below)

The full Conbench report has more details.

[kou]

+1

Can we merge this?
Or do we need more discussion before we merge this?

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit 369bb31.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them.