Pelles C forum
Pelles C => General discussions => Topic started by: LaVanTien on April 23, 2015, 04:32:54 PM
-
I run this code on vary compiler:
#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.
(http://i.imgur.com/yPyvldA.jpg)
- Seccond is MS VS 2013, the average runtime is 3.401000 s.
(http://i.imgur.com/QWKKzIP.jpg)
- Finally is Pelles C 8.00, the average runtime is 1.154000 s.
(http://i.imgur.com/FsGif8f.jpg)
The question is, what is going on here? Why Pelles C so fast?
-
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).
-
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. ;)
-
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.
#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
-
The compiler optimizes at low-level.
The programmer optimizes at high-level.
So those numbers are more your fault than the compiler's. :)
-
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.
-
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.
-
I would not say it is really better, but I use this two examples (with I found, I never know where) for testing.