1 |
On Tue, Mar 13, 2012 at 2:58 PM, Florian Philipp <lists@×××××××××××.net> wrote: |
2 |
> Am 13.03.2012 19:18, schrieb Michael Mol: |
3 |
>> On Tue, Mar 13, 2012 at 2:06 PM, Florian Philipp <lists@×××××××××××.net> wrote: |
4 |
>>> Am 13.03.2012 18:45, schrieb Frank Steinmetzger: |
5 |
>>>> On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote: |
6 |
>>>> |
7 |
>>>>>> Since I am planning to encrypt only home/ under LVM control, what kind |
8 |
>>>>>> of overhead should I expect? |
9 |
>>>>> |
10 |
>>>>> What do you mean with overhead? CPU utilization? In that case the |
11 |
>>>>> overhead is minimal, especially when you run a 64-bit kernel with the |
12 |
>>>>> optimized AES kernel module. |
13 |
>>>> |
14 |
>>>> Speaking of that... |
15 |
>>>> I always wondered what the exact difference was between AES and AES i586. I |
16 |
>>>> can gather myself that it's about optimisation for a specific architecture. |
17 |
>>>> But which one would be best for my i686 Core 2 Duo? |
18 |
>>> |
19 |
>>> From what I can see in the kernel sources, there is a generic AES |
20 |
>>> implementation using nothing but portable C code and then there is |
21 |
>>> "aes-i586" assembler code with "aes_glue" C code. |
22 |
>> |
23 |
>> |
24 |
>>> So I assume the i586 |
25 |
>>> version is better for you --- unless GCC suddenly got a lot better at |
26 |
>>> optimizing code. |
27 |
>> |
28 |
>> Since when, exactly? GCC isn't the best compiler at optimization, but |
29 |
>> I fully expect current versions to produce better code for x86-64 than |
30 |
>> hand-tuned i586. Wider registers, more registers, crypto acceleration |
31 |
>> instructions and SIMD instructions are all very nice to have. I don't |
32 |
>> know the specifics of AES, though, or what kind of crypto algorithm it |
33 |
>> is, so it's entirely possible that one can't effectively parallelize |
34 |
>> it except in some relatively unique circumstances. |
35 |
>> |
36 |
> |
37 |
> One sec. We are talking about an Core2 Duo running in 32bit mode, right? |
38 |
> That's what the i686 reference in the question meant --- or at least, |
39 |
> that's what I assumed. |
40 |
|
41 |
I think you're right; I missed that part. |
42 |
|
43 |
> |
44 |
> If we talk about 32bit mode, none of what you describe is available. |
45 |
> Those additional registers and instructions are not accessible with i686 |
46 |
> instructions. A Core 2 also has no AES instructions. |
47 |
> |
48 |
> Of course, GCC could make use of what it knows about the CPU, like |
49 |
> number of parallel pipelines, pipeline depth, cache size, instructions |
50 |
> added in i686 and so on. But even then I doubt it can outperform |
51 |
> hand-tuned assembler, even if it is for a slightly older instruction set. |
52 |
|
53 |
I'm still not sure why. I'll posit that some badly-written C could |
54 |
place constraints on the compiler's optimizer, but GCC should have |
55 |
little problem handling well-written C, separating semantics from |
56 |
syntax and finding good transforms of the original code to get |
57 |
proofably-same results. Unless I'm grossly overestimating the |
58 |
capabilities of its AST processing and optimization engine. |
59 |
|
60 |
> |
61 |
> If instead we are talking about an Core 2 Duo running in x86_64 mode, we |
62 |
> should be talking about the aes-x86_64 module instead of the aes-i586 |
63 |
> module and that makes use of the complete instruction set of the Core 2, |
64 |
> including SSE2. |
65 |
|
66 |
FWIW, SSE2 is available on 32-bit processors; I have code in the field |
67 |
using SSE2 on Pentium 4s. |
68 |
|
69 |
-- |
70 |
:wq |