|Re: [eigen] about changeset 6eb14e380|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] about changeset 6eb14e380
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Thu, 19 Aug 2010 12:04:21 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=fDXad+252BimvThldzy/8szNqy0w40IDeo9+Sfzc/2w=; b=JT0R80RM2FvYq7sCRk2hnSzjC1F1GD88R9igJynOCwtPjvT6i4/F5r4yZC+IIVxlMT n5kmkQQcAkuQk6CY7SU2few5LIvwQONWfAQ742ClGjAEiDIp+wlIOYo9q7EGSIXAOhTV mFxtUDia2DD/dpVfWepeQN4k4rjSs0m1BarKs=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ZowHia2t1QbBRfmMsRp2/1tePy9SYek/2DinCe6XOmiqxXBxtQ3//bbJCz2m3wkFgD k6mkXl5jgW+O84wNqplD9cVsywzY/2k/JouhlC/PMy/R8AyhBcVve6+War7/KOipr80p RRIpfhEqCBJGTrfCSwrfcEh2lZKEBEBaH5oQQ=
2010/8/19 joel falcou <joel.falcou@xxxxxx>
It is not.
On 19/08/10 13:03, Gael Guennebaud wrote:
To make things more complicated we could also think about how to
support packet of different sizes for the same scalar type. Indeed,
both the NEON (for ARM) and the future AVX engines support packet of
different sizes. 2 or 4 floats for NEON, and 4 or 8 floats for AVX.
For dynamic sized objects it is pretty clear that supporting largest
packets is enough. However, for small fixed sized objects it be very
welcome to be able to instantiate packet types according to the
context. For instance, if AVX is enabled, we still want to able to use
packets of 4 floats to vectorize Vector4 and Matrix4. This is very
important for what you know...
Gael was just saying that it's important to offer vectorization for small fixed-size objects, such as Vector4f, which means that we must be able to use 16 byte packets instead of 32 byte packets in some circumstances.
Earlier today on IRC, we discussed replacing the AlignedBit flag by a new, separate enum value Alignment. Heap allocated arrays would use a generously large alignment, e.g. cache line boundary alignment. Static arrays would use the highest alignment that is useful for SIMD, doesn't increase their sizeof, and is <= some limit that the user could manually set if he really knows what he's doing (setting such a limit would be ABI incompatible). At computation-time, we'd then check the value of Alignment and emit SIMD code accordingly.
In nt2, the simd packet class is native<T,X> where T is the scalar
type and X the extension tag. Then functions knwo which packet they are allowed
to mix and the configuration include w/e tag needed.