On 05.06.2013 11:34, Herbert Xu wrote:
> On Sun, Jun 02, 2013 at 07:51:52PM +0300, Jussi Kivilinna wrote:
>> It appears that the performance of 'vpgatherdd' is suboptimal for this kind
>> of
>> workload (tested on Core i5-4570) and causes blowfish-avx2 to be
>> significantly
>> slower than blowfish-amd64. So disable the AVX2 implementation to avoid
>> performance regressions.
>>
>> Signed-off-by: Jussi Kivilinna <[email protected]>
>
> Both patches applied to crypto. I presume you're working on
> a more permanent solution on this?
Yes, I've been looking for solution. Problem is, well, that I assumed vgather
to be quicker than emulating gather using vpextr/vpinsr instructions. But it
appears that vgather has about the same speed as group of vpextr/vpinsr doing
gather manually. So doing
asm volatile(
"vpgatherdd %%xmm0, (%[ptr], %%xmm8, 4), %%xmm9; \n\t"
"vpcmpeqd %%xmm0, %%xmm0, %%xmm0; /* reset mask */ \n\t"
"vpgatherdd %%xmm0, (%[ptr], %%xmm9, 4), %%xmm8; \n\t"
"vpcmpeqd %%xmm0, %%xmm0, %%xmm0; \n\t"
:: [ptr] "r" (&mem[0]) : "memory"
);
in loop is slightly _slower_ than manually extracting&inserting values with
asm volatile(
"vmovd %%xmm8, %%eax; \n\t"
"vpextrd $1, %%xmm8, %%edx; \n\t"
"vmovd (%[ptr], %%rax, 4), %%xmm10; \n\t"
"vpextrd $2, %%xmm8, %%eax; \n\t"
"vpinsrd $1, (%[ptr], %%rdx, 4), %%xmm10, %%xmm10; \n\t"
"vpextrd $3, %%xmm8, %%edx; \n\t"
"vpinsrd $2, (%[ptr], %%rax, 4), %%xmm10, %%xmm10; \n\t"
"vpinsrd $3, (%[ptr], %%rdx, 4), %%xmm10, %%xmm9; \n\t"
"vmovd %%xmm9, %%eax; \n\t"
"vpextrd $1, %%xmm9, %%edx; \n\t"
"vmovd (%[ptr], %%rax, 4), %%xmm10; \n\t"
"vpextrd $2, %%xmm9, %%eax; \n\t"
"vpinsrd $1, (%[ptr], %%rdx, 4), %%xmm10, %%xmm10; \n\t"
"vpextrd $3, %%xmm9, %%edx; \n\t"
"vpinsrd $2, (%[ptr], %%rax, 4), %%xmm10, %%xmm10; \n\t"
"vpinsrd $3, (%[ptr], %%rdx, 4), %%xmm10, %%xmm8; \n\t"
:: [ptr] "r" (&mem[0]) : "memory", "eax", "edx"
);
vpextr/vpinsr cannot be used with 256-bit wide ymm registers, so
'vinserti128/vextracti128' is needed and make manual gather about the same
speed as vpgatherdd.
Now the block cipher implementations need to use all bytes of vector register
for table look-ups, and the way that this is done in the AVX implementation of
Twofish (move data from vector register to generic purpose registers, handle
byte-extraction and table look-ups there and move processed data back to vector
register) is about two to three times faster than the way with current AVX2
implementation using vgather.
Blowfish does not do much processing in addition to table look-ups, so there is
not much to that can be done. With Twofish, the table look-ups are the most
computationally heavy part and I don't think that the wider vector registers in
the other parts are going to give much boost. So permanent solution is likely
to be revert.
-Jussi
>
> Thanks,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
