Re: [lmi] Using auto-vectorization

[Vadim Zeitlin]

On Tue, 24 Jan 2017 04:11:10 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-01-24 02:49, Vadim Zeitlin wrote:
GC> [...]
GC> > ET-based code seems to profit from auto-vectorization just
GC> > as well as everything else, so I don't see any reason to use anything 
else,
GC> > especially if the code clarity and simplicity are the most important
GC> > criteria.
GC> > 
GC> >  Now, whether using the particular PETE library is the best choice in 2017
GC> > is another question and I suspect that it isn't, but I'm not aware of any
GC> > critical problems with it neither.
GC> 
GC> It seems that there was a flurry of interest around the turn of the
GC> century, but almost none since then. The audience for ET libraries is
GC> relatively small, and I'd guess that most potential users chose a
GC> library long ago and aren't interested in changing.

 There are still a few actively developed libraries built on ET, e.g. Eigen
(http://eigen.tuxfamily.org/) or Armadillo (http://arma.sourceforge.net/)
and, of course, some older libraries such as Boost.uBLAS are still much
newer than PETE.

GC> >  So, I guess, I'm still not sure what, if anything, should be done here? I
GC> > can spend a lot of time profiling/benchmarking/debugging and it probably
GC> > will result in at least some useful insights, but I can't propose any
GC> > syntax better than the current ET-based one and so I'm still not sure what
GC> > is my goal here.
GC> 
GC> I think we're done for now. We aren't likely to find anything that
GC> outperforms PETE. We can make greater use of it as time permits.

 Yes, I agree with this. However I think that you might still want to
consider switching to -O3 (or adding just -ftree-vectorize?) as it seems to
result in a "free" performance gain.

 Regards,
VZ