Xxhash: Perbarui perbandingan kecepatan dengan crc32

Dibuat pada 24 Apr 2016  ·  6Komentar  ·  Sumber: Cyan4973/xxHash

Jika Anda menggunakan instruksi crc32 dengan benar, tersedia sejak Nehalem (SSE 4.2), Anda dapat mencapai throughput 1,17 siklus per 8 byte, yang akan menjadi kinerja teoritis 20,5 GB/s pada prosesor 3ghz, dalam kondisi idealis. Sumber: http://www.drdobbs.com/parallel/fast-parallelized-crc-computation-using/229401411?pgno=2

Googling sedikit memunculkan pertanyaan SO ini, yang mengutip throughput 20GB/s, yang cocok dengan angka teoretis dengan sangat baik: http://stackoverflow.com/questions/17645167/implementing-sse-4-2s-crc32c-in- perangkat lunak

Bisakah Anda membuat sedikit catatan bahwa hardware crc32 sebenarnya ~3x lebih cepat dari xxhash? Itu bukan untuk mengatakan itu adalah algoritma hash yang lebih cocok, tetapi saya membuang banyak waktu untuk mempertimbangkan xxhash vs crc32 vektor untuk tujuan checksum, sebelum saya menyadari bahwa saya tidak dapat mendekati kinerja crc32.

question

Komentar yang paling membantu

Terima kasih!
Binari adalah 64bit.
XXH3_64bit pasti berkinerja lebih baik. Tanpa menggunakan vektorisasi NEON, saya mendapatkan 3,9 GB/dtk dan dengan NEON mendekati 4,0 GB/dtk. Masih CRC32 yang menggunakan vmull_p64 memiliki throughput yang sedikit lebih baik.

Semua 6 komentar

Masalahnya adalah,
benchmark dijalankan pada Core 2 Duo @3GHz.
CPU ini tidak mendukung perangkat keras crc32c.

Juga, crc32 dan crc32c serupa tetapi algoritmanya berbeda: Anda tidak akan mendapatkan hasil yang sama.
crc32 banyak digunakan, crc32c apalagi. Kebingungan penamaan seperti itu dapat menyebabkan masalah interoperabilitas non-sepele.

Versi crc32 yang dibangkitkan di sini adalah yang disediakan dalam suite tes smasher.
Ada versi yang lebih cepat, termasuk yang di-vektorkan.
Diperlukan untuk memodifikasi suite pengujian untuk mengintegrasikannya.

Jika Anda dapat mentolerir ketergantungan Intel untuk aplikasi Anda, dan dapat menjamin semua cpus klien Anda cukup baru (yang masuk akal pada tahun 2016), Anda kemudian dapat menggunakan perangkat keras crc32c, itu memang sangat cepat.

xxHash dibuat dalam konteks yang berbeda, menggunakan cpu tanpa kemampuan ini, dan dengan tujuan portabilitas maksimum, jauh melampaui ranah Intel (lengan, mips, daya, dll.). Oleh karena itu tidak ada ketergantungan pada fitur khusus merek.

@Cyan4973
Sebagai tindak lanjut yang sangat terlambat, dapatkah Anda memberikan beberapa wawasan tentang XXH3 baru dibandingkan dengan crc32c?

Perangkat keras crc32c dengan sendirinya tidak kompetitif. Meskipun tentu saja lebih cepat daripada perangkat lunak crc32, ia tidak dapat mengikuti ILP, yang digunakan oleh sebagian besar algoritme hash modern.

Namun, beberapa saluran crc32c secara paralel dapat lebih efisien. Dalam hal ini, hasil yang tepat bergantung pada implementasi. Banyak implementasi dapat ditemukan melalui Internet. Saya telah menemukan beberapa implementasi yang dapat mempercepat XXH64 , tetapi belum ada yang terbaik XXH3 . Mungkin ini masalah mencari lebih banyak.

CRC32 dan CRC32C dapat diimplementasikan dengan sangat efisien menggunakan instruksi pclmulqdq atau ARMv8 CLMUL Intel.

Beberapa waktu yang lalu saya mengumpulkan beberapa implementasi ARM menggunakan instruksi CRC32 dan CLMUL dan kecepatan mereka mengambang sekitar 4,1GB/s di rk3399. Sekarang saya membandingkannya dengan xxh32 dan xxh64 dan masing-masing mendapatkan 3.5GB/s dan 2.5GB/s.

Apakah diharapkan xxh64 lebih lambat dari xxh32 di ARMv8, atau ada yang salah?

Diharapkan xxh64 lebih lambat dari xxh32 pada binari 32-bit.
Pada binari 64-bit, kemungkinannya kecil, tetapi orang masih dapat membayangkan sebuah chip yang menampilkan instruksi perkalian 64-bit yang lemah/lambat, jauh lebih lambat daripada yang 32-bit, dalam hal ini, itu mungkin.
Sayangnya, keluarga chip ARMv8 cukup besar, dan setiap chip dapat menampilkan pertukaran kinerja yang sangat berbeda. Jadi saya akan mengatakan kasus ini harus terjadi di suatu tempat, tetapi saya tidak akan menjadikannya aturan.

Untuk hash 64-bit yang lebih cepat di ARM, Anda mungkin tertarik untuk mencoba XXH3_64bit() , yang ditampilkan dalam rilis terbaru.

Terima kasih!
Binari adalah 64bit.
XXH3_64bit pasti berkinerja lebih baik. Tanpa menggunakan vektorisasi NEON, saya mendapatkan 3,9 GB/dtk dan dengan NEON mendekati 4,0 GB/dtk. Masih CRC32 yang menggunakan vmull_p64 memiliki throughput yang sedikit lebih baik.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat