-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
[3.7] bpo-40791: Make compare_digest more constant-time. (GH-20444) #23438
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
Conversation
* bpo-40791: Make compare_digest more constant-time. The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]>
|
Sorry, I can't merge this PR. Reason: |
The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> Rebased for Python 2.7 by Michał Górny <[email protected]>
|
Thanks @miss-islington for the PR, and @benjaminp for merging it 🌮🎉.. I'm working now to backport this PR to: 3.6. |
|
GH-23767 is a backport of this pull request to the 3.6 branch. |
The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit db95802) Co-authored-by: Miss Islington (bot) <[email protected]>
The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]>
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767) The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization. (This is change GH-1 from https://bugs.python.org/issue40791 .) (cherry picked from commit 3172936) Co-authored-by: Devin Jeanpierre <[email protected]> (cherry picked from commit 8bef9eb)
The existing volatile
left/rightpointers guarantee that the reads will all occur, but does not guarantee that they will be used. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency betweenresultand the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)
Co-authored-by: Devin Jeanpierre [email protected]
https://bugs.python.org/issue40791