>> ... 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]. > > 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
I.e. 5% difference. Exact difference can of course vary, as it depends on how fast cipher is. Slower cipher is, smaller the difference, because cbc128.c overhead does not depend on cipher. So that exact coefficient depends even on compiler version and optimization level. 10% is something I've measured when cbc128.c was implemented and it was approximately same today on my computer. You've got 5%. Point still is that there is measurable difference. Next question is of course if the difference is significant enough to care about in the context. It should be noted that sanitized code referred to in original report is not necessarily something you'd use in production build, because it's significantly slower because of the additional checks. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
