My idea is to statically link the different versions of libargon2 into the same binary, giving the function names a suffix of the target via a C macro.
We'd then have argon2d_hash_raw_avx2, argon2d_hash_raw_sse2 and so on built from the same source.
Like in https://github.com/nimiq-network/core/pull/456, a $PACKAGING environment variable should be introduced, that will trigger a native build if it's false instead of the avx2, sse2… versions.
On startup, Rust then would set up function pointers to the native module and use rust-cupid to initialize them with the correct implementations.
The alternative would be to dynamically load the implementations like the .node libraries in Node.js but that'd be more difficult and inconvenient, in my opinion.
Like in https://github.com/nimiq-network/core/pull/440 of core-js, I think it's useful to have a native module selection for packaged builds, and I'd like to take on this.
My idea is to statically link the different versions of
libargon2
into the same binary, giving the function names a suffix of the target via a C macro. We'd then haveargon2d_hash_raw_avx2
,argon2d_hash_raw_sse2
and so on built from the same source.Like in https://github.com/nimiq-network/core/pull/456, a $PACKAGING environment variable should be introduced, that will trigger a
native
build if it's false instead of theavx2
,sse2
… versions.On startup, Rust then would set up function pointers to the native module and use
rust-cupid
to initialize them with the correct implementations.I also filed https://github.com/nimiq/core-rs/pull/1 to reduce the number of functions so the module is easier to work with.
The alternative would be to dynamically load the implementations like the
.node
libraries in Node.js but that'd be more difficult and inconvenient, in my opinion.