Fixes curve25519_dalek_bits defaults for cross and wasm

[pinkforest]

As discussed in #456 this sets well known defaults for:
cfg(target_family = "wasm") and cfg(target_arch = "arm")

By setting the 64 bit serial arithmetric via cfg(curve25519_dalek_bits = "64")

EDIT: I've used platforms crate via env TARGET to determine the actual cross target and this now fixes build.rs only.

[rozbb]

Awesome! One thing: could we have documentation somewhere (can even be in the comments of build.rs) that explains what's going on and why? A link to something about WASM benchmarks would be nice to include too if you have it

[pinkforest]

I'm fixing the build script for cross.. this is WIP for an hour or so. sorry

[tarcieri]

Sidebar: we should probably add some cross tests, particularly for big-endian architectures.

Here's an example of the ones we use for the @RustCrypto elliptic curve crates (although testing on both MSRV and stable is probably overkill):

https://github.com/RustCrypto/elliptic-curves/blob/0337e2a/.github/workflows/p256.yml#L89-L109

[pinkforest]

K. I'll add those here

[tarcieri]

I'm not super familiar with WASM benchmarking but this seems like an option:

https://docs.rs/easybench-wasm/latest/easybench_wasm/

@burdges you brought this up originally... any thoughts on how to do WASM benchmarks?

[pinkforest]

Should we also build / test on windows and mac runners ?
I have a portable builder that uses diff runners https://github.com/rinse-repeat/rust-auditable-builder here
zig allows easy cross w/ cc w/o cross but then qemu could be used to test if we need (as you pointed elsewhere I think)

[tarcieri]

@pinkforest that's something I think is helpful when using std APIs with different std::os-specific backends, but this is a purely computational crate now which doesn't link std at all so I think it's probably unnecessary in this case

[pinkforest]

Yeah that's a very good point

[pinkforest]

This is now documented here alongside other backend selection changes:

• Document curve25519_dalek_ backend and bits selection #467

[tarcieri]

It would be good to confirm via a benchmark that WASM benefits from this, which is something I can poke at this weekend unless someone else wants to.

[pinkforest]

With criterion could have to wrap the wasm blob with a runtime - e .g. with lunatic - system oriented - we do:
https://github.com/lunatic-solutions/lunatic/blob/main/benches/benchmark.rs

But I think the easybench_wasm looks okay

For browser few pop up:
https://github.com/originjs/WASM-benchmark

https://github.com/PSPDFKit-labs/pspdfkit-webassembly-benchmark
that provides this:
http://iswebassemblyfastyet.com/

Though those got a lot of host/guest (js/wasm) boundary stuff going that creates overhead but still diff runtimes.

wasm is complicated beast to bench as there is tons of diff runtimes and not everyone agrees to "standards" 🤷‍♀️

[rozbb]

I think sticking with browser benches (easybench looks okay) is probably enough for now. For this crate, I'd guess the most common place people will try to deploy their WASM is Chrome.

[pinkforest]

FWIW - wasmer seems to benchmark sha1 crate via their runtime test
https://github.com/wasmerio/wasmer-bench/blob/master/benchmarks/src/sha.rs

[pinkforest]

I've set this to only fix the build.rs for cross-compile and wasm targets for now as keen to get this merged.
This also gives the structure for well known targets -
Another follow-up PR perhaps can be instead used to provide well known defaults armv7 and wasm potentially (original intent of this PR) when we have more test / bench coverage on those overrides to justify these defaults.
This also now includes CI for some cross targets.

[burdges]

you brought this up originally... any thoughts on how to do WASM benchmarks?

I donno, but I'll forward the question to people who do.