Re: [eigen] Decrease in performances

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


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





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