Optimise OPENSSL_init_crypto using new atomics primitives #13733
Conversation
We add an implementation for CRYPTO_atomic_or() and CRYPTO_atomic_load()
If everything has already been initialised we can check this with a single test at the beginning of OPENSSL_init_crypto() and therefore reduce the amount of time spent in this function. Since this is called via very many codepaths this should have significant performance benefits. Partially fixes #13725 and #13578
Also tests the older CRYPTO_atomic_add() which was without a test
|
@mattcaswell, I don't think it's the slowest part of the code currently. I agree that |
|
Nice job! |
|
The time spent in |
|
|
||
| =item * | ||
|
|
||
| CRYPTO_atomic_or() atomically ors I<op> to I<*val> and returns the |
richsalz
Dec 23, 2020
Contributor
Is it a boolean/logical or? And not a C "any non-zero bit is true" kind of or? Like | versus ||? I'm sure it is, but it might be worth calling that out in the docs here and consider changing the name.
Is it a boolean/logical or? And not a C "any non-zero bit is true" kind of or? Like | versus ||? I'm sure it is, but it might be worth calling that out in the docs here and consider changing the name.
mattcaswell
Dec 23, 2020
Author
Member
Its a bitwise or (i.e. | not ||). I have made this clearer in the docs. I don't think its necessary to change the name - the underlying atomic operation names don't feel the need to make this distinction.
Its a bitwise or (i.e. | not ||). I have made this clearer in the docs. I don't think its necessary to change the name - the underlying atomic operation names don't feel the need to make this distinction.
richsalz
Dec 23, 2020
Contributor
made it clearer in the docs.
WFM, thanks.
made it clearer in the docs.
WFM, thanks.
| @@ -86,6 +86,9 @@ int CRYPTO_THREAD_unlock(CRYPTO_RWLOCK *lock); | |||
| void CRYPTO_THREAD_lock_free(CRYPTO_RWLOCK *lock); | |||
|
|
|||
| int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK *lock); | |||
| int CRYPTO_atomic_or(uint64_t *val, uint64_t op, uint64_t *ret, | |||
| CRYPTO_RWLOCK *lock); | |||
| int CRYPTO_atomic_load(uint64_t *val, uint64_t *ret, CRYPTO_RWLOCK *lock); | |||
kroeckx
Dec 23, 2020
Member
Is there a reason to make those functions public?
Is there a reason to make those functions public?
mattcaswell
Dec 24, 2020
Author
Member
I pondered this myself. We made the other "atomic" function public, and other similar threading type functions, so I decided that if we thought those ones were generally useful, then this one is too. OTOH, I don't have a strong preference if you'd rather them not be.
I pondered this myself. We made the other "atomic" function public, and other similar threading type functions, so I decided that if we thought those ones were generally useful, then this one is too. OTOH, I don't have a strong preference if you'd rather them not be.
|
LGTM |
|
This pull request is ready to merge |
We add an implementation for CRYPTO_atomic_or() and CRYPTO_atomic_load() Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from #13733)
If everything has already been initialised we can check this with a single test at the beginning of OPENSSL_init_crypto() and therefore reduce the amount of time spent in this function. Since this is called via very many codepaths this should have significant performance benefits. Partially fixes #13725 and #13578 Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from #13733)
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from #13733)
Also tests the older CRYPTO_atomic_add() which was without a test Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from #13733)
|
Merged. Many thanks! |
We add an implementation for CRYPTO_atomic_or() and CRYPTO_atomic_load() Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from openssl#13733)
If everything has already been initialised we can check this with a single test at the beginning of OPENSSL_init_crypto() and therefore reduce the amount of time spent in this function. Since this is called via very many codepaths this should have significant performance benefits. Partially fixes openssl#13725 and openssl#13578 Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from openssl#13733)
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from openssl#13733)
Also tests the older CRYPTO_atomic_add() which was without a test Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from openssl#13733)
We introduce some new atomics primitives and use them to optimise the performance of
OPENSSL_init_crypto.We add a new check to the beginning of
OPENSSL_init_cryptoto end early if we have already initialised everything that we need to.I've tested the new atomics primitives as best I can but:
I tested using the same methodology as outlined in #13730. Both the before and after tests had the commits from #13730, #13731 applied (as well as the already committed #13721).
Before:
Which gives an average of 41014.77k
After:
Which is an average of 44346.66k.
This represents an overall performance improvement in this test of about 8%.
This provides a partial fix for #13725 and #13578