On 05/29/2013 09:05 AM, Joel Falcou wrote:
On 29/05/2013 15:00, Nasos Iliopoulos wrote:
As a matter of fact I am surprised by the progress of the compilers auto-vectorization facilities the last few years, that make me -doubt- the need for explicit vectorization any more. The GSOC project will make it clear for us. An added benefit on relying on compiler is that future vector instructions come for free. A disadvantage is of course the non-guarantee that auto-vectorization will work but I find this rarely the case.
I beg to differ, you're in for some nasty surprises. It basically works for simple operations on simple one-level loops with easily inferred loop boundaries. Also, those stuff are very fragile and based on vendor willingness to do whatever.
That's true. So what we are looking at is breaking down the certain algorithms to a state that the vectorizer can penetrate the patterns. A triple loop won't be just vectorized but providing clear functional paths is working. I don't expect that it will work generally for the current expression templates back-end that's why the we encouraged the student to keep his proposal within the bounds of certain functions. Additionally just injecting explicit vectorization instructions is not gonna work; you need to alter your computational patterns that in the end come very close to what the compiler would optimize anyway.
In multiple actual cases we had to deal with in both academic and industrial context, the autovectorizer was rapidly confused even for rather simple c++ code.
We are also worried with polluting the code with vectorization instructions that will make things quite unmanageable in the future. I also think boost libraries should stay closer to what standard C++ specifies and this fixation of mine may be hindering my willingness to support non-standard items. This is a good discussion, Nasos
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost