Open annenkov opened 4 months ago
There's not a whole lot we can do here. The core problem is Miri performance. You can allow(long_running_const_eval)
, but the compile times seem perhaps prohibitively slow.
In such cases where computing the Montgomery parameters at compile time is too slow given current Miri limitations, you may need to take the path of just precomputing them, i.e. copy-paste the expanded macro as you suggested.
Just curious, AWS has their (formally verified) s2n bignum assembly library. https://github.com/awslabs/s2n-bignum
It looks like there may be rust bindings for it. Would that solve any of these issues?
@spitters it won't help here, since this question is about const fn
usage, and s2n-bignum
is a C/ASM library which isn't callable from const fn
contexts
@spitters note, however, that we do have a general tracking issue for incorporating the assembly from s2n-bignum
: #572
From @protz:
HACL* extracted as pure safe Rust (dubbed "HACL-rs") lives here: https://github.com/hacl-star/hacl-star/tree/afromher_rs/dist/rs
In there, you'll find bignums in src/hacl:
Since HACL-rs still preliminary, but the C code is documented properly, e.g. https://github.com/hacl-star/hacl-star/blob/afromher_rs/dist/gcc-compatible/Hacl_Bignum64.h.
For performance one should make sure to use "release mode".
Description
When using the
impl_modulus!
macro with U3072 and bigger types, theR2
constant computation takes several seconds. The Rust compilers version >= 1.73 with an error. In some cases (not for the example below, probably depends on how the constants are used, see here) compiler v1.76 panics.Ways to reproduce
The example below fails to compile with 1.73.
Console output
Using the Rust compiler v1.76
Misc
It is possible to create
StandardModulusP
and the corresponding implementation by hand (or copy-paste the expanded macro) and allowlong_running_const_eval
:In this case, computing the constant in compile time takes ~7s on ThinkPad X1.