On Sun, Jul 06, 2014 at 05:12:42PM +0200, Andy Polyakov via RT wrote: > >>> Running `make test` with Clang sanitizers results in some issues with > >>> unaligned pointers surrounding some uses of buffers cast to a size_t*. > >>> The sanitizers used were `-fsanitize=undefined -fsanitize=address`. > >> Those are conscious choices based on the fact that some CPUs, x86_64 > >> included, are perfectly capable of tolerating unaligned access, in sense > >> that code doesn't crash and produces correct result. In other words, > >> it's legitimate platform-specific behaviour. As a compromise it's > >> possible to arrange it so that build doesn't attempt to utilize this > >> platform capability *if* compiled with -DPEDANTIC. Would it be > >> acceptable compromise? > > > > It already seems to be controlled by the STRICT_ALIGNMENT define, > > which looks like: > > #define STRICT_ALIGNMENT 1 > > #if defined(__i386) || defined(__i386__) || \ > > defined(__x86_64) || defined(__x86_64__) || \ > > defined(_M_IX86) || defined(_M_AMD64) || defined(_M_X64) || \ > > defined(__aarch64__) || \ > > defined(__s390__) || defined(__s390x__) > > # undef STRICT_ALIGNMENT > > #endif > > Yes, and suggestion is to !defined(PEDANTIC) over whole thing. > > > This are the result I get without the strict alignment: > > without EVP (and AES-NI): > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > > bytes > > aes-128 cbc 109991.09k 121907.05k 124370.43k 125518.43k > > 125509.63k > > > > With EVP: > > aes-128-cbc 659929.40k 717046.56k 726172.76k 731055.52k > > 732257.95k > > > > And with strict alignment: > > without EVP: > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > > bytes > > aes-128 cbc 111016.13k 121922.45k 124197.29k 125595.48k > > 125438.63k > > > > With EVP: > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > > bytes > > aes-128-cbc 655557.30k 714415.45k 726278.83k 730977.09k > > 731893.55k > > These are all assembly cases, with and without AES-NI and/or EVP, when > cbc128.c is not involved. I mean AES CBC-ing is handled in assembly in > all these cases, not in cbc128.c. But even if cbc128.c was involved, the > benefit can be observed when input or output is actually misaligned, > while openssl speed benchmarks ... aligned data. So that above results > don't tell anything about benefits of STRICT_ALIGNMENT being undefined. > And it's usually around 10%. And indeed, I just measured 12.5% on my > computer. [You have to configure with no-asm, and rig apps/speed.c to > use misaligned buffers].
So with no-asm with an aligned buffer I end up with: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 221815.09k 235505.86k 237484.26k 238394.37k 238802.26k aes-128-cbc 207397.35k 231086.25k 235446.02k 238599.88k 238622.04k With an unaligned buffer: aes-128 cbc 221833.70k 233167.94k 230320.73k 234839.16k 236371.97k aes-128-cbc 209436.36k 229418.03k 229917.28k 234346.84k 236027.90k If I then turn on strict alignment I get: aligned buffer: aes-128 cbc 217976.36k 235141.91k 236186.03k 238082.39k 239554.35k aes-128-cbc 203719.29k 229814.17k 234827.01k 238313.91k 238441.81k unaligned buffer: aes-128 cbc 202410.53k 222304.58k 224151.72k 226482.52k 227178.68k aes-128-cbc 192809.47k 218801.59k 223360.85k 226003.29k 227447.18k Kurt ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
