KSpam writes:
I've discovered a situation where using boost::array results in a 2-fold performance degradation over other array types, including C arrays, tr1::array, and a simple handwritten array class.
In your build environment, ensure that you ARE NOT defining _DEBUG, and that you ARE defining NDEBUG. These flags can make a significant difference in run-time performance.
Setting NDEBUG took care of it. Thanks. :)
While the tr1::array performs well, I was suprised to find that it pads the array, so sizeof(tr1::array<3,float>) == sizeof(tr1::array<4,float>). Is that a requirement of tr1::array?
It is very strange that you see a performance difference between tr1::array and boost::array. I think that boost::array was used as a submission for tr1::array (they are likely one and the same).
The tr1::array does not do range checking or an assert in operator[]. As for the alignment, this explains it: from gcc tr1/array: value_type _M_instance[_Nm ? _Nm : 1] __attribute__((__aligned__)); This is in the implementation of tr1::array, for gcc's standard C++ library, which is used by Intel C++. I sure would like to know the rational for putting in the alignment attribute, as it changes the code in a very non-trivial way. -bgreen