Sur ma machine Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz avec 32 Go de RAM :
/tmp ❯ dd if=/dev/urandom bs=1k count=10M of=/tmp/random
10485760+0 enregistrements lus
10485760+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 42,7199 s, 251 MB/s
/tmp ❯ hyperfine 'xxhsum -H3 /tmp/random' 'b3sum /tmp/random' 'b3sum --num-threads 1 /tmp/random'
Benchmark 1: xxhsum -H3 /tmp/random
Time (mean ± σ): 1.757 s ± 0.260 s [User: 0.467 s, System: 1.288 s]
Range (min ... max): 1.484 s ... 2.242 s 10 runs
Benchmark 2: b3sum /tmp/random
Time (mean ± σ): 1.054 s ± 0.036 s [User: 5.877 s, System: 0.770 s]
Range (min ... max): 1.013 s ... 1.136 s 10 runs
Benchmark 3: b3sum --num-threads 1 /tmp/random
Time (mean ± σ): 3.600 s ± 0.102 s [User: 3.047 s, System: 0.549 s]
Range (min ... max): 3.470 s ... 3.743 s 10 runs
Summary
b3sum /tmp/random ran
1.67 ± 0.25 times faster than xxhsum -H3 /tmp/random
3.42 ± 0.15 times faster than b3sum --num-threads 1 /tmp/random
Sur 1 thread, XXH3 est bien plus rapide que BLAKE3, ça prend environ la moitié du temps.
Par contre, vu la parallélisation, BLAKE3 gagne. Après, ça se prête bien aux gros fichiers (dans mon cas, 10 Go), sur un système qui ne fait pas 30 vérifications en même temps. Sur des condensats de paquets TCP, vaut ptêt mieux partir sur du XXH en effet :) (Plein de connexions en parallèle, données tellement petites que lancer un thread prend trop de temps).
[^] # Re: J'ai pas toujours envie que mon hash crypto aille vite...
Posté par Glandos . En réponse au journal BLAKE3, le condensat cryptographique qui laisse les autres sur le quai. Évalué à 3.
Sur ma machine Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz avec 32 Go de RAM :
Sur 1 thread, XXH3 est bien plus rapide que BLAKE3, ça prend environ la moitié du temps.
Par contre, vu la parallélisation, BLAKE3 gagne. Après, ça se prête bien aux gros fichiers (dans mon cas, 10 Go), sur un système qui ne fait pas 30 vérifications en même temps. Sur des condensats de paquets TCP, vaut ptêt mieux partir sur du XXH en effet :) (Plein de connexions en parallèle, données tellement petites que lancer un thread prend trop de temps).