Why Pelles C so fast?

[LaVanTien]

I run this code on vary compiler:

Code: [Select]

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

int main(void) {
  time_t begin,end;
  double spent;
  begin=clock();
  int n=0;
  for(int i=0;i<1000000000;i++)
    n++;
  end=clock();
  spent=(double)(end-begin)/CLOCKS_PER_SEC;
  printf("%d\n%lf\n",n,spent);
  return 0;
}

And here is the results:
- First is GCC 4.9.2, the average runtime is 3.600666 s.

- Seccond is MS VS 2013, the average runtime is 3.401000 s.

- Finally is Pelles C 8.00, the average runtime is 1.154000 s.


The question is, what is going on here? Why Pelles C so fast?

[Snowman]

By default, speed optimizations are turned on for a new Pelles C project.
See: Project Options -> Compiler -> Optimizations

With speed optimizations turned on, useless code may be removed by the compiler (including useless loops).

[AlexN]

If I try it on my computer, I get this results:
Pelles C with optimise off: 2.685
Pelles C with optimise on: 0.408
Tiny CC:                             2.695
gcc 4.9.2 with -O0:            2.655
gcc 4.9.2 with -O1:            0.417
gcc 4.9.2 with -O2 or -O3: 0.000

Your benchmark example is not very good, because the result of the loop is constant and a very good optimiser removes the hole loop and set n to the final result.

[LaVanTien]

Thanks Snowman and AlexN.

After I saw both of you suggest I decide to make an other benchmarks. This time is much hardcore than the one before.

Code: [Select]

#include<stdio.h>
#include<time.h>
#include<stdlib.h>

int main(void) {
  time_t begin,end;
  double spent;
  begin=clock();
  srand(time(NULL));
  unsigned long long int n=0;
  for(int i=0;i<20000;i++)
    for(int j=20000;j>0;j--)
      n+=i+j+rand()%10;
  end=clock();
  spent=(double)(end-begin)/CLOCKS_PER_SEC;
  printf("%llu\n%lf\n",n,spent);
  return 0;
}

And the result is quite sad:
              Compiler                              First run | Seccond run | Third run
GCC 4.9.2 (Maximum optimize)         4.461000 |   4.492000 |  4.508000
MS VS 2013 (Maximum optimize)    27.487000 | 27.268000 | 27.736000
Pelles C 8.00 (Maximum optimize)  12.230000 | 12.230000 | 12.199000

[Snowman]

The compiler optimizes at low-level.
The programmer optimizes at high-level.

So those numbers are more your fault than the compiler's. 

[jj2007]

And the result is quite sad

No, it isn't:

  for(int i=0;i<20000;i++)
    for(int j=20000;j>0;j--)
      n+=i+j+rand()%10;

The two loops cost almost nothing, but rand may be implemented in very different ways. Speed and randomness can vary a lot. So you basically measuring the performance of one single instruction. Not meaningful.

[moreson]

And the result is quite sad:
              Compiler                              First run | Seccond run | Third run
GCC 4.9.2 (Maximum optimize)         4.461000 |   4.492000 |  4.508000
MS VS 2013 (Maximum optimize)    27.487000 | 27.268000 | 27.736000
Pelles C 8.00 (Maximum optimize)  12.230000 | 12.230000 | 12.199000

They might be using completely different implementations of rand() (might even e provided as an intrinsic on some implementations), C standard doesn't require any particular behavior, entropy, etc out of rand(), and a higher quality rand() function will obviously be slower.
Not a particularly useful benchmark.

[AlexN]

I would not say it is really better, but I use this two examples (with I found, I never know where) for testing.