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

Subject: Re: [boost] SIMD EDSL blues (was [XInt] Some after thoughts)
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-03-15 15:47:14

Joel Falcou wrote:
...
> In terms of integer stuff at hand, this means the high level algorithm
> should be expressed as a combination of lifted concepts where the
> actual 
> bit twiddling can be aggregated in logical, semantic-rich, functions
> operating on w/e. Let the SIMD DSL provide such function, implement
> them 
> as properly needed (use the proper specialized itnrinsic or add
> pattern replacer) and voila.
> 
> No need to dumb down the feature set of the SIMD DSL, it will grow
> naturally as cocnept requiring it and some special stuff will arise
> from algorthimic analysis, much more like normal code. And int his
> case, 
> you'll see that these problem of optimality actually lessens as they
> willbe captured at high level by your concept based analysis.
> 
> I bet we have a lot of stuff to exchange and argue on the subject as
> we 
> seems to have taken radically different angle on the matter, I will be
> glad if we can go over our first premises of arguments and maybe try
> to 
> see if our respective experiences in some concrete area can't be
> shared 
> for the greater good of everyone. Especially, if you have actual
> algorithm you see as something hard that didn't fit your design (and
> by concrete I mean a snapshot of code not a mere description in words
> were 
> both of us can misinterpret parts (see the CSE fiasco above :p) so we
> can look at the problem in our framework and see where problem arise.
> 
> Hoping to help :)

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.  This problem also gives me headaches with the Polygon library when compiled with the Intel compiler.  The compile time really is excessive.  This made using the ET wrapper too inconvenient.  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.

Regards,
Luke