I had a look into multi_array's implementation and i can see a number of opportunities to improve the efficiency multi_array perhaps by quite a lot with only very minor changes. Why are we not taking advantage of the fact that that allocation/de-allocation is separate from construction/destruction? i see in a number of places that multi_array is redundantly default constructing elements (like in multi_array::allocate_space) and then copying new elements into the array for example in multi_array i see a lot of: allocate_space(); // allocate memory then default construct std::copy(rhs.begin(),rhs.end(),this->begin()); instead why not just do an in-place copy construction from the outset, something like: allocate_space(); // a new version which only allocates memory, no construction std::uninitialized_copy(rhs.begin(), rhs.end(), this->begin()); When i create a multi_array i want to be able to "reserve" the shape of a multi_array and then incrementally add new elements via in-place copy construction or even better using in-place factories. We do not even need to explicitly store the size if we take advantage of uninitialized and initialized elements, just like how modern implementations of std::vector do. Another minor thing is to apply the empty member/base optimizations (EMO/EBO) for allocator types which are empty in size. So i would like to know the rationale for these, since i need something like multi_array i may just make the adjustments myself. _________________________________________________________________ Windows Live Messenger has arrived. Click here to download it for free! http://imagine-msn.com/messenger/launch80/?locale=en-gb
I was interested in using multi_array for some numeric work, but a trivial benchmark of indexing operations, comparing C-style array, ublas, and multi_array showed that multi_array was many times slower than ublas for this common operation.
Hi Korcan, Your proposals for improving multi_array's performance sound interesting. Unfortunately I don't have time right now to pursue this, but I am interested in improving multi_array's performance. If you make these changes to your copy of Boost and experience performance improvements (without breaking regressions :) ), feel free to send me patches and I will see about applying them to the library. Thanks, ron On Dec 1, 2006, at 5:24 AM, Korcan Hussein wrote:
I had a look into multi_array's implementation and i can see a number of opportunities to improve the efficiency multi_array perhaps by quite a lot with only very minor changes.
Why are we not taking advantage of the fact that that allocation/de- allocation is separate from construction/destruction? i see in a number of places that multi_array is redundantly default constructing elements (like in multi_array::allocate_space) and then copying new elements into the array for example in multi_array i see a lot of:
allocate_space(); // allocate memory then default construct std::copy(rhs.begin(),rhs.end(),this->begin());
instead why not just do an in-place copy construction from the outset, something like:
allocate_space(); // a new version which only allocates memory, no construction std::uninitialized_copy(rhs.begin(), rhs.end(), this->begin());
When i create a multi_array i want to be able to "reserve" the shape of a multi_array and then incrementally add new elements via in-place copy construction or even better using in-place factories.
We do not even need to explicitly store the size if we take advantage of uninitialized and initialized elements, just like how modern implementations of std::vector do.
Another minor thing is to apply the empty member/base optimizations (EMO/EBO) for allocator types which are empty in size.
So i would like to know the rationale for these, since i need something like multi_array i may just make the adjustments myself.
_________________________________________________________________ Windows Live™ Messenger has arrived. Click here to download it for free! http://imagine-msn.com/messenger/launch80/?locale=en-gb
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost
participants (3)
-
Korcan Hussein -
Neal Becker -
Ronald Garcia