Boost logo

Boost :

Subject: Re: [boost] [gsoc] boost.simd news from the front.
From: Joel falcou (joel.falcou_at_[hidden])
Date: 2011-06-11 12:21:44


On 11/06/11 10:45, David A. Greene wrote:

> Vectorizing compilers exist today. They've existing since the 1970's.

I still thinking you're mixing SIMD ISA and vector machine ...

As I see it, Vector machine as in
http://en.wikipedia.org/wiki/SIMD#Chronology existed since 197x. BUT,
what you purposely
fake to not understand is that we don't care about this type of machine
and focus on this http://en.wikipedia.org/wiki/SIMD#Hardware which
exists since 1994 or such and for which the use cases, idioms and
techniques are completely different.

So yeah, autovectorization on huge CRAY system is done automatically
with results I really don't know about and for which i dont care as it
is not our target audience but I concede it is maybe good or w/e.

Now, strictly speaking on SIMD ISA in x86/PPC familly, no,
auto-vectorizing is not that good and still require manual input,
functions library and so forth. So in this case, our claims hold
and boost.simd has to been has a set of enabling tools for helping
people writing generic code able to be vectorized.

Learn that Template Meta-Programming as we use it there don't prevent
compiler to do stuff afterward our code generation process. They usually
do (inlining or loop unrolling etc ...) and we let them do so as they
wish cause they fill the gaps we can not access with our library.

Did you ever go to the last slides where we have the Range based
functions code where no SIMD stuff leak but yet is able to eat up
SIMDRange ? I fail to see how this is *not* a correct way of designing
code in C++ : - relying on range abstraction + providing a Range with
proper properties. And this kind of code is largely sufficent and
generic to handle most classical use cases with high level of
performances. Dealing with microarchitecture never went that far as
manual code goes, and I don't really get your obsession with that.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk