chibenwa commented on PR #2770: URL: https://github.com/apache/james-project/pull/2770#issuecomment-3104758692
Just saw the JMH benchmarks. Damn. > Blake3 claimed to be faster than SHA256. I do not fully understand why it is slower than SHA256 in our Java case. My guess is that Java code does not access CPU instructions directly like other languages e.g. C or Rust ...(Blake3 seems to rely on deeply on SIMD instructions). sha256 is litterally implemented by the VM with native code. It's thus heavily optimized. FYI I found https://github.com/zalopay-oss/blake3-jni/ which tend to reflect this is a common issue. Ideas to move this bench forward: - wamup time is rather low. Have you tried warming up longer? Does it impact the results? - use a blackhole in order to consume the hashed value. Or the JVM is likely to optimize stuff away.. - maybe one run with longer hashes on 11MB ? - ideally we should do computation on distinct arrays. Can we append something random ' iteration count at the end of the array just to be sure there's no cache effect? - Apparently using small buffers for blake3 can harm paralelism. Can we try with 256 size like sha ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@james.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@james.apache.org For additional commands, e-mail: notifications-h...@james.apache.org
