modpow in 0.3 (128 bit support) degrades performance for WASM

[ra--]

num-bigint 0.3 introduced 128 bit integer support, which significantly improves modular exponentation. On my machine with arbitrary 256 bit inputs, modpow() improved from 94 ms to 24 ms from num-bigint version 0.2 to version 0.3 respectively. With Wasm code generated by modpow() from num-bigint's version 0.2, I observe an execution time of 125 ms, which seems a reasonable overhead. I expected to observe some performance improvement from num-bigint 0.3 to translate over to Wasm as well, but the opposite seems to be the case. Instead of improving, execution time degrades from 125 ms to 148 ms. Is this a known issue?

Summary: modpow() num-bigint v0.2: 94 ms -> Wasm 125 ms modpow() num-bigint v0.3: 24 ms -> Wasm expected ~32 ms, but at least < 125 ms. observed 148 ms.

[cuviper]

The new 64-bit digits are only used for target_pointer_width = 64. Since the only Wasm targets are wasm32-* so far, they won't get the new digit size by default. So at first glance, I would not expect wasm32 running on x86_64 to get any part of the same speedup as native x86_64.

The montgomery modpow also got a big rewrite in bb3e3b178a38133ce9b5c25c86e22e12dad943de, regardless of digit size.

Here are my own native results, and for fun I also tried forcing alternate digit sizes.

i686-unknown-linux (ns/iter)

bench	0.2.6	0.3.0	0.3.0 (u64)
modpow	23,260,377	18,386,342	15,552,574
modpow_even	81,104,677	80,563,416	94,701,085

x86_64-unknown-linux (ns/iter)

bench	0.2.6	0.3.0	0.3.0 (u32)
modpow	18,742,629	3,914,476	13,402,402
modpow_even	39,494,004	34,533,942	43,222,990

Those are using 2048-bit inputs, so your 256-bit inputs could well hit different hotspots. And I'm not sure how to predict what Wasm JITs will do with all of this. If you have a way to actually profile that, it could be helpful.