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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk