Poor performance with GNAT-GPL-2017

Poor performance with GNAT-GPL-2017

[Charly]

Hi,

when I found the new GNAT-GPL-2017 this morning I was happy and installed it at once.
But I was rather disappointed about the poor performance.
To be more precise:

When I switch to new hard- or software I allways check the performance with my private tool:
It solves Rubics Tabgle https://www.jaapsch.net/puzzles/tangle.htm with an ada programm, using one task per core.

With GNAT-GPL-2016 (gcc 4.9.4) it took about 0,4 sec to find both solutions,
with GNAT-GPL-2017 (gcc 6.3.1) it takes about 0,8 sec to find both solutions,
which means the program is slower by a factor of 2.

In both cases I use the following options: 
-O3 -gnatA -gnatn -funroll-loops -fPIC -gnatp -g -gnatW8 -gnatVn -mtune=amdfam10 -gnat12

Any ideas??

Sincerly
Charly

Re: Poor performance with GNAT-GPL-2017

[Jacob Sparre Andersen]

Charly <carl.weierstrass@googlemail.com> writes:

> In both cases I use the following options: 
> -O3 -gnatA -gnatn -funroll-loops -fPIC -gnatp -g -gnatW8 -gnatVn -mtune=amdfam10 -gnat12
>
> Any ideas??

Try different options.  Different GCC versions tend to give different
results with the same flags.  Some other combination my be more
efficient with GNAT-GPL-2017.

Greetings,

Jacob
-- 
"Two silk worms had a race. They ended up in a tie."

Re: Poor performance with GNAT-GPL-2017

[Robert Eachus]

On Saturday, June 10, 2017 at 7:23:34 AM UTC-4, Charly wrote:
 
> Any ideas??
 
Three ideas really.  First there may be some change in the tasking and rendezvous parts of GNAT-GPL that results in twice as many scheduling actions (or more) and thus the slowdown.  Most probable.

Second there is no guarantee that the tasking actions will be identical between the two instances.  Worst case, you have one thread which is the high pole in the tent starting later.  The "easy" way to check this is to take out the tasking and make the program single-threaded with identical program behavior.

You could run some tasking tests which I hope have been around forever (ACES), to see what changed in tasking timings.

Finally, and highly unlikely given the manitude of the timing change, the change in versions will change the order (to some extent) in which alternatives are tested.  These changes can result in the program run time being different because more instances are checked before determining that there is no valid way to continue from that point.  You could check this by putting in an instance counter that is incremented each time a tile is placed.  (Keeping separate counters for each task is an obvious optimization.)

It would be very interesting if the number of instances checked varied, either from run-to-run or compiler version to compiler version. 

Re: Poor performance with GNAT-GPL-2017

[Charly]

Am Sonntag, 11. Juni 2017 22:48:11 UTC+2 schrieb Robert Eachus:
> On Saturday, June 10, 2017 at 7:23:34 AM UTC-4, Charly wrote:
>  
> > Any ideas??
>  
> Three ideas really.  First there may be some change in the tasking and rendezvous parts of GNAT-GPL that results in twice as many scheduling actions (or more) and thus the slowdown.  Most probable.
> 
> Second there is no guarantee that the tasking actions will be identical between the two instances.  Worst case, you have one thread which is the high pole in the tent starting later.  The "easy" way to check this is to take out the tasking and make the program single-threaded with identical program behavior.
> 
> You could run some tasking tests which I hope have been around forever (ACES), to see what changed in tasking timings.
> 
> Finally, and highly unlikely given the manitude of the timing change, the change in versions will change the order (to some extent) in which alternatives are tested.  These changes can result in the program run time being different because more instances are checked before determining that there is no valid way to continue from that point.  You could check this by putting in an instance counter that is incremented each time a tile is placed.  (Keeping separate counters for each task is an obvious optimization.)
> 
> It would be very interesting if the number of instances checked varied, either from run-to-run or compiler version to compiler version.

