[Bug c++/14563] octave built under Cygwin very slow

["paulthomas2 at wanadoo dot fr" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From paulthomas2 at wanadoo dot fr  2004-03-31 00:21 -------
Subject: Re:  octave built under Cygwin very slow

I realise from the silence that it cannot have been apparent from the 
last forward that we have understood where the problem lies with 
gcc-3.3.1 (cygming special).  It has nothing to do with sjlj, inspite of 
the profiling.  A significant difference has creapt in between new and 
malloc.  Normally, on just about every system that we have tested, new 
is about 50% slower than malloc.  In gcc 3.3.1-3 (cygming special) it is 
about 6-10 times slower. We have no idea why.

The following scrap of code demonstrates it (have used -O2 for compilation):

#include <iostream>
#include <stdio.h>
#include <time.h>
#include <vector>

using namespace std;

int main()
{
  long t1 = clock();
  for (int iloop = 0; iloop < 10000000; iloop++)
  {
     double *myarray;
     if ((myarray = new double [1]) == NULL)
     {
        cout << "unable to allocate my array at iloop=" << iloop <<  endl;
        exit(1);
     }
     delete [] myarray;
 }
 long t2 = clock();
 double delt1 = (double)( t2 - t1 )/ (double)(CLOCKS_PER_SEC);
 cout << "done looping time 1=" << delt1 << endl;
 long t3 = clock();

 for (int iloop = 0; iloop < 10000000; iloop++)
 {
   double *myarray = (double *)malloc(sizeof(double));
   if (myarray== NULL) { printf("alloc failed\n"); exit(1); }
   else free (myarray);
 }
 long t4 = clock();
 double delt2 = (double)( t4 - t3 )/ (double)(CLOCKS_PER_SEC);
 cout << "done looping time 2=" << delt2 << endl;

return 0;
}

Best regards

Paul Thomas



bangerth at dealii dot org wrote:

>------- Additional Comments From bangerth at dealii dot org  2004-03-25 14:36 -------
>SJLJ stands for "setjmp/longjmp". I'm not an expert in this field 
>(as I know virtually nothing about the gcc interiors anyway, I'm 
>just the bug database dude), but here's the idea: when you call 
>a function that may or may not throw an exception, and the calling 
>function needs to run destructors of local objects in case an exception 
>is thrown, you need to put down the address of the cleanup code somewhere. 
>One way to do this is to set this address via setjmp, and throwing an 
>exception then transfers control to this place via longjmp. This is expensive 
>since you have to call setjmp every time a cleanup is necessary. 
> 
>The other possibility is to use lookup tables that the compiler generates 
>statically, so this is cheap at run-time, but incurs some code overhead. If 
>you generate an exception, you have to somehow look up where to transfer 
>execution. Don't ask me how exactly this works, but it is to my best 
>knowledge how dwarf2 exception unwinding works. Corrections on this topic 
>my more knowledgable people are certainly welcome. 
> 
>Now back to the question how we can figure out what the problem is: if 
>using -fno-exceptions doesn't work, is there a possibility you repeat 
>your experiments with an octave version prior to the introduction of 
>exceptions? 
> 
>W. 
>
>  
>




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563