On 2012/11/06 19:08:54, rsc wrote:
i&0xf will get you something here.
I am not sure I understand. Since the loop only goes from [0, 15],i&0xf will get you something here.
anding with 0xf should be a no-op.
be in range here, but &0xf will force it to notice that and avoid the
bounds check. It is unlikely to matter much.
I adding this change, and got a small increase in speed.
On 2012/11/06 04:06:47, dfc wrote:
for ; i < 20; i++ { .. }
and so forth
FWIW this is unlikely to matter.for ; i < 20; i++ { .. }
and so forth
loops because the compiler should be doing it and it decreases
readability. In addition, the comments at the top of this file hint
it not being a priority to make this as fast as possible.
Dave suggested a single i instead of 5 different i variables. Mycomment was only that from a performance standpoint it is unlikely to
matter. The compiler does not unroll the loops, and in general I think
it is unreasonable to expect it to. The big win you can get from the
SHA1 block function is if you unroll the loops 5x and do the variable
renamings in each iteration, so that all the rotating assignments
disappear. If you want to do this it should be done in a separate CL
and the speed gain should justify the increase in code. The last time
I looked at this I think it was not quite enough. crypto/md5/gen.go is
the program that generates the MD5 block routine. You could use
something similar for SHA1.
Russ
misses, so I agree it should be in a future CL. Hoisting i out of the
loop in the meantime showed a little extra gain.
https://codereview.appspot.com/6820096/
