Interest in static-sized valarray
Hello, I am trying to guage interest in a fixed sized version of valarray. I frequently found myself using small(-ish) compile-time known sized numeric arrays that don't justify the overhead of operator new in std::valarray but needed the math interface that valarray provided. I wrote a static-sized version of valarray for this purpose. It is modeled after std::valarray and implements about 90% of valarray's interface (obviously resizing is not included, neither is gslice due to the result not being known at compile time). Examples of it's use are: float _v[10] = {...}; size_t _i[5] = {...}; cvalarray<float,10> v1(_v); cvalarray<float,5> v2 = v1[cslice<0,5,2>()]; v1[cslice<0,3,3>()] = 0.0f; cvalarray<size_t,5> ind(_i); cvalarray<float,5> cvalB = v1[ind]; v2 *= (v2 + v1) / 2.0; //all of the usual math ops I have a complete implementation that models std::valarray in every possible way (with compile-time known limitations) including expression-template support for the numeric ops. My testing indicates a decent performance increase over gcc4's valarray for small number of elements <1000. If anyone has any interest, I'll put together some docs and throw it in the sandbox. Mike Tegtmeyer
In order to get an idea whether its gcc's valarray implementation at fault, you could evaluate macstl (macs and pcs) at www.pixelglow.com They cite significant speed improvements just by replacing gcc's valarray with their alternative (albeit they are concerned with vectorised operations almost exclusively). Its got a slightly restrictive license, but has valarrays and similar fixed size alternatives. A quick benchmark of this might convince you of what is worth pursuing. FWIW wrapping simple C arrays and using 'restrict' seems to work as well in many optimising compilers I've looked at on the PC. Something like macstl wins when you have longer operations that can make use of expression templates. I'd LOVE to see something like MacSTL developed for Boost. I haven't really been following MTL recently, but some smart people are working on it behind the scenes. I'm hoping that can be used as a framework for an alternative. Paul
Sounds useful - if only to some people. Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Tegtmeyer | Sent: 27 January 2006 19:40 | To: boost@lists.boost.org | Subject: [boost] Interest in static-sized valarray | | Hello, | | I am trying to guage interest in a fixed sized version of valarray. I | frequently found myself using small(-ish) compile-time known sized | numeric arrays that don't justify the overhead of operator new in | std::valarray but needed the math interface that valarray provided. I | wrote a static-sized version of valarray for this purpose. It | is modeled | after std::valarray and implements about 90% of valarray's interface | (obviously resizing is not included, neither is gslice due to | the result | not being known at compile time). Examples of it's use are: | | float _v[10] = {...}; | size_t _i[5] = {...}; | | cvalarray<float,10> v1(_v); | cvalarray<float,5> v2 = v1[cslice<0,5,2>()]; | v1[cslice<0,3,3>()] = 0.0f; | | cvalarray<size_t,5> ind(_i); | cvalarray<float,5> cvalB = v1[ind]; | | v2 *= (v2 + v1) / 2.0; | //all of the usual math ops | | I have a complete implementation that models std::valarray in every | possible way (with compile-time known limitations) including | expression-template support for the numeric ops. My testing | indicates a | decent performance increase over gcc4's valarray for small number of | elements <1000. | | If anyone has any interest, I'll put together some docs and | throw it in | the sandbox. | | Mike Tegtmeyer | | _______________________________________________ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/boost |
participants (4)
-
John Maddock -
Michael Tegtmeyer -
Paul A Bristow -
Paul Baxter