Hi,

I made some tests with different number of tasks, but the factor of two between old and new is almost independent of that. I also checked the effect of option -gnato as Mark suggested, but the effect is negligible :

gnat-gpl-2017

$ ./bin/tangle 
using:  8 tasks    duration 851 ms

$ ./bin/tangle -t4
using:  4 tasks    duration 1.213 ms

$ ./bin/tangle -t2
using:  2 tasks    duration 2.346 ms

$ ./bin/tangle -t1
using:  1 tasks    duration 4.638 ms


gnat-gpl-2016

$ ./bin/tangle 
using:  8 tasks    duration 430 ms

$ ./bin/tangle -t4
using:  4 tasks    duration 740 ms

$ ./bin/tangle -t2
using:  2 tasks    duration 1.428 ms

$ ./bin/tangle -t1
using:  1 tasks    duration 2.835 ms


gnat-gpl-2016 with additional -gnato flag

$ ./bin/tangle 
using:  8 tasks    duration 456 ms

$ ./bin/tangle -t4
using:  4 tasks    duration 761 ms

$ ./bin/tangle -t2
using:  2 tasks    duration 1.453 ms

$ ./bin/tangle -t1
using:  1 tasks    duration 2.879 ms

Re: Poor performance with GNAT-GPL-2017

[Robert Eachus]

Doing some simple arithmetic:

> gnat-gpl-2017
> 
> $ ./bin/tangle 
> using:  8 tasks    duration 851 ms x 8 = 6.808
> 
> $ ./bin/tangle -t4
> using:  4 tasks    duration 1.213 ms x 4 = 4.852
> 
> $ ./bin/tangle -t2
> using:  2 tasks    duration 2.346 ms x 2 = 4.692
> 
> $ ./bin/tangle -t1
> using:  1 tasks    duration 4.638 ms x 1 = 4.638
> 
> 
> gnat-gpl-2016
> 
> $ ./bin/tangle 
> using:  8 tasks    duration 430 ms x 8 = 3.440
> 
> $ ./bin/tangle -t4
> using:  4 tasks    duration 740 ms x 4 = 2.960
> 
> $ ./bin/tangle -t2
> using:  2 tasks    duration 1.428 ms x 2 = 2.856 
> 
> $ ./bin/tangle -t1
> using:  1 tasks    duration 2.835 ms x 1 = 2.835

The numbers indicate that tasking overhead goes up with more tasks, but it also seems that the 2 to 1 ratio holds true.

Choices are: stick with the 2016 version, accept the slowdown, or buy an ACT subscription.

Re: Poor performance with GNAT-GPL-2017

[Lucretia]

On Tuesday, 13 June 2017 05:14:33 UTC+1, Robert Eachus  wrote:

> Choices are: stick with the 2016 version, accept the slowdown, or buy an ACT subscription.

I still find it amazing that you people think that us normal people have £5k to spare on an ACT subscription.

Re: Poor performance with GNAT-GPL-2017

[Robert Eachus]

On Tuesday, June 13, 2017 at 9:57:47 AM UTC-4, Lucretia wrote:

> I still find it amazing that you people think that us normal people have £5k to spare on an ACT subscription.

I don't think 'normal people' have the money for an ACT subscription.  I do think people who work for companies using Ada or Spark on safety or mission critical systems also read this list, so the choices are what they are.

Re: Poor performance with GNAT-GPL-2017

[Emile]

Le samedi 10 juin 2017 13:23:34 UTC+2, Charly a écrit :
> Hi,
> 
> when I found the new GNAT-GPL-2017 this morning I was happy and installed it at once.
> But I was rather disappointed about the poor performance.
> To be more precise:
> 
> When I switch to new hard- or software I allways check the performance with my private tool:
> It solves Rubics Tabgle https://www.jaapsch.net/puzzles/tangle.htm with an ada programm, using one task per core.
> 
> With GNAT-GPL-2016 (gcc 4.9.4) it took about 0,4 sec to find both solutions,
> with GNAT-GPL-2017 (gcc 6.3.1) it takes about 0,8 sec to find both solutions,
> which means the program is slower by a factor of 2.
> 
> In both cases I use the following options: 
> -O3 -gnatA -gnatn -funroll-loops -fPIC -gnatp -g -gnatW8 -gnatVn -mtune=amdfam10 -gnat12
> 
> Any ideas??
> 
> Sincerly
> Charly

