Re: [eigen] Allocation policy of eigen decompositions

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


2010/4/16 Adolfo Rodríguez Tsouroukdissian <dofo79@xxxxxxxxx>:
>
>
> On Fri, Apr 16, 2010 at 1:29 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> 2010/4/16 Adolfo Rodríguez Tsouroukdissian
>> <adolfo.rodriguez@xxxxxxxxxxxxxxxx>:
>> >
>> >
>> > On Thu, Apr 15, 2010 at 1:24 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
>> > wrote:
>> >>
>> >> 2010/4/15 Adolfo Rodríguez Tsouroukdissian
>> >> <adolfo.rodriguez@xxxxxxxxxxxxxxxx>:
>> >> > Hi Eigen devs,
>> >> >
>> >> > After a couple of weeks disconnected from the dev branch, and with
>> >> > the
>> >> > date
>> >> > of the Beta1 tag fast approaching,
>> >>
>> >> I was about to propose delaying beta1 and/or turning it into an alpha..
>> >
>> > OK. Please do update the wiki when the new release schedule is out, for
>> > we
>> > are following it somewhat closely :)
>>
>> Ah ok. The schedule was a shot in the dark made 6 months ago and it's
>> actually quite a miracle that we've come so close of actually making
>> it. I mean, the delay will probabably be ~ 1 month, which is little
>> compared to these 6 months.
>>
>> Today I want to finish with my eigen-storageorders fork, merge it,
>> then I'm available to discuss schedules.
>>
>> >>
>> >> > I'd like to ask about the status of a
>> >> > couple of topics that have been discussed in this (and another)
>> >> > thread:
>> >> >
>> >> > - It was mentioned that decompositions would have a constructor with
>> >> > size
>> >> > parameters. Is this API addition still on?. I just checked the two
>> >> > SVD's
>> >> > on
>> >> > tip and it is not yet the case
>> >>
>> >> It is still planned, it is not yet implemented.
>> >
>> > I've been playing with this a bit, and I could send a patch that:
>> > - Adds a constructor with size parameters for all decompositions that
>> > still
>> > don't have one
>> > - Makes all temporary matrices class members so they can too be
>> > preallocated
>> > in the above mentioned constructor. This is to ensure that calls to
>> > decomposition::compute(const MatrixType&) will not perform heap
>> > allocations
>> > when dynamic matrices are used.
>>
>> Excellent ideas, I would be really happy about such a patch!
>>
>> >
>> > The patch is pretty straightforward to implement and I'll probably be
>> > taking
>> > a shot at it today, so if you see any potential conflicts with
>> > to-be-implemented additions, please let me know
>>
>> No conflict. But it will take you some effort, because we have a dozen
>> decompositions. Extra bonus points for covering this somehow by unit
>> tests!
>
>
> What would you expect from such a test? to check that the parameter size
> constructor exists and does not throw, or would you also want to verify
> whether the sizes of the preallocated class members are correct?.
> For the latter to work, we would probably have to subclass the
> decompositions to gain access to the (protected) class members. These
> (simple) subclasses would exist only in the test files.

Oh just a simple test checking that it compiles, would already be
great. Since eigen is a template library, such tests are our only way
of detecting compilation errors.

Benoit

