Re: [eigen] Decrease in performances

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

OK, my benchmark was very similar. If you compile with optimization
-O2 -DNDEBUG, then you should not see any slowdown anymore. The
difference between 3.1 and head is that I added missing runtime
assertions.

I think this close this issue.

gael

On Thu, Jun 28, 2012 at 10:53 AM, Maxime REIS <maxime.reis@xxxxxxxxx> wrote:
> Hi,
>
> The simple use of the resize method shows differences in perfs between
> versions of eigen.
> I built and ran the following snippet (without any gcc optimization flags) :
>
> # include <Eigen/Dense>
> # include <iostream>
> # include <sys/time.h>
>
> typedef Eigen::Matrix< double, Eigen::Dynamic, Eigen::Dynamic > matrixN;
> typedef Eigen::Matrix< double, 3, 3 > matrix3d;
>
> int main()
> {
>   int N=1e8;
>   long TICKS_PER_SECOND = 1e6;
>   struct timeval tv_start, tv_stop;
>
>   matrixN m1 = matrixN::Random(3,3);
>   matrix3d m2 = matrix3d::Random();
>
>   std::cout << "Resize dynamic size matrix\n  ";
>   long time_usec = 0;
>   ::gettimeofday(&tv_start, NULL);
>   for(int i=0; i<N; i++)
>     m1.resize(4,4);
>   ::gettimeofday(&tv_stop, NULL);
>
>   time_usec = ( tv_stop.tv_sec - tv_start.tv_sec ) * TICKS_PER_SECOND
>              + ( tv_stop.tv_usec - tv_start.tv_usec );
>   std::cout
>     << "average execution time = " << (double)time_usec/(double)N << "µs"
>     << std::endl;
>
>   std::cout << "Resize fixed size matrix (sic)\n  ";
>   time_usec = 0;
>   ::gettimeofday(&tv_start, NULL);
>   for(int i=0; i<N; i++)
>     m2.resize(4,4);  // Should send me to prison
>   ::gettimeofday(&tv_stop, NULL);
>
>   time_usec = ( tv_stop.tv_sec - tv_start.tv_sec ) * TICKS_PER_SECOND
>              + ( tv_stop.tv_usec - tv_start.tv_usec );
>   std::cout
>     << "average execution time = " << (double)time_usec/(double)N << "µs"
>     << std::endl;
> }
>
> I built it with either eigen 3.0.3, eigen 3.1 or with the mercurial head.
> All tests were made and the same machine, with the same load, and were ran
> on turn several times, and the results were consistant. Here are the average
> execution times:
> - Eigen 3.0.3
>     Resize dynamic matrix : 12.2ns
>     'Resize' fixed size matrix (should be illegal) : 7.2ns
> - Eigen 3.1
>    Resize dynamic matrix : 12.2ns
>    'Resize' fixed size matrix : 10.6ns
> - Head
>   Resize dynamic matrix : 15.5ns
>   'Resize' fixed size matrix is illegal
>
> Hope this helps.
>
> Regards,
> Maxime
>
> P.S.: Not sure if useful, but my proc is an Intel(R) Core(TM) i7-2670QM CPU
> @ 2.20GHz, I'm running on Ubuntu 12.04, and compiling with gcc 4.6.3
>
> On 27 June 2012 15:36, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:
>>
>> On Wed, Jun 27, 2012 at 1:17 PM, Jitse Niesen <jitse@xxxxxxxxxxxxxxxxx>
>> wrote:
>> > On 26 June 2012 23:07, Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
>> > wrote:
>> >
>> >> Now about optimizing the check itself, before implementing subtle
>> >> mechanisms I'd like to see an example of any performance hit.
>> >
>> >
>> > Instead of optimizing the check, would it be possible to argue that it's
>> > the
>> > user's responsibility and not ours to ensure that row * col does not
>> > overflow (which we should of course clearly document)? In that case, the
>> > check would only need to take place when NDEBUG is not defined, but not
>> > in
>> > production code.
>>
>>
>> It might be an option too. I'm not against it.
>>
>> gael
>>
>>
>