Re: [eigen] Malloc-free dynamic matrices |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Malloc-free dynamic matrices*From*: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>*Date*: Fri, 5 Mar 2010 12:57:55 +0100*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=+Q4pZkrNcLYtLHpiB+NPrwHkK0KqXVXFlCDta+/kED4=; b=xpYqfQxmuD5OA+hh6jp4iCWdBz8kY1JZcQgJnrQ24f04pHMUIdFcWN6DU52ak9P7Uv 4EEsiT6kYJmC+oqc1TLv3Pnr4kZ0Xzm7XoIMIyxxAdhNiPCzIYfvKhRnHz99FZ5Dfb7e sjTZC72L/dSezg/RPKe/0kHOyecX0zZEeTe/Y=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=NywdLXEtxm8eXgO7yb6Zj22OH86qgvq8MALF0f+ikQvcHHllUcfLZEtUsDdXsb2ZGI KhO1X4Z2uSjYuI+jv1Y4fLKJ28SO2s1BbO2Zm/WQI9vAyl/ACKkXl9TCma+y5yZma6ql RB5sV3tJRh898+hb6UJeJ2zUkxuiKNKyRUCb8=

Hi Leon, On Fri, Mar 5, 2010 at 12:10 PM, leon zadorin <leonleon77@xxxxxxxxx> wrote: >> If some want MatrixXf to have memory caching/reservation and don't >> mind extra flags; whilst others don't want extra flags -- what are the >> reasons for not simply having a template type/policy called >> MemoryAllocator which will be used by MatrixXf (similar to STL/::std >> types using allocators)... At this point, it is hardly possible to follow this path. It would require enormous changes within Eigen which we will not be able to apply before 3.0 and more importantly it is not really that simple since currently parts of Eigen's allocation strategy is controlled by the template parameters of Matrix/Array. One example being alignment - we have plenty of algorithms that chose at compile time control paths depending on the alignment. IIRC, standard allocators as provided by the STL do not offer flags or other ways to determine alignment at compile time. > Because, even if a given basic Allocator is an empty class (i.e. no > data members whatsoever), the 1st case will use extra 1 to 8 bytes of > memory (i.e. in C++ a complete object cannot have size 0), but in > second case an EBO (empty-base-optimization) will be automatically > used by the compiler to guarantee that 0 extra bytes are associated > with an given empty (e.g. all static methods) Allocator sub-type > -object. We are well aware of this fact and it is once more a little bit tricky. First, we rely on a specific inheritance structure to get the expression templates working and in order to make Eigen extensible without minimal effort. Our inheritance tree also reflects (at least to some extent) how data is stored -- i.e. you cannot simple inject the allocator somewhere within the inheritance tree. Multiple inheritance on the other hand side is also not an option because e.g. MSVC fails to perform proper EBO in the presence of multiple inheritance. Regards, Hauke

**References**:**[eigen] Malloc-free dynamic matrices***From:*Márton Danóczy

**Re: [eigen] Malloc-free dynamic matrices***From:*Benoit Jacob

**Re: [eigen] Malloc-free dynamic matrices***From:*Gael Guennebaud

**Re: [eigen] Malloc-free dynamic matrices***From:*Benoit Jacob

**Re: [eigen] Malloc-free dynamic matrices***From:*Gael Guennebaud

**Re: [eigen] Malloc-free dynamic matrices***From:*Benoit Jacob

**Re: [eigen] Malloc-free dynamic matrices***From:*Gael Guennebaud

**Re: [eigen] Malloc-free dynamic matrices***From:*Eamon Nerbonne

**Re: [eigen] Malloc-free dynamic matrices***From:*leon zadorin

**Re: [eigen] Malloc-free dynamic matrices***From:*leon zadorin

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Malloc-free dynamic matrices** - Next by Date:
**[eigen] If Eigen adds a tiny shared library (was: Malloc-free dynamic matrices)** - Previous by thread:
**Re: [eigen] Malloc-free dynamic matrices** - Next by thread:
**Re: [eigen] Malloc-free dynamic matrices**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |