[kmiller68]

Since the non-simd version of the test is relatively slow I reduced the iteration/worst counts to 15/2, repsectively.

Also, I moved all the benchmark files to the argon2 directory to help organize the wasm directory a bit.

[kmiller68]

CC @danleh @camillobruni @eqrion @jandem for thoughts

[danleh]

Regarding the README.md (which wasn't changed by this PR, but since I looked at it): Could you add a short description where the source code is coming from? Or ideally change build.sh to checkout/download it from some URL, so we could more easily update it with whatever the upstream is?

Edit: I searched a bit, could this NPM package/repo be the upstream? https://github.com/antelle/argon2-browser

[danleh]

Mhm, I think there is something wrong with the non-SIMD variant of this benchmark. In particular, the flamegraph/profile shows tons of samples attributed to capturing stack traces, caused by growing the memory inside _emscripten_resize_heap and emscripten_realloc_buffer. See screenshot:

If you modify emscripten_realloc_buffer in argon2-bundle.js to not just swallow the error/failure to grow memory

                function emscripten_realloc_buffer(size) {
                    try {
                        wasmMemory.grow(size - buffer.byteLength + 65535 >>> 16);
                        updateGlobalBufferAndViews(wasmMemory.buffer);
                        return 1
                    } catch (e) { console.log(e) }
                }

you get tons of errors, e.g., in d8 RangeError: WebAssembly.Memory.grow(): Maximum memory size exceeded or in jsc RangeError: WebAssembly.Memory.grow expects the grown size to be a valid page count.

I will briefly try to rebuild this from source to diagnose further. @kmiller68 have you seen this before or is this just a problem on my end? Do you have more information on why/how the memory usage of the non-SIMD variant could be higher than the SIMD variant? Could this be an issue simply because of running multiple iterations after setup, such that later iteration continuously grow memory?

Edit: While I could build the argon2.wasm and argon2-simd.wasm binaries with the provided build.sh, the build script(s) don't seem to produce (or mention) argon2-bundle.js. How can it be re-generated? I stopped investigating further for now.

For the time being, I don't think the non-SIMD variant is measuring something sensible.

[danleh]

Similar to the other Emscripten-built line items, could we move the generated files in a build/ subdirectory, to distinguish them from manually written code, such as benchmark.js (just so we/someone in the future doesn't end up mixing/interjecting manually written with generated code again).

[danleh]

Also, is it correct that both benchmark.js and argon2.js were written by you (or your colleagues)?

[danleh]

Even with only 15 iterations, the non-SIMD variant runs quite long (>1 minute), while the SIMD variant runs ~2-3s with the same number of iterations. I am bit surprised by that stark difference (30x or more), so I will spend a brief time trying to understand why we are that slow. We do expect the SIMD and non-SIMD variant to do essentially the same amount of work, right?

[danleh]

(lone comment, since the file wasn't changed in this PR): I believe the ../ prefix should be stripped from the destination paths in line 17 and 21 of wasm/argon2/build.sh, see

JetStream/wasm/argon2/build.sh

Line 17 in ab7d6d0

mv dist/argon2.wasm ../argon2-simd.wasm

[kmiller68]

Closing this in favor of #47