Re: [eigen] Pre-allocating LU objects

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


The FullPivLu ctor taking two ints is there in Eigen3, in
Eigen/src/LU/FullPivLU.h, and as you can see in the initialization
list, it does allocate the LU matrix and other data members. See
recent thread with Adolfo on this list, he added that feature to all
our decompositions.

Benoit

2010/5/21 Manoj Rajagopalan <rmanoj@xxxxxxxxx>:
>
> I don't seem to be able to find these names in Eigen3. Were they part of
> Eigen2?
>
> thanks,
> Manoj
>
>
>
> On Friday 21 May 2010 01:22:24 pm Vincent Lejeune wrote:
>> As far as I know, there is already a constructor of MatrixPivLU that takes
>> 2 ints. However I don't know if it does allocate a matrix...
>>
>> MatrixPivLu::Compute(matrix) does copy your matrix in its m_lu member
>> before doing any computation, performance may suffer. I suggest you use the
>> lower level makeluinplace() method if performance is critical in your
>> application.
>>
>> --------------------------------------------------
>> From: "Manoj Rajagopalan" <rmanoj@xxxxxxxxx>
>> Sent: Friday, May 21, 2010 6:46 PM
>> To: <eigen@xxxxxxxxxxxxxxxxxxx>
>> Subject: [eigen] Pre-allocating LU objects
>>
>> > Hi,
>> >
>> >   I am writing code where I am pre-allocating a bunch of Eigen3 objects
>> > and
>> > reusing them O(10^5) times in my simulation. Therefore, I am trying to
>> > push
>> > as much as possible of the memory allocation to the sim initialization
>> > before
>> > the main loop.
>> >
>> >   FullPivLU and PartialPivLu don't seem to have constructors that just
>> > resize
>> > them initially. They seem to get resized only when a matrix is passed as
>> > CTOR
>> > argument or when the compute() method is called. My sim uses the default
>> > CTOR
>> > and calls compute() later with the matrix to be factorized but the size
>> > of the matrix is the same throughout.
>> >
>> >   Most resize methods check the provided sizes against the currently
>> > allocated size before actually performing the new[] and I am guessing
>> > Eigen
>> > code does this too. So the first call to ??PivLU::compute() in my code
>> > should
>> > cause allocation and the rest of them should be no-ops because I am
>> > always solving the same-size matrix. Am I right in concluding that the
>> > performance
>> > hit due to invasive scratch-memory allocation in ??PivLU should therefore
>> > be
>> > minimal?
>> >
>> >   Will it be a good idea to include a CTOR that takes only size arguments
>> > (dynamic, not static) and allocates the scratch memory that these classes
>> > use
>> > at instantiation?
>> >
>> > Thanks,
>> > Manoj
>
>
>
>



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