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

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

This discussion also reminds me that there is a need to support
packets of different sizes. This is already possible with NEON where
there are special instructions to work on packets of 2 or 4 floats.
With AVX you can work on packets of 4 or 8 floats (btw, with AVX you
will ideally need an alignment of 32 bytes). In practice that means
that the packet<> and writePacket<> functions be templatized on the
Packet size (or maybe on the packet type would be as simple could
possibly allow more fancy stuffs in the future). Packets of various
sizes could also be a way to go to elegantly support casting. For
instance, to go from char to float, one could create a simple Packet
of 4 chars with only load/store/casting capabilities... Another
possibility is to create "virtual" packet types of any sizes multiple
of the largest "native" packet size. They would be based on
Array<Scalar,K*NativePacketSize,1> for the meta unrolling etc....


gael

On Sun, Dec 19, 2010 at 7:16 PM, Christoph Hertzberg
<chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> 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
> ----------------------------------------------
>
>
>