Re: [eigen] Malloc-free dynamic matrices

[leon zadorin <leonleon77@xxxxxxxxx>]

On 3/3/10, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:
> On Tue, Mar 2, 2010 at 6:16 PM, Benoit Jacob
> <jacob.benoit.1@xxxxxxxxx>wrote:
>
>> 2010/3/2 leon zadorin <leonleon77@xxxxxxxxx>:
>> > On 3/3/10, leon zadorin <leonleon77@xxxxxxxxx> wrote:
>> >> On 3/3/10, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> >>> 2010/3/2 Márton Danóczy <marton78@xxxxxxxxx>:
>> >> [...]
>> >>>> The only API changes are a new option NeverRealloc (the name is maybe
>> >>>> not the best) and a method reserve(int size) that allocates the
>> >>>> memory. Then, a Matrix<Scalar, Dynamic, Dynamic, NeverRealloc> keeps
>> >>>> track of its allocated size via the member variable m_size and each
>> >>>> mat.resize(rows, cols) only changes two ints instead of actually
>> >>>> allocating memory. If rows*cols < m_size, an assertion
[...]
>> > To clarify -- I'm getting at saying that one may not need patching
>> > anything in eigen in the first place, and by simply using the
>> > already-existing API of Map<> objects one could achieve what the
>> > original poster wanted :-)
>>
>> Yes, that sounds like a very good idea. It may require minor API
>> additions to class Map to make it convenient for Marton, but that's
>> still much lighter than the proposed patch.
>>
>>
> In practice, being able to reserve memory is a really important feature.
> Even though it is currently possible to achieve the same using either a big
> matrix + blocks, or a std::vector + a map, such approaches are not very
> convenient for the user. So having such a feature directly inside Eigen is
> really important to me.

well... pseudo-code wise we already could have something like the
following with a very small change(s) to API as per Benoit's post:

double * reserved(aligned_alloc(8192));

// 3x3
Map<double> m(reserved, 3, 3);

// 10x10 -- resize w/o reallocation -- equivalent to NeverRealloc w/o
much repatching(?)
m.remap(reserved, 10, 10);

3 lines of code -- looks convenient-enough to me.

or, without making *any* changes to the API, one can use  new
Map<double> (reserved, 10, 10) with ::boost::{scoped, shared}_ptr (to
avoid adding 'remap' to API);

.... or even passing Map<double> obj. by value w.r.t. code which may
use the "resize-able" semantic-matrix objects. (if metadata copying
and returning is not a problem).

This would *still* appear to me as "waaaay convenient-enough".

So, personally, I don't really see the above as a huge overhead in
coding... at all -- esp. to justify adding more-complex code to the
Matrix itself when there (i.e. in existing Eigen API) are already
numerous options available to achieve the desired semantics.

For super-duper convenience, one could possibly, and easily, *wrap*
the above in a custom class (to hide the alloc and Map
visibility/implementation), but this would, indeed, be rather
trivial... more of a convenience class (i.e. an adapter... or a
facade... I don't want to split hairs ;-)

Speaking of adding new types/code -- I'd be leaning towards lesser
code --> lesser bugs --> lesser maintenance: esp. if the same
semantics/features can be achieved as compared to a greater-sized code
changes.

Anyway, just my 2 ignorant cents... I'll mainly be an observer here on
this list...

leon.