Re: [eigen] No vectorization in presence of .cast<T>() calls

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

Ah, I just remembered of something I had thought of a while ago, which
is a reason why supporting AVX should actually be very easy and not
required changes around AlignedBit and stuff.

My understanding of AVX is that even though it goes faster with 32
byte alignment, none of its instructions, not even the aligned
load/store instructions, require it.

So really that means that our code doesn't need to know at compile
time whether stuff is 32-byte aligned.

For dynamic matrices, all we'll need is to edit aligned_malloc to
return 32-byte aligned pointers, and for fixed-size matrices whose
size is a multiple of 32 bytes, we'll require 32 byte alignment.
That's all!

Of course some changes will be needed in the vectorization code to
support multiple packet sizes (16 or 32 bytes). But at least we
shouldn't need changes arounds the alignment-info-at-compile-time /
AlignedBit stuff.

Benoit


2010/12/19 Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>:
> On 18.12.2010 14:45, Benoit Jacob wrote:
>> 2010/12/18 Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>:
>>> [...]
>>> Another point: Did someone already think about how to support AVX in the
>>> future? -- Last time I checked there were some hard-coded 16 in the code ...
>>
>> Sure, as soon as AVX hardware is actually available, that's a useful
>> thing to do :-)
>>
>> Yes there still are hardcoded 16's but that's not a big problem.
>> Should be easy to get rid of, as they mostly don't affect the API.
>>
>> The only thing that worries me a little bit is when this impacts the
>> API itself. There are 2 such places:
>>  - the Aligned option to Map
>>  - the AlignedBit flag on expression (that one is largely internal though).
>>
>> What we can do in Eigen 3.1 is:
>>  - replace Aligned by a template<int N=16> struct Aligned. So Aligned
>> would mean 16-byte aligned, and you could do Aligned<32> if you want
>> to explicitly specify 32 byte alignment. This preserves the API, but
>> changes the ABI of class Map, I think that's OK: we're only making ABI
>> stability guarantees on plain objects, not expressions, so especially
>> in Eigen 3.0 this doesn't have to include class Map.
>
> I'm afraid you would have to write Aligned<> then, so for full
> API-compatibility maybe a new struct and a typedef would be required.
>
> Also regarding ABI-stability: Having a struct like this:
>        struct S{double d; Vector4d vec;};
> leads to different layout depending on alignment requirements (depending
> on alignment requirements of vec the struct is 40, 48 or 64 bytes long
> (though I don't know how far ABI stability goes for you).
>
> On the other hand I don't know if 32byte alignment is required at all
> for AVX (wikipedia says: "The alignment requirement of SIMD memory
> operands is relaxed."). Also I agree that there is currently no reason
> for a rush to support AVX ...
>
> Christoph
>
> --
> ----------------------------------------------
> Dipl.-Inf. Christoph Hertzberg
> Cartesium 0.051
> Universität Bremen
> Enrique-Schmidt-Straße 5
> 28359 Bremen
>
> Tel: (+49) 421-218-64252
> ----------------------------------------------
>
>
>