New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crypto: uniform runtime capability detection #3512
base: 1.15.0-dev
Are you sure you want to change the base?
crypto: uniform runtime capability detection #3512
Conversation
A generic and reusable hardware capability detection mechanism to not query and reimplement multi-architecture code all over the place.
Hi, I ran For this PR I've got for scrypt: For original 1.15.0-dev benchmark run I've got: Judging by the results (and skimming over the code), my understanding is that this PR detects and automatically sets SSE2 CPU features if they are supported by hardware? This is really awesome! Does this mean sse2 and avx2 features can be regarded as standard and not that much "experimental" features anymore? The reason why I ask is in my net-p2p/dogecoin-qt I make it a requirement to specify However, if CPU supports such features as Thank you, |
Thank you.
This PR does not change the experimental-ness of
Those are odd results, could you please attach your
It already did that before - I just made the method available generically.
We can support that once we take this out of experimental. However, the results you posted are not consistent with what I would expect! |
Hi, Thank you for clarifying. Attaching both config.log files as requested. |
I reviewed the logs... your result is a 2x worse performance when compiling without SSE2 enabled. I will try to reproduce these results, because that would be an unintended effect. |
Hi, Just a quick note that I also ran test on another Linux installation in VirtualBox and got following compilation error: This error was fixed by adding
|
@victorsk2019 2 notes:
|
Thank you for additional information. I've recompiled this PR's code without |
Because we want to check for hardware capabilities at runtime among a set of current experimental features when they mature, it's good to have a uniform, central facility that checks capabilities. Detection code is riddled with macros making it hard to review/debug, because for each architecture/compiler there can be quirks.
This PR does 3 things:
compat/cpuid.h
from Bitcoin Core, to provide a generic, low level interface for reading out x86 CPU properties. This helps us in the future outside of crypto algorithms too, because we'll need it for RNG enhancements; see for example this finding on a proposedRDSEED
implementation.crypto/hwcap.*
, where all capabilities can be tested (once), and decoupled from implementation selectors. It can be easily extended by enumerating new booleans into theHardwareCapabilities
struct, which can then be detected in theDetectHWCapabilities()
function. The values in this struct can also be overridden ininit.cpp
in the future, for example: there are plenty products where you would not want to run RDSEED or AVX2 on because either the implementation is terribly slow or has serious security flaws. This construct allows us to create a facility that turns those off using a startup argument that overrides the detection. This would allow users to simply run a released binary but runtime override what features to use, sparing them the need for compile expertise.Testing
I think this needs a couple of specific tests that we don't have a CI for: