Re: [eigen] Allocation policy of eigen decompositions

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 :)

> 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.

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

> - 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.

> - 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.

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.
>