|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:41:49 -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=rEnB6nurzO1/QDb+PfU2LLoOgGoLweezCTTEW8x+2fg=; b=T1+4StYJmtoZVwvPUaE08ZMKRpNnH4DX2lCcqQoro6mSr8T4a8EVnlkaX4Hfp/Eq8v omLog2yHTEhWXnT0NDv5JBKb+4TsbACLMmvR0/Sac5GGalvVfJApyMZC+Q3fUtUkcTQp 66xkATWY1AHEBhMM2wVEpjE8lY3awwfgI97W8=
- 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=KwhEa78JwRPPiSkmilivNL7DiEbLPYuuZHGpMto/I+5phHnm6mX0KCWMNcBc28TFly 53VuS/bK8r2i0Xsazg2HYTtF/Y2XAfiAjk/pjGQNDcsQkY2f7Ewp7OZ0pRsm35Ma557N TKnutcnncKdY4/62xwBqnVVaBtCZ/BBDYX1xo=
2010/8/19 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
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.
Note for the worried: I think that all of that can be done for Eigen 3.1, as it's essentially internal. The only issue is that if at a later time we enable AVX vectorization, then if we run AVX code on a matrix that was created by a shared library compiled against Eigen 3.0, it would crash (the library would have to be re-built against newer Eigen). Given that AVX is still a thing of the future, I think we can ignore that for now, and by the time we add AVX support in Eigen, we document that issue. We've got to put some realistic boundaries on our ABI compatibility guarantees, we can't boast compatibility with every future hardware platform without recompilation.
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.