Re: [eigen] new eigen2 release (2.0.12) runs slower than 2.0.0 ?

[ Thread Index | Date Index | More Archives ]

2010/3/2 leon zadorin <leonleon77@xxxxxxxxx>:
> On 3/2/10, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> What you report sounds very interesting but we indeed need more
>> details in order to do anything about it. Ideally, if you could
>> produce a self-contained, compilable benchmark...
>> Here are some ideas.
> Great -- thanks for that -- I'll try to run those as soon as I get
> some free time for this issue.
> In the meantime, I had compiled/ran with some of the different
> versions of eigen2 and it would appear at this stage that the slowdown
> was introduced in 2.0.7 (i.e. up to, and including, 2.0.6 there is no
> slowdown) yet at 2.0.7 there is a distinct/noticeable slowdown.

Very interesting!

Have a look at the 2.0.7 changelog:

I don't see many things there that could have caused the regression. I
see mostly one:

"finish syncing Memory.h with the devel branch. This is cleaner and
fixes a warning. The choice of system aligned malloc function may be
affected by this change."

If your program is spending a significant proportion of its runtime
allocating memory, then it may have been significantly affected by

Ideally, if you could run your program in a real profiler to know how
much time it spends in ei_aligned_malloc, that would be optimal.

Otherwise here's something you can do that's very simple and already
potentially enough:

Open Eigen/src/Core/util/Memory.h

look for ei_aligned_malloc()

you can see a lot of #ifdefs here to select the right aligned malloc
function for the platform.

Can you add some #error's there to check which path is actually taken
on your platform? On both 2.0.0 and 2.0.7?


> Just in case if you might find this interesting before I get around to
> trying your suggestions...
> Kind regards
> Leon.
>> First let's check for potentially stupid compiler optimizations:
>>  - what happens if you remove -ffast-math?
>>  - what happens if you replace -O3 by -O2 ?
>> Is it 32bit or 64bit code?
>> If you disable vectorization (EIGEN_DONT_VECTORIZE) on both sides, how
>> does performance compare?
>> Benoit
>> 2010/3/1 leon zadorin <leonleon77@xxxxxxxxx>:
>>> Hi all -- just a generic question w.r.t. benchmarking being done to
>>> compare older vs newer eigen2 releases to see if, inadvertently, there
>>> are performance-related regressions...
>>> I have noticed that v 2.0.12 appears to have slowed down in comparison
>>> to 2.0.0_1 ...
>>> Currently, it's too time-consuming for me to unwind the code for a
>>> particular bottleneck -- I have simply noticed that a complex function
>>> (log-likelihood calculations made up from large dynamic matricies of
>>> mainly column-major layout with some exp, cwise, select, etc. calls)
>>> are taking ~3.4 seconds to calculate with 2.0.12 whilst taking ~3.1
>>> seconds with the 2.0.0 (exactly same app's code and compilation
>>> options (e.g. -DNDEBUG -O3 -ffast-math -march=native on E6550 core2
>>> duo cpu -- implying SSE3 et al, eigen_vectorization macros etc etc
>>> etc)... running with gcc 4.4 (threading model single) on FreeBSD with
>>> drawf eh.
>>> My current question would be if the new versions/releases of Eigen do
>>> undergo the comparative (to earlier versions) performance-related
>>> benchmarks tests to find any performance regressions et al?
>>> The benchmarks page
>>> appears to list march, 2009 (oldish) as the date for benchmarks?
>>> ... and it only compares eigen2 vs other libs... are there any
>>> already-done marks w.r.t. eigen vs eigen of different versions out
>>> there?
>>> Kind regards
>>> Leon.

Mail converted by MHonArc 2.6.19+