Is it the 64 Bits Linux version of GNAT which presents this performance slow down ?

Re: Poor performance with GNAT-GPL-2017

[Charly]

Am Montag, 12. Juni 2017 14:22:00 UTC+2 schrieb Emile:
> Le samedi 10 juin 2017 13:23:34 UTC+2, Charly a écrit :
> > Hi,
> > 
> > when I found the new GNAT-GPL-2017 this morning I was happy and installed it at once.
> > But I was rather disappointed about the poor performance.
> > To be more precise:
> > 
> > When I switch to new hard- or software I allways check the performance with my private tool:
> > It solves Rubics Tabgle https://www.jaapsch.net/puzzles/tangle.htm with an ada programm, using one task per core.
> > 
> > With GNAT-GPL-2016 (gcc 4.9.4) it took about 0,4 sec to find both solutions,
> > with GNAT-GPL-2017 (gcc 6.3.1) it takes about 0,8 sec to find both solutions,
> > which means the program is slower by a factor of 2.
> > 
> > In both cases I use the following options: 
> > -O3 -gnatA -gnatn -funroll-loops -fPIC -gnatp -g -gnatW8 -gnatVn -mtune=amdfam10 -gnat12
> > 
> > Any ideas??
> > 
> > Sincerly
> > Charly
> 
> Is it the 64 Bits Linux version of GNAT which presents this performance slow down ?

Yes, Xubuntu GNU/Linux with Kernel 4.10 on AMD FX 8350 (8 cores)

Re: Poor performance with GNAT-GPL-2017

[Mark Lorenzen]

On Saturday, June 10, 2017 at 1:23:34 PM UTC+2, Charly wrote:
> Hi,
> 
> when I found the new GNAT-GPL-2017 this morning I was happy and installed it at once.
> But I was rather disappointed about the poor performance.
> To be more precise:
> 
> When I switch to new hard- or software I allways check the performance with my private tool:
> It solves Rubics Tabgle https://www.jaapsch.net/puzzles/tangle.htm with an ada programm, using one task per core.
> 
> With GNAT-GPL-2016 (gcc 4.9.4) it took about 0,4 sec to find both solutions,
> with GNAT-GPL-2017 (gcc 6.3.1) it takes about 0,8 sec to find both solutions,
> which means the program is slower by a factor of 2.
> 
> In both cases I use the following options: 
> -O3 -gnatA -gnatn -funroll-loops -fPIC -gnatp -g -gnatW8 -gnatVn -mtune=amdfam10 -gnat12
> 
> Any ideas??

Previous versions of GNAT did not have overflow check (-gnato) enabled by default, whereas newer versions have. Maybe this is what you are seeing.

Regards,

Mark L

Re: Poor performance with GNAT-GPL-2017

[alkhimey]

On Monday, June 12, 2017 at 6:28:17 PM UTC+3, Mark Lorenzen wrote:
> On Saturday, June 10, 2017 at 1:23:34 PM UTC+2, Charly wrote:
> > Hi,
> > 
> > when I found the new GNAT-GPL-2017 this morning I was happy and installed it at once.
> > But I was rather disappointed about the poor performance.
> > To be more precise:
> > 
> > When I switch to new hard- or software I allways check the performance with my private tool:
> > It solves Rubics Tabgle https://www.jaapsch.net/puzzles/tangle.htm with an ada programm, using one task per core.
> > 
> > With GNAT-GPL-2016 (gcc 4.9.4) it took about 0,4 sec to find both solutions,
> > with GNAT-GPL-2017 (gcc 6.3.1) it takes about 0,8 sec to find both solutions,
> > which means the program is slower by a factor of 2.
> > 
> > In both cases I use the following options: 
> > -O3 -gnatA -gnatn -funroll-loops -fPIC -gnatp -g -gnatW8 -gnatVn -mtune=amdfam10 -gnat12
> > 
> > Any ideas??
> 
> Previous versions of GNAT did not have overflow check (-gnato) enabled by default, whereas newer versions have. Maybe this is what you are seeing.
> 
> Regards,
> 
> Mark L

I see Charly is compiling with '-gnatp'. Does it suppress the overflow checks as well?

Charly, it can be an interesting experiment to trace the source of this anomaly. This is strange that the compiler is emitting a code that is twice as slow. It can compile a specific language feature to be slower, but this one needs to be run frequently enough in your program. Can you guess what this feature can be? Maybe a profiler can help.

Can you try to compile your benchmark without tasking at all (remove the tasking code, rather than create 1 task)?

Can you use a different run time for the 2017 compiler?

Re: Poor performance with GNAT-GPL-2017

[Charly]

Am Dienstag, 13. Juni 2017 21:46:13 UTC+2 schrieb alkh...@gmail.com:
> On Monday, June 12, 2017 at 6:28:17 PM UTC+3, Mark Lorenzen wrote:
> > On Saturday, June 10, 2017 at 1:23:34 PM UTC+2, Charly wrote:
> > > Hi,
> > > 
> > > when I found the new GNAT-GPL-2017 this morning I was happy and installed it at once.
> > > But I was rather disappointed about the poor performance.
> > > To be more precise:
> > > 
> > > When I switch to new hard- or software I allways check the performance with my private tool:
> > > It solves Rubics Tabgle https://www.jaapsch.net/puzzles/tangle.htm with an ada programm, using one task per core.
> > > 
> > > With GNAT-GPL-2016 (gcc 4.9.4) it took about 0,4 sec to find both solutions,
> > > with GNAT-GPL-2017 (gcc 6.3.1) it takes about 0,8 sec to find both solutions,
> > > which means the program is slower by a factor of 2.
> > > 
> > > In both cases I use the following options: 
> > > -O3 -gnatA -gnatn -funroll-loops -fPIC -gnatp -g -gnatW8 -gnatVn -mtune=amdfam10 -gnat12
> > > 
> > > Any ideas??
> > 
> > Previous versions of GNAT did not have overflow check (-gnato) enabled by default, whereas newer versions have. Maybe this is what you are seeing.
> > 
> > Regards,
> > 
> > Mark L
> 
> I see Charly is compiling with '-gnatp'. Does it suppress the overflow checks as well?
> 
> Charly, it can be an interesting experiment to trace the source of this anomaly. This is strange that the compiler is emitting a code that is twice as slow. It can compile a specific language feature to be slower, but this one needs to be run frequently enough in your program. Can you guess what this feature can be? Maybe a profiler can help.
> 
> Can you try to compile your benchmark without tasking at all (remove the tasking code, rather than create 1 task)?
> 
> Can you use a different run time for the 2017 compiler?

-----
As alhk suggested, I made a new variant of my program that doesn't use any tasking when I supply option -t 0
Here are the results:

gnat-gpl-2016

$ ./bin/tangle -t 0 
using:  0 tasks
duration 2847 ms

$ ./bin/tangle -t 1
using:  1 tasks
duration 2874 ms


gnat-gpl-2017

$ ./bin/tangle -t 0 
using:  0 tasks
duration 4889 ms

$ ./bin/tangle -t 1
using:  1 tasks
duration 4936 ms

As you can see, the overhead of using one task instead of avoiding tasking at all is
a.) very small for both gnat-versions
b.) also differs by a factor 2 between gnat-version

4936 - 4889
-----------  = 0,96 %
   4889

2874 - 2847
----------- = 0,95 %
   2847

Re: Poor performance with GNAT-GPL-2017

[Charly]

Am Donnerstag, 15. Juni 2017 17:19:20 UTC+2 schrieb Charly:
> Am Dienstag, 13. Juni 2017 21:46:13 UTC+2 schrieb alkh...@gmail.com:
> > On Monday, June 12, 2017 at 6:28:17 PM UTC+3, Mark Lorenzen wrote:
> > > On Saturday, June 10, 2017 at 1:23:34 PM UTC+2, Charly wrote:
> > > > Hi,
> > > > 
> > > > when I found the new GNAT-GPL-2017 this morning I was happy and installed it at once.
> > > > But I was rather disappointed about the poor performance.
> > > > To be more precise:
> > > > 
> > > > When I switch to new hard- or software I allways check the performance with my private tool:
> > > > It solves Rubics Tabgle https://www.jaapsch.net/puzzles/tangle.htm with an ada programm, using one task per core.
> > > > 
> > > > With GNAT-GPL-2016 (gcc 4.9.4) it took about 0,4 sec to find both solutions,
> > > > with GNAT-GPL-2017 (gcc 6.3.1) it takes about 0,8 sec to find both solutions,
> > > > which means the program is slower by a factor of 2.
> > > > 
> > > > In both cases I use the following options: 
> > > > -O3 -gnatA -gnatn -funroll-loops -fPIC -gnatp -g -gnatW8 -gnatVn -mtune=amdfam10 -gnat12
> > > > 
> > > > Any ideas??
> > > 
> > > Previous versions of GNAT did not have overflow check (-gnato) enabled by default, whereas newer versions have. Maybe this is what you are seeing.
> > > 
> > > Regards,
> > > 
> > > Mark L
> > 
> > I see Charly is compiling with '-gnatp'. Does it suppress the overflow checks as well?
> > 
> > Charly, it can be an interesting experiment to trace the source of this anomaly. This is strange that the compiler is emitting a code that is twice as slow. It can compile a specific language feature to be slower, but this one needs to be run frequently enough in your program. Can you guess what this feature can be? Maybe a profiler can help.
> > 
> > Can you try to compile your benchmark without tasking at all (remove the tasking code, rather than create 1 task)?
> > 
> > Can you use a different run time for the 2017 compiler?
> 
> -----
Some aditional strange results, all without any tasking (new option -t 0)

gnat-gpl-2016 -O
duration 3485 ms

gnat-gpl-2016 -O2
duration 4713 ms

gnat-gpl-2016 -O3
duration 2772 ms

gnat-gpl-2017 -O
duration 3375 ms

gnat-gpl-2017 -O2
duration 4480 ms

gnat-gpl-2017 -O3
duration 4823 ms

To summarize I draw two conclusions
This year optimization level -O is the best choice,
Try several optimization levels next year when gnat-gpl-2018 is out.

Re: Poor performance with GNAT-GPL-2017

[Anh Vo]

On Thursday, June 15, 2017 at 9:31:52 AM UTC-7, Charly wrote:
> Am Donnerstag, 15. Juni 2017 17:19:20 UTC+2 schrieb Charly:
> > Am Dienstag, 13. Juni 2017 21:46:13 UTC+2 schrieb alkh...@gmail.com:
> > > On Monday, June 12, 2017 at 6:28:17 PM UTC+3, Mark Lorenzen wrote:
> > > > On Saturday, June 10, 2017 at 1:23:34 PM UTC+2, Charly wrote:

> > -----
> Some aditional strange results, all without any tasking (new option -t 0)
> 
> gnat-gpl-2016 -O
> duration 3485 ms
> 
> gnat-gpl-2016 -O2
> duration 4713 ms
> 
> gnat-gpl-2016 -O3
> duration 2772 ms
> 
> gnat-gpl-2017 -O
> duration 3375 ms
> 
> gnat-gpl-2017 -O2
> duration 4480 ms
> 
> gnat-gpl-2017 -O3
> duration 4823 ms
> 
> To summarize I draw two conclusions
> This year optimization level -O is the best choice,
> Try several optimization levels next year when gnat-gpl-2018 is out.

