A proposal for new asm.js test
There is a nice asm.js based crypto library written by @vibornoff. Maybe you could include some of the crypto functions eg.:
- SHA512: for int64 operations
- PBKDF-HMAC-SHA256: intentionally slow algorithm, int32 computations
- AES-CBC: a test for throughput
- AES-GCM: the most modern block mode cipher used in TLS1.2
https://github.com/vibornoff/asmcrypto.js
P.S.: this asm.js code is hand-written/generated and not compiled from C++
Interesting, thanks!
I'm not that familiar with crypto myself. I see that project benchmarks itself against CryptoJS and SJCL, I assume those are the other major projects in that space?
I am certainly open to discussing including a benchmark of this in Massive. Would be good to hear from @vibornoff first about thoughts on this.
Oh, hello everyone!
As I see Massive is more about emscripten — asm.js chain, rather than only asm.js benchmarking. asmCrypto code in opposite is carefully written with hands and profiled to have a good enough speed in browsers not supporting asm.js.
If you decide to add asmCrypto into your benchmarks I'd recommend at least 2 things:
- PBKDF-HMAC-SHA256 with reasonably high number of iterations (100k and more) — there's almost none of memory allocations and heap access, everything happens through the local and module-scope variables;
- AES-CBC with reasonably large data chunk (1 MiB is enough) — my AES implementation intensively use precomputed lookup table residing in the heap so it's good to test heap access speeds.
And feel free to contact me if any clue.
Thanks for the info!
While the main purpose of Massive is asm generated by emscripten, it's just because most asm.js code is created that way, currently. We should include other code if it makes sense to do so.
I think the relevant questions are:
- Is asmCrypto performance currently good enough, or not? (If it's already good, a benchmark is not needed, the goal of benchmarks is to motivate and measure progress.) By "good enough" I guess I mean either compared to how it is used, or compared to native code doing the same.
- Is perf consistent across browsers? (If it already is, then again, a benchmark is not needed.)
- And, how representative this code is of real-world use, how commonly it would be used, etc. Thoughts?
edit: added a third item
- Native is at least twice fast as the Firefox score (OpenSSL with the CPUs AES-NI instruction usage turned off)
- The SHA512 performance is at least 10x slower because of the missing 64bit int operations and the missing ROT operation, which browsers don't detect. This test could measure the 64bit integer and special bitwise operation detection in the Javascript code.
- asmCrypto AES throughput ratio for Firefox:Chrome:IE is 40:25:1
- It can be used as a polyfill for the FUTURE (not the currently implemented or current W3 draft) WebCryptoAPI. This one can handle progressive processing and you can implement the missing crypto operations.
Thanks for the info, we should think more on this.