Re: [boost] SIMD EDSL blues (was [XInt] Some after thoughts)

Subject: Re: [boost] SIMD EDSL blues (was [XInt] Some after thoughts)
From: Joel Falcou (joel.falcou_at_[hidden])
Date: 2011-03-15 15:55:35

On 15/03/11 20:47, Simonson, Lucanus J wrote:
> I'm not so sure we took that different and angle on it, perhaps more a different point of view on the results based on different circumstances.  Providing a more productive syntax than the intrinsics themselves was pretty much what we had in mind for the simd ET library.  I think the fact that the compiler was pre-production in our case meant that everywhere your experience tells you the compiler should do the right thing our experience was that it often did not and we kept having to go into the generated assembly code and figure out what went wrong.  The other very significant disadvantage the compiler put us at with our ET implementation efforts was it was using an old version of EDG frontend that had quadratic compile time for template instantiation.

Ah well, blame the compiler then :p
> Also, given that we weren't abstracting away any of the complexity of the instruction set using the SIMD library wasn't any less complicated than intrisics, but the syntax errors were harder to understand.  The user couldn't expect to write templated code that worked for int or float types and replace int with simd_type and get anything reasonable except in the very simplest of cases since that limits us to only instructions that map to operations on basic types and algorithms that aren't branchy.  Given that designing the vector algorithms was hard with or without the wrapper, requiring a strong understanding of the instruction set, it wasn't clear that a more productive syntax than intrinsics themselves was really going to be of much benefit, since that wasn't where time was being spent anyway.

Well, our stuff just works as a drop in replacement. Branches has tu be 
abstracted away either using some where(c,a,b) constructs that mapped on 
w/e is there or by using horizontal branching. As a test, you can check 
that all our trigonometric functions are basically using the same stuff 
for both SIMD and scalar with great performances.
We also have a Range interface on them so you can just ditch them into a 
regular std algorithm and have your cake.

I think you got distracted by working with some unstable compiler. I can 
tell it works when you look at it in a sane environment.