On Tue, Mar 13, 2012 at 3:30 PM, Florian Philipp <li...@binarywings.net> wrote: > Am 13.03.2012 20:13, schrieb Michael Mol: >> On Tue, Mar 13, 2012 at 2:58 PM, Florian Philipp <li...@binarywings.net> >> wrote: >>> Am 13.03.2012 19:18, schrieb Michael Mol: >>>> On Tue, Mar 13, 2012 at 2:06 PM, Florian Philipp <li...@binarywings.net> >>>> wrote: >>>>> Am 13.03.2012 18:45, schrieb Frank Steinmetzger: >>>>>> On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote: >>>>>> >>>>>>>> Since I am planning to encrypt only home/ under LVM control, what kind >>>>>>>> of overhead should I expect? >>>>>>> >>>>>>> What do you mean with overhead? CPU utilization? In that case the >>>>>>> overhead is minimal, especially when you run a 64-bit kernel with the >>>>>>> optimized AES kernel module. >>>>>> >>>>>> Speaking of that... >>>>>> I always wondered what the exact difference was between AES and AES >>>>>> i586. I >>>>>> can gather myself that it's about optimisation for a specific >>>>>> architecture. >>>>>> But which one would be best for my i686 Core 2 Duo? >>>>> >>>>> From what I can see in the kernel sources, there is a generic AES >>>>> implementation using nothing but portable C code and then there is >>>>> "aes-i586" assembler code with "aes_glue" C code. >>>> >>>> >>>>> So I assume the i586 >>>>> version is better for you --- unless GCC suddenly got a lot better at >>>>> optimizing code. >>>> >>>> Since when, exactly? GCC isn't the best compiler at optimization, but >>>> I fully expect current versions to produce better code for x86-64 than >>>> hand-tuned i586. Wider registers, more registers, crypto acceleration >>>> instructions and SIMD instructions are all very nice to have. I don't >>>> know the specifics of AES, though, or what kind of crypto algorithm it >>>> is, so it's entirely possible that one can't effectively parallelize >>>> it except in some relatively unique circumstances. >>>> >>> >>> One sec. We are talking about an Core2 Duo running in 32bit mode, right? >>> That's what the i686 reference in the question meant --- or at least, >>> that's what I assumed. >> >> I think you're right; I missed that part. >> >>> >>> If we talk about 32bit mode, none of what you describe is available. >>> Those additional registers and instructions are not accessible with i686 >>> instructions. A Core 2 also has no AES instructions. >>> >>> Of course, GCC could make use of what it knows about the CPU, like >>> number of parallel pipelines, pipeline depth, cache size, instructions >>> added in i686 and so on. But even then I doubt it can outperform >>> hand-tuned assembler, even if it is for a slightly older instruction set. >> >> I'm still not sure why. I'll posit that some badly-written C could >> place constraints on the compiler's optimizer, but GCC should have >> little problem handling well-written C, separating semantics from >> syntax and finding good transforms of the original code to get >> proofably-same results. Unless I'm grossly overestimating the >> capabilities of its AST processing and optimization engine. >> > > Well, it's not /that/ good. Otherwise the Firefox ebuild wouldn't need a > profiling run to allow the compiler to predict loop and jump certainties > and so on.
I was thinking more in the context of simple functions and mathematical operations. Loop probabilities? Yeah, that's a tough one. Nobody wants to stall a huge CPU pipeline. I remember when the NetBurst architecture came out. Intel cranked up the amount of die space dedicated to branch prediction... > > But, by all means, let's test it! It's not like we cannot. > Unfortunately, I don't have a 32bit Gentoo machine at hand where I could > test it right now. Now we're talking. :) Unfortunately, I don't have a 32-bit Gentoo environment available, either. Actually, I've never run Gentoo in a 32-bit envrionment. >.> -- :wq
