libsrtp
libsrtp copied to clipboard
cisco
Add x86 SIMD optimizations to crypto datatypes
- The v128 operations are optimized for SSE2/SSSE3/SSE4.1.
-
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. - In
srtp_cleanse, usememsetand 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.
- In
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.
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 https://github.com/cisco/libsrtp/pull/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 bitvector_left_shift, the other places are mostly where I saw an easy opportunity to optimize.