[IPOL discuss] use of Eigen for PCA/SVD computation in demo blm_color_dimensional_filtering

Pascal Monasse monasse at imagine.enpc.fr
Tue May 24 09:20:13 CEST 2011

Hi all,

I agree with Nicolas. We are all for simple, readable algorithms, but when it 
comes to an SVD, we just want something that is simple to use, stable and fast 
(our own algorithms have plenty CPU cycles to waste for other things). If it 
uses BLAS, this is fine, it is a standard for matrix-vector operations. Such 
operations could of course be trivially rewritten but would be slower.

If our algorithm has numerous dot products to compute and it is critical for 
efficiency, I am all for using an optimized library, as long as it remains clear 
in our code that we are simply computing a dot product.


On Monday, May 23, 2011 09:15:13 PM Nicolas Limare wrote:
> > We should do some experiments to compare performances before I'm
> > convinced.  But in my view, chosing SSE instructions should be the
> > task of the compiler, not of an optimized library.
> In principle I agree, but I have an experience eith the ASIFT
> code. The computation of distances between vectors (sums of absolute
> values) was time consuming, and the compiler was not using vector
> instructions. By modifying the data types and instructions order, we
> could get the compiler to use the some vector instructions and it
> speeded up the code bu a measurable factor. Without hardcoding these
> optimizations, with portable, pure C and perfectly readable code.
> > There is no reason to think that a trivial two-line C program that
> > computes the dot product can not be as fast as a fancy library.  The
> > compiler should be fancy enough to select the appropriate
> > instructions by itself.
> CPUs are now quite different fromt he typical Turing machine, and
> properly choosing and ordering the instructions has an important
> impact on the performances. Jérôme Darbon has much more expertise
> and experience with these low-level details, he can probably explain
> in detail (and correct my mistakes).
> And, of course, I completely agree with Miguel that we don'ty want to
> deal with this level of optimization. We just want to choose the best
> possible solution if it is easily available, portable, perfectly
> readable, etc... But it's good to know how to speed up a code,
> sometimes we need it. If simply compiling with...
>     cc foo.o -Lcblas -o program
> ...results in a program 20% faster than...
>     cc foo.o gsl_cblas.o -o program
> ...why not benefit from this speedup?

More information about the discuss mailing list