On Sun, Jul 06, 2014 at 06:57:57PM +0200, Andy Polyakov via RT wrote:
> >> ... 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.

I think the main question is if this speed difference is a good
excuse to use undefined behavior or not.

I'm curious where all the unaligned pointers actually come from,
since as far as I can see that function doesn't create the
unaligned pointers itself and it seems to be other code that
seems to be introducing the unaligned buffers and when
STRICT_ALIGNMENT is defined it knows how to deal with that.

Defining STRICT_ALIGNMENT fixes the warnings in cbc128.c, but
there are still in wp_block.c:576-626, md5_dgst.c:108-123 and
md32_common.h:399


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager                           [email protected]

Reply via email to