Re: [boost] [gsoc] boost.simd news from the front.

Subject: Re: [boost] [gsoc] boost.simd news from the front.
From: David A. Greene (greened_at_[hidden])
Date: 2011-06-10 16:16:06

Mathias Gaunard <mathias.gaunard_at_[hidden]> writes:

> On 06/06/2011 12:10, Robert Jones wrote:
>
>> From reading a few of the nt2 webpages, and wikipedia on SSE2, the
>> business of exploiting SIMD capability seems to be in the domain of
>> the compiler. How does this look from a library perspective? What are
>> the mechanisms you'll use/consider?
>
> This has been discussed several times in the past on this mailing list
> already.
>
> I suggest you take a look at the Boostcon 2011 presentation:
> <https://github.com/boostcon/2011_presentations/raw/master/thu/simd.pdf>

I don't think this presentation makes the case for this library.  That
said, I am very glad you and others are thinking about these problems.

Almost everything the compiler needs to vectorize well that it does not
get from most language syntax can be summed up by two concepts: aliasing
and alignment.

I don't see how pack<> addresses the aliasing problem in any way that is
not similar to simply grabbing local copies of global data or
parameters.  Various C++ "restrict" extensions already address the
latter.  We desperately need something much better than "restrict" in
standard C++.  Manycore is the future and parallel processing is the new
normal.

pack<> does address alignment, but it's overkill.  It's also
pessimistic.  One does not always need aligned data to vectorize, so the
conditions placed on pack<> are too restrictive.  Furthermore, the
alignment information pack<> does convey will likely get lost in the
depths of the compiler, leading to suboptimal code generation unless
that alignment information is available elsewhere (and it often is).

I think a far more useful design of this library would be providing
standard ways to assert certain conditions.  For example:

simd::assert(simd::is_aligned(&v[0], 16))
for (...) {
}

(Of course one can do the above today in standard C++ but the above is
more readable.)

and:

simd::assert(simd::no_overlap(v, w))
for (...) {
}

or even for the old vectorheads:

simd::assert(simd::ivdep)
for (...) {
}

Provide simple things the compiler can recognize via pattern matching
and we'll be a long way to getting the compiler to autovectorize.

I like simd::allocator to provide certain guarantees to memory managed
by containers.  That plus some of the asserts described above could help
generic code a lot.

Other questions about the library:

What's under the operators on pack<>?  Is it assembly code?

I wonder how pack<T> can know the best vector length.  That is highly,
highly code- and implementation-dependent.

How does simd::where define pack<> elements of the result where the
condition is false?  Often the best solution is to leave them undefined
but your example seems to require maintaining current values.

How portable is Boost.simd?  By portable I mean, how easy is it to move
the code from one machine to another get the same level of performance?

I don't mean to be too discouraging.  But a library to do this kind of
stuff seems archaic to me.  It was archaic when Intel introduced MMX.
If possible, I would like to see this evolve into a library to convey
information to the compiler.

                              -Dave