Poseidon benchmark that also runs in Wasm

[mitschabaude]

This adds a simple benchmark to the poseidon crate that can run in both the native and the wasm target.

For running criterion in Wasm, I followed this approach: https://github.com/bheisler/criterion.rs/blob/version-0.4/book/src/user_guide/wasi.md

This PR prepares for experiments with making the Wasm version faster. It makes sense to scope these experiments to Poseidon at first, because

• This will be possible with low complexity and limited understanding of the code base
• An alternative, faster version of Poseidon in Wasm would be independently useful to o1js even if we don't end up making any other changes to the proof system

Results

On this benchmark, Wasm is 4.8x slower than native:

> cargo bench --bench=poseidon_bench

Poseidon/poseidon_hash_kimchi                                                                             
                        time:   [34.578 µs 34.691 µs 34.816 µs]
                        change: [-0.1993% +0.4298% +1.0889%] (p = 0.23 > 0.05)
                        No change in performance detected.

> ./bench-wasm.sh --bench=poseidon_bench

Poseidon/poseidon_hash_kimchi
                        time:   [167.97 µs 168.33 µs 168.70 µs]
                        change: [+379.25% +383.20% +387.09%] (p = 0.00 < 0.05)
                        Performance has regressed.

(note: criterion actually uses the same benchmark data for the native and wasm runs, and compares between them. this doesn't seem too bad if you're mostly interested in improving one of them, and let's you compare the two easily if necessary)

[mitschabaude]

my IDE automatically ran cmake (I think?) and added this folder, so let's gitignore it

[mitschabaude]

Is there a better place for this script than the repo root?

[volhovm]

I'd suggest you create a scripts/ folder, and call this script from the Makefile, what do you think? Then it'd be similar to mina.

[volhovm]

Generally great, but please take a look at my comments! 👍

[volhovm]

Would it work if we put this criterion into the top level Cargo.toml? Or is this version/feature selection fundamentally incompatible with criterion used in different packages within proof-systems?

[volhovm]

Can you add cd $(git rev-parse --show-toplevel) or something like that? Maybe another argument that would specify from which directory to execute, so we have to pass .? This script is assumed to be called /exactly/ from a directory we need it to run into, and I think it's not a very obvious UX and can potentially erase some files you didn't expect it to touch.

[volhovm]

Ooh, fun, we now have the npm dependency for proof-systems.