on Tue Jan 20 2009, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
Hi Patrick,
On Tue, Jan 20, 2009 at 9:01 AM, Patrick Mihelich <patrick.mihelich@gmail.com> wrote:
The sense I'm getting from this discussion is that SIMD code generation is uninteresting, and that we should stick our heads in the sand and wait for the Sufficiently Smart Compilers to come along. OK, I sympathize with this. Writing functions using SIMD intrinsics is a bit of a distraction from the computer vision tasks I actually care about, but I have time budgets to meet and usually some work of this type has to be done.
Actually, I think you're missing the point (at least from what I'm saying).
I'm saying SIMD code generation ought to be the job of the compiler(s) for the platforms where they make sense.
Why are these SIMD operations different in that respect from, say, large matrix multiplications?
Now *if* you wanted to be able to specifically make it work, you can do something that others have already been doing: adding a layer of indirection.
I.e., a library?
Now this layer of indirection can be as clever as a DSEL (which I don't think it needs to be) or as simple as a function that switches implementations at compile time using preprocessor macros or some other facility. Now if you needed to optimize a set of operations that are specific to your field (like for example, applying a blur on a set of pixels represented by a set of floats) then I wouldn't find it hard to imagine having that specific part hand-optimized for your need.
Does this need another library? I wager to say it doesn't -- it's like saying you're implementing a DSEL in C++ to do simple mathematics.
Why do you say that? Do you routinely find yourself having to write non-portable code to do simple math in C++? Do you routinely find that the compiler generates inadequate simple math code? -- Dave Abrahams BoostPro Computing http://boostpro.com