On Tuesday 13 November 2007 20:49, David Miller wrote: > From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx> > Date: Tue, 13 Nov 2007 19:47:08 -0700 > > > If CONFIG_CC_OPTIMIZE_FOR_SIZE is not an acceptable method, > > do you have other ideas? > > Look at ways to make the code run faster without loop unrolling? I did it. I noticed that key setup is mostly operating on 64-bit quantities, and provided alternative implementation which exploits that fact. It's smaller and faster. However, after I've done that, the question still stands: should I unroll the loop or not? The situation we are in now is exactly the sutiation I want to avoid: On Wednesday 07 November 2007 06:22, Denys Vlasenko wrote: > > Having two versions of the cdoe is unmaintainable. So please > > either decide that 5% is worth it or isn't. > > *I* am happy with 5% speed sacrifice. I'm afraid other people won't be. > > I just want to escape vicious cycle of -Os people arguing with > -O2 people to no end. I don't want somebody to come later > and unroll the loop again. And then me to come > and de-unroll it again... > > It's better for everybody to recognize that both POVs are valid, > and have provisions for tuning size/speed tradeoff by the user > (person which builds the binary). That's why I made a patch where unrolling can be enabled by CONFIG_xxx. I will resubmit the patch without de-unrolling. Meanwhile, I'd like to ask you guys to think about ways to make size/speed tradeoffs selectable at build time. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
