[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120719194340.GA9739@openwall.com>
Date: Thu, 19 Jul 2012 23:43:40 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Keychain format speedup on CPU.
Jim, Lukas -
On Thu, Jul 19, 2012 at 02:07:15PM -0500, jfoug wrote:
> Also one very small optimization (less than 1%) is to avoid the non-needed
> assignments.
The compiler most likely took care of this, but it is indeed good to
cleanup the source.
More curiously, removing somewhat similar seemingly redundant
assignments from Sayantan's MSCash2 kernel actually hurt performance
(so I put some of them back in the patch I posted, which later got
committed). Specifically, IIRC this applied to moving some of these out
of the 10k iterations loop:
W[5] = 0x80000000;
W[6] = 0;
W[7] = 0;
W[8] = 0;
W[9] = 0;
W[10] = 0;
W[11] = 0;
W[12] = 0;
W[13] = 0;
W[14] = 0;
W[15] = 0x2A0;
Presumably having a redundant assignment of a constant to a variable
shortly before its use let the compiler substitute the constant in
place of the uses of the variable in an inline function and optimize it
accordingly (computing some subexpressions at compile time), whereas
having the assignment done just once and followed by some non-trivial
code (seemingly changing these W[] elements) prevented this
optimization. Indeed, fully optimizing this at the source code level
(not leaving any expressions that the compiler could optimize by
substituting the constants) would achieve the same or better speed, so
what I am trying to say is that sometimes partial optimization actually
hurts performance, even if the same change is the right one to make as
part of fully optimizing the source code.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
