You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There has been a recent and very unfortunate discovery about PDEP on AMD processors.
This comes from a very respected pair of performance gurus, namely the person running the famous uops.info website.
To summarize: While AMD processors officially support the PDEP opcode, it is really implemented in microcode via a loop and might execute anywhere between 18-289 cycles.
This might also have potential security implications for code that performs PDEP as part of cryptographic functions that might require/rely on constant time execution (Though I'm less of an expert, maybe people like @blowdart can provide some feedback about how real this is).
In my opinion, the only proper way to handle such erratic CPU behavior (Unfortunately it's really not the last, nor the first time this sort of thing happens) is to provide HW information to developers while also making sure that the JIT can and will treat this information as a constant when it comes to code-generation.
I've already opened a separate issue for exposing these HW level constants in a more general way, but this PDEP mess also deserves some attention in its own.
The text was updated successfully, but these errors were encountered:
@damageboy, would you be fine with closing this given that we've updated the codebase to not use PDEP/PEXT and we are tracking exposing CPUID as its own intrinsic via #785?
At the request of @danmosemsft I'm opening this issue...
There has been a recent and very unfortunate discovery about PDEP on AMD processors.
This comes from a very respected pair of performance gurus, namely the person running the famous uops.info website.
Discussion:
https://twitter.com/trav_downs/status/1203425075896225792
Repro:
https://twitter.com/uops_info/status/1202950721211162626
Screenshot (twitter being twitter and all):
To summarize: While AMD processors officially support the
PDEP
opcode, it is really implemented in microcode via a loop and might execute anywhere between 18-289 cycles.This might also have potential security implications for code that performs
PDEP
as part of cryptographic functions that might require/rely on constant time execution (Though I'm less of an expert, maybe people like @blowdart can provide some feedback about how real this is).In my opinion, the only proper way to handle such erratic CPU behavior (Unfortunately it's really not the last, nor the first time this sort of thing happens) is to provide HW information to developers while also making sure that the JIT can and will treat this information as a constant when it comes to code-generation.
I've already opened a separate issue for exposing these HW level constants in a more general way, but this
PDEP
mess also deserves some attention in its own.The text was updated successfully, but these errors were encountered: