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

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

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.

OK, whatever: then let's have a typedef Aligned for Alignment_t<16>,
or let's have an *integer* Alignment parameter with Aligned being a
deprecated integer constant with value 16; we're not running short of
possibilities there.

>
> 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).

Indeed, and we must not break ABI of plain matrix/array classes such
as Vector4d, that's one of the basic constraints to keep in mind here.

>
> 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.").

It's not required but IIUC buys you better performance for certain instructions.

Benoit

> 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
> ----------------------------------------------
>
>
>