Re: [eigen] about JacobiSVD's options

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

Hi,

2009/9/15 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> hi,
>
> the "Options" template parameter of JacobiSVD seems to be over-complicated.
>
> What about removing the Square/MoreColsThanRows/etc. stuff from the
> Option template parameter ? For small fixed sizes they can be
> automatically extracted at compile time, and for dynamic sizes .. well
> who care ? Moreover in the worst case, if the user use various matrix
> shapes he can generate 3 instances of JacobiSVD for the same matrix
> type...

The reason for making these template parametes is to avoid compiling
useless code: so it allows to compile much faster, and produce much
smaller code.

When you give JacobiSVD a rectangular matrix, it does a full-pivoting
QR to reduce to the case of a square matrix. This step has to be done
differently depending on whether m>=n or m<=n. I already have made
sure that these 2 paths use the same instantiation of
FullPivotingHouseholderQR, so it is only instantiated once. Still,
that instantiation is relatively expensive (as is any householder QR
--- the full pivoting version is only marginally more expensive to
compile).

That's why I provided the user a way to avoid compiling this code if
it's not going to be used. By default the code is compiled and the
user doesn't need to care about anything, just use
JacobiSVD<MatrixXf>, but an advanced user may be interested in that.

Here is a benchmark for compilation times and code size. (attached a.cpp)

Result:
=== 23:23:18 ~$ g++ a.cpp -o a -I eigen2 -O2 && time g++ a.cpp -o a -I
eigen2 -O2 -DSVDOPTIONS=Square && ls -l a

real    0m2.460s
user    0m2.348s
sys     0m0.108s
-rwxr-xr-x 1 bjacob users 51007 sept. 15 23:23 a

=== 23:23:29 ~$ g++ a.cpp -o a -I eigen2 -O2 && time g++ a.cpp -o a -I
eigen2 -O2 && ls -l a

real    0m6.530s
user    0m6.372s
sys     0m0.152s

So, passing the Square template parameter almost divides compilation
times and code size by 3.

(g++ 4.4.1 x86)

>
> Also, I'm wondering whether the ComputeU and ComputeV parameters could
> be runtime parameters ? I doubt there is any performance difference,
> but of course to be sure we should bench it. If I have time I'll do
> it.

Hm, that makes more sense indeed, we need to bench, not only
performance but code size and compilation times.
At the same time, making them runtime params is good in itself as it
can mean fewer template instantiations, precisely.

Benoit

#include<Eigen/SVD>

using namespace Eigen;

#ifndef SVDOPTIONS
#define SVDOPTIONS 0
#endif

template<typename MatrixType>
EIGEN_DONT_INLINE typename MatrixType::Scalar f(const MatrixType& m)
{
  JacobiSVD<MatrixType,SVDOPTIONS> svd(m);
  return svd.singularValues()[0];
}

int main()
{
  f(MatrixXf(10,10));
  f(MatrixXd(10,10));
}