Hi, >> Tue, 13 Nov 2007 19:47:08 -0700 >> [Subject: Re: [camellia-oss:00952] Re: [PATCH 5/5] camellia: de-unrolling, 64bit-ization] >> Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx> wrote... > On Tuesday 13 November 2007 18:41, David Miller wrote: > > From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx> > > Date: Tue, 13 Nov 2007 15:34:33 -0700 > > > > > My preferred solution is to make loop unrolling conditional on > > > CONFIG_CC_OPTIMIZE_FOR_SIZE - and this is what is done in my > > > (first) patch (see attached). This part: > > > > The default build is going to be CONFIG_CC_OPTIMIZE_FOR_SIZE > > basically for everyone, this is what people get by default > > and this is what every distribution uses. > > > > Therefore %99.9999 of folks will get the slowdown. > > > > So in my book this is not an acceptable way to deal with > > this problem. > > Loop unrolling here amounts to 25% code growth: > > text data bss dec hex filename > 21714 0 0 21714 54d2 camellia5.o > 15906 0 0 15906 3e22 camellia5_Os.o > > Saving 25% or code size and going 5% slower is perfectly acceptable > tradeof for some users. NB: I'm not saying all, ut some significant > part of users would like to be able to have this choice. IMHO, if you are going to use camellia on the embedded system, size of code will be important. On the other hand, I think typically the CPU performance is restricted on the embedded system, so the performance of code will be important... I'm not sure 5% slow down is important or not. It will depend on the system. Regards, -- Noriaki TAKAMYA - 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
