|Re: [eigen] Status of AVX support|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Status of AVX support
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Tue, 6 Dec 2011 08:01:28 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CZFtYujNwkak8ouI7cRRTGiN/+GJlRuFAwql+Y5jwLs=; b=PfEx9wahH4vOhi2BygOJaXr2YJYDGHAV0cwY1MtkkAlYz8bhdH9bkMqCjqXyjBi/uE PAQ6ZHlOy4dLIk2783Ub2RXxWzhFCPnDPLgs2Wr4PGg9z5F6RZFSC8fzhosMfTnLGI2O 57ILh38pd2By1t7I/j211ZZicu9TUVPBsy9Rg=
I don't know of any work in that direction.
The difficulty is that taking advantage of AVX without regressing
current performance from SSE will require us to handle *both* 16-byte
and 32-byte packet size and alignment. We will need 16-byte for e.g.
Vector4f, while we will of course want to use 32-byte wherever we can.
That part requires significant changes in Eigen.
On the other hand, if you can be satisfied with just a pure-32-byte
mode, not trying to fall back to 16-byte, that's a lot easier, you'd
just have to adjust existing code to allow for 32-byte alignment
instead of 16-byte (easy) and add arch/AVX/PacketMath.h (not hard if
you know AVX intrinsics). You're welcome to do so, but keep in mind
that such a pure-32-byte mode will regress performance for the
applications that don't lend themselves well to 32-byte packets and
alignment, such as Vector4f, so it won't be possible to enable it by
default until it can properly fall back to 16-byte packets and
2011/12/5 Rohit Garg <rpg.314@xxxxxxxxx>:
> I just laid my hands on a Sandy Bridge machine and I was wondering
> what is the current status of AVX development for Eigen.
> Rohit Garg
> Graduate Student
> Applied and Engineering Physics
> Cornell University