Add x86 SIMD optimizations to crypto datatypes #507
Conversation
Lastique
force-pushed
the
optimize_datatypes
branch
4 times, most recently
from
f7f31d5 to
ae2a70c
Compare
|
Hi, @Lastique thanks for these. I guess these changes are based on real world usage, do you have any benchmarks on the speed improvements for a given configuration & platform? |
|
I have attached a unit benchmark to #508, but I don't have one at hand for the changes in this PR. I did bench the change when I originally wrote this patch for our in-house use a few years back, but unfortunately I didn't save it. I suppose, I could write one anew, if required. Basically, these two PRs came out of our attempts to reduce libsrtp entries in the profiling reports for our WebRTC SFU software. The software maintains lots of SRTP connections (hundreds), and these changes allowed to save a few percents of total CPU usage. The most CPU consuming part in this PR that came up in our reports is |
Lastique
force-pushed
the
optimize_datatypes
branch
from
ae2a70c to
ccd75ec
Compare
|
Rebased on top of the current master. |
Lastique
force-pushed
the
optimize_datatypes
branch
from
ccd75ec to
52d61dd
Compare
|
@Lastique thanks for updating, will take a new look at this now |
- The v128 operations are optimized for SSE2/SSSE3. - srtp_octet_string_is_eq is optimized for SSE2. When SSE2 is not available, use a pair of 32-bit accumulators to speed up the bulk of the operation. We use two accumulators to leverage instruction-level parallelism supported by most modern CPUs. - In srtp_cleanse, use memset and ensure it is not optimized away with a dummy asm statement, which can potentially consume the contents of the memory. - Endian conversion functions use gcc-style intrinsics, when possible. The SIMD code uses intrinsics, which are available on all modern compilers. For MSVC, config_in_cmake.h is modified to define gcc/clang-style SSE macros based on MSVC predefined macros. We enable all SSE versions when it indicates that AVX is enabled. SSE2 is always enabled for x86-64 or for x86 when SSE2 FP math is enabled.
Lastique
force-pushed
the
optimize_datatypes
branch
from
52d61dd to
faa7998
Compare
| @@ -272,9 +480,14 @@ int srtp_octet_string_is_eq(uint8_t *a, uint8_t *b, int len) | |||
|
|
|||
| void srtp_cleanse(void *s, size_t len) | |||
| { | |||
| #if defined(__GNUC__) | |||
| memset(s, 0, len); | |||
| __asm__ __volatile__("" : : "r"(s) : "memory"); | |||
There was a problem hiding this comment.
This is probably a little unrelated to the rest ... unless it was performance problem.
|
thanks for the pr @Lastique , and sorry it so long to get in |
|
Thanks. |
srtp_octet_string_is_eqis optimized for SSE2. When SSE2 is not available, use a pair of 32-bit accumulators to speed up the bulk of the operation. We use two accumulators to leverage instruction-level parallelism supported by most modern CPUs.srtp_cleanse, usememsetand ensure it is not optimized away with a dummy asm statement, which can potentially consume the contents of the memory.base64_block_to_octet_triple, prefermemchrtostrchras it explicitly accepts the string length, which is known at compile time.The SIMD code uses intrinsics, which are available on all modern compilers. For MSVC, config_in_cmake.h is modified to define gcc/clang-style SSE macros based on MSVC predefined macros. We enable all SSE versions when it indicates that AVX is enabled. SSE2 is always enabled for x86-64 or for x86 when SSE2 FP math is enabled.