Subject: Re: [boost] [gsoc] boost.simd news from the front.
From: Gruenke, Matt (mgruenke_at_[hidden])
Date: 2011-06-10 22:22:16
David, based on previous threads concerning the Boost.SIMD GSoC project, I think what you're describing is simply a different library than what they're trying to build. I feel I have a good enough understanding of their proposal and it fits real needs that I have--needs which I feel I understand, having heretofore satisfied them with my own, less-refined/elegant solutions.
While what you're describing sounds appealing, I'm finding your description very abstract and I think more work needs to be done to demonstrate whether and how those goals can be realized. Perhaps you might find more support for your ideas, if you can make a more convincing case for the feasibility of implementation and the practicality of using such a library. To be honest, I'm actually skeptical that even with the extensions implemented by the majority of Boost-supported compilers, C++ is sufficiently expressive to get very far towards your ideal, though I'd be happy for someone to demonstrate otherwise.
At present, I believe that Boost.SIMD, as previously defined, would provide me with significant benefits. In my opinion, it's not worth holding up this work based on a loosely-defined set of ideals that don't fit its aims. I'm all for improving the state of auto-vectorization, but I want the more direct control that Boost.SIMD can give me, if/when auto-vectorization lets me down. Because they aren't portable & I cannot effectively use them in templates, I do not consider directly using intrinsics do as an acceptable fall-back.
Finally, consider that perhaps lessons can be learned in the course of development, porting, refining, and using Boost.SIMD. Also, maybe a higher-level effort can either stack on top of it, or at least reuse some of the code. Therefore, taking the feasibility & practicality of your vision as a given and disregarding the interests of people like myself, there's still potential for plenty of value to be derived from proceeding with Boost.SIMD as presently defined.
As a potential user, I support Joel & Mathieu continuing on their current track. That said, I hope work on explicit vector programming and auto-vectorization will continue. I would be interested and supportive of anyone exploring these areas, but I feel it's unnecessary and not worthwhile to hold up Boost.SIMD in hopes of something better.
Matt