What numbers will you get if you run it say 10 times?

Anh Vo

Re: Poor performance with GNAT-GPL-2017

[Charly]

Am Donnerstag, 15. Juni 2017 20:00:07 UTC+2 schrieb Anh Vo:
> On Thursday, June 15, 2017 at 9:31:52 AM UTC-7, Charly wrote:
> > Am Donnerstag, 15. Juni 2017 17:19:20 UTC+2 schrieb Charly:
> > > Am Dienstag, 13. Juni 2017 21:46:13 UTC+2 schrieb alkh...@gmail.com:
> > > > On Monday, June 12, 2017 at 6:28:17 PM UTC+3, Mark Lorenzen wrote:
> > > > > On Saturday, June 10, 2017 at 1:23:34 PM UTC+2, Charly wrote:
> 
> > > -----
> > Some aditional strange results, all without any tasking (new option -t 0)
> > 
> > gnat-gpl-2016 -O
> > duration 3485 ms
> > 
> > gnat-gpl-2016 -O2
> > duration 4713 ms
> > 
> > gnat-gpl-2016 -O3
> > duration 2772 ms
> > 
> > gnat-gpl-2017 -O
> > duration 3375 ms
> > 
> > gnat-gpl-2017 -O2
> > duration 4480 ms
> > 
> > gnat-gpl-2017 -O3
> > duration 4823 ms
> > 
> > To summarize I draw two conclusions
> > This year optimization level -O is the best choice,
> > Try several optimization levels next year when gnat-gpl-2018 is out.
> 
> What numbers will you get if you run it say 10 times?
> 
> Anh Vo
I did 10 runs for gnat-gpl-2017 with -O3 and 10 runs with -O

-O3:
 4846 ms
 4825 ms
 4831 ms
 4838 ms
 4825 ms
 4842 ms
 4814 ms
 4826 ms
 4824 ms
 4838 ms

-O:
 3371 ms
 3374 ms
 3368 ms
 3373 ms
 3370 ms
 3364 ms
 3366 ms
 3375 ms
 3370 ms
 3364 ms

As you can see the results are VERY stable

Re: Poor performance with GNAT-GPL-2017

[Anh Vo]

On Thursday, June 15, 2017 at 12:21:19 PM UTC-7, Charly wrote:
> Am Donnerstag, 15. Juni 2017 20:00:07 UTC+2 schrieb Anh Vo:
> > On Thursday, June 15, 2017 at 9:31:52 AM UTC-7, Charly wrote:
> > > Am Donnerstag, 15. Juni 2017 17:19:20 UTC+2 schrieb Charly:
> > > > Am Dienstag, 13. Juni 2017 21:46:13 UTC+2 schrieb alkh...@gmail.com:
> > > > > On Monday, June 12, 2017 at 6:28:17 PM UTC+3, Mark Lorenzen wrote:
> > > > > > On Saturday, June 10, 2017 at 1:23:34 PM UTC+2, Charly wrote:
> > 
> > > > -----
> > > Some aditional strange results, all without any tasking (new option -t 0)
> > > 
> > > gnat-gpl-2016 -O
> > > duration 3485 ms
> > > 
> > > gnat-gpl-2016 -O2
> > > duration 4713 ms
> > > 
> > > gnat-gpl-2016 -O3
> > > duration 2772 ms
> > > 
> > > gnat-gpl-2017 -O
> > > duration 3375 ms
> > > 
> > > gnat-gpl-2017 -O2
> > > duration 4480 ms
> > > 
> > > gnat-gpl-2017 -O3
> > > duration 4823 ms
> > > 
> > > To summarize I draw two conclusions
> > > This year optimization level -O is the best choice,
> > > Try several optimization levels next year when gnat-gpl-2018 is out.
> > 
> > What numbers will you get if you run it say 10 times?
> > 
> > Anh Vo
> I did 10 runs for gnat-gpl-2017 with -O3 and 10 runs with -O
> 
> -O3:
>  4846 ms
>  4825 ms
>  4831 ms
>  4838 ms
>  4825 ms
>  4842 ms
>  4814 ms
>  4826 ms
>  4824 ms
>  4838 ms
> 
> -O:
>  3371 ms
>  3374 ms
>  3368 ms
>  3373 ms
>  3370 ms
>  3364 ms
>  3366 ms
>  3375 ms
>  3370 ms
>  3364 ms
> 
> As you can see the results are VERY stable

