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. 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. If instead we are talking about an Core 2 Duo running in x86_64 mode, we should be talking about the aes-x86_64 module instead of the aes-i586 module and that makes use of the complete instruction set of the Core 2, including SSE2. Regards, Florian Philipp
signature.asc
Description: OpenPGP digital signature