>
> Best,
>
> Adolfo
>
>>
>> >
>> >>
>> >> > - What's the status on computing decompositions in place, and the
>> >> > possibility of making this work on blocks?
>> >>
>> >> Both still planned, both not yet implemented.
>> >
>> > I don't have an immediate use case for performing decompositions on
>> > blocks,
>> > and since in-place decompositions will likely have to take blocks into
>> > account, I'm not jumping in on this one.
>>
>> OK.
>>
>> >
>> >>
>> >> > - Will optimized matrix products between smallish matrices (size <
>> >> > 50x50)
>> >> > involve heap allocations?. A previous post said that on Linux (which
>> >> > is
>> >> > my
>> >> > case) alloca() is used so no heap (but rather stack) allocations. Am
>> >> > I
>> >> > understanding this correctly?
>> >>
>> >> Yes, on linux we are using stack allocation there. There are plans to
>> >> do that on MSVC too. The threshold is controlled by
>> >> EIGEN_STACK_ALLOCATION_LIMIT. See Core/util/Memory.h.
>> >
>> > Thanks for the pointer to the relevant source file :). I just verified
>> > this
>> > behavior.
>>
>> Cheers
>> Benoit
>>
>>
>> >>
>> >> Roadmap-wise, here's how things are looking for me:
>> >>  - i'm currently knee deep in very deep changes with the class
>> >> hierarchy, storage orders, and fully supporting 0 and 1 sizes.
>> >>  - once i'm done i want to finish the cleanup of renaming "Matrix" to
>> >> "Object" wherever needed, etc
>> >>  - once i'm done i must do the new SVD
>> >>
>> >> That i'm sure to be able to do by early May. Then I start my new job
>> >> so will have less time.
>> >>
>> >> Help with the above-discussed items is very welcome :)
>> >>
>> >> Benoit
>> >>
>> >> >
>> >> > Thanks and cheers,
>> >> >
>> >> > Adolfo
>> >> >
>> >> >
>> >> > --
>> >> > Adolfo Rodríguez Tsouroukdissian, Ph. D.
>> >> >
>> >> > Robotics engineer
>> >> > PAL ROBOTICS S.L
>> >> > http://www.pal-robotics.com
>> >> > Tel. +34.93.414.53.47
>> >> > Fax.+34.93.209.11.09
>> >> > AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos,
>> >> > pueden
>> >> > contener información privilegiada y/o confidencial que está dirigida
>> >> > exclusivamente a su destinatario. Si usted recibe este mensaje y no
>> >> > es
>> >> > el
>> >> > destinatario indicado, o el empleado encargado de su entrega a dicha
>> >> > persona, por favor, notifíquelo inmediatamente y remita el mensaje
>> >> > original
>> >> > a la dirección de correo electrónico indicada. Cualquier copia, uso o
>> >> > distribución no autorizados de esta comunicación queda estrictamente
>> >> > prohibida.
>> >> >
>> >> > CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s)
>> >> > may
>> >> > contain confidential information which is privileged and intended
>> >> > only
>> >> > for
>> >> > the individual or entity to whom they are addressed.  If you are not
>> >> > the
>> >> > intended recipient, you are hereby notified that any disclosure,
>> >> > copying,
>> >> > distribution or use of this e-mail and/or accompanying document(s) is
>> >> > strictly prohibited.  If you have received this e-mail in error,
>> >> > please
>> >> > immediately notify the sender at the above e-mail address.
>> >> >
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Adolfo Rodríguez Tsouroukdissian, Ph. D.
>> >
>> > Robotics engineer
>> > PAL ROBOTICS S.L
>> > http://www.pal-robotics.com
>> > Tel. +34.93.414.53.47
>> > Fax.+34.93.209.11.09
>> > AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos,
>> > pueden
>> > contener información privilegiada y/o confidencial que está dirigida
>> > exclusivamente a su destinatario. Si usted recibe este mensaje y no es
>> > el
>> > destinatario indicado, o el empleado encargado de su entrega a dicha
>> > persona, por favor, notifíquelo inmediatamente y remita el mensaje
>> > original
>> > a la dirección de correo electrónico indicada. Cualquier copia, uso o
>> > distribución no autorizados de esta comunicación queda estrictamente
>> > prohibida.
>> >
>> > CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
>> > contain confidential information which is privileged and intended only
>> > for
>> > the individual or entity to whom they are addressed.  If you are not the
>> > intended recipient, you are hereby notified that any disclosure,
>> > copying,
>> > distribution or use of this e-mail and/or accompanying document(s) is
>> > strictly prohibited.  If you have received this e-mail in error, please
>> > immediately notify the sender at the above e-mail address.
>> >
>>
>>
>



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