Indeed, the results are pretty stable. Thank you for running and posting the results.

Re: Poor performance with GNAT-GPL-2017

[stephane.carrez]

Le jeudi 15 juin 2017 18:31:52 UTC+2, Charly a écrit :
> 
> gnat-gpl-2016 -O
> duration 3485 ms
> 
> gnat-gpl-2016 -O2
> duration 4713 ms
> 
> gnat-gpl-2016 -O3
> duration 2772 ms
> 
> gnat-gpl-2017 -O
> duration 3375 ms
> 
> gnat-gpl-2017 -O2
> duration 4480 ms
> 
> gnat-gpl-2017 -O3
> duration 4823 ms
> 
> To summarize I draw two conclusions
> This year optimization level -O is the best choice,
> Try several optimization levels next year when gnat-gpl-2018 is out.

The best choice is different for each program.

As far as I'm concerned, I observe a 5% improvement in speed
and 8% reduction in code size. The -O2 or -O3 give better
performance for me.

If you look at gcc bug list at https://gcc.gnu.org/bugzilla/ you will
find some performance regressions for some very particular cases between
gcc 4.9 and gcc 6.3.  Fortunatly it does not affect the majority of
programs.

It might be interesting that you publish your program so that
further investigations can be conducted.

Stephane

Re: Poor performance with GNAT-GPL-2017

[gautier_niouzes]

On a number-crunching program, I also get an average of +5% improvement with GPL 2017 too. It depends a lot on the kind of program, tasking or not, compiler options, part of FPU calculation, the machine itself, etc. So no general conclusion.
The compiler options I use are:

         when "Optimize" =>
            for Default_Switches ("ada") use ("-gnat12", "-gnatwu", "-O2", "-gnatpn", 
              "-funroll-loops", "-fpeel-loops", "-funswitch-loops", 
              "-ftracer", "-fweb", "-frename-registers",
              "-fpredictive-commoning", "-fgcse-after-reload", "-ftree-vectorize", "-fipa-cp-clone",
              "-ffunction-sections", 
              "-mfpmath=sse", "-msse4.2",
              "-g");

Cheers
Gautier
_____________________________________________________________
A free online game in Ada: http://pasta.phyrama.com/game.html

Re: Poor performance with GNAT-GPL-2017

[Anatoly Chernyshev]

 
> To summarize I draw two conclusions
> This year optimization level -O is the best choice,
> Try several optimization levels next year when gnat-gpl-2018 is out.

Phew, no need for the ACT subscription... What a relief!

Re: Poor performance with GNAT-GPL-2017

[briot.emmanuel]

Since you are running linux, you could try running a profiler ("prof record ./main; prof report -g") on both instances of your program. Maybe that will highlight some source of inefficiency and you can report this to AdaCore. I don't remember whether they changed the version of the gcc backend this year, so at this stage the slowdown could be either in the front-end or in the backend...

Re: Poor performance with GNAT-GPL-2017

[Simon Wright]

briot.emmanuel@gmail.com writes:

> I don't remember whether they changed the version of the gcc backend
> this year, so at this stage the slowdown could be either in the
> front-end or in the backend...

2016 was GCC 4.9.4, 2017 is 6.3.1.