Re: GNAT (GCC) Profile Guided Compilation

[Keean Schupke <keean.schupke@googlemail.com>]

On Wednesday, 4 July 2012 13:38:45 UTC+1, Georg Bauhaus  wrote:
> On 04.07.12 12:57, Keean Schupke wrote:
> > On Wednesday, 4 July 2012 11:38:57 UTC+1, Georg Bauhaus  wrote:
> >> On 03.07.12 01:48, Keean Schupke wrote:
> >>> I have done some testing with the linux "perf" tool. These are some figures for the Ada version:
> >>>
> >>>           1,014,900 l1-dcache-load-misses     #    0.01% of all L1-dcache hits
> >>>      12,462,973,199 l1-dcache-loads
> >>>           7,311,495 cache-references
> >>>              38,804 cache-misses              #    0.531 % of all cache refs
> >>>       2,588,686,069 branch-instructions
> >>>         388,460,030 branch-misses             #   15.01% of all branches
> >>>        21.885512117 seconds time elapsed
> >>>
> >>> And here are the results for the C++ version:
> >>>
> >>>             840,245 l1-dcache-load-misses     #    0.01% of all L1-dcache hits
> >>>      11,140,761,995 l1-dcache-loads
> >>>           6,019,321 cache-references
> >>>              27,584 cache-misses              #    0.458 % of all cache refs
> >>>       3,049,597,029 branch-instructions
> >>>         560,173,316 branch-misses             #   18.37% of all branches
> >>>        17.823476294 seconds time elapsed
> >>>
> >>>
> >>> So the interesting thing is that the Ada version has less overall branches and less branch misses than the C++ version, so it seems the profile-guided compilation has achieved as much. There is another factor limiting performance. The interesting figure would appear to be the cache-misses.
> >>>
> >>> So it would appear I need to focus on the cache utilisation of the Ada code.
> >>
> >> FWIW, looking at the 1D vs 2D subprograms in order to learn
> >> about a (dis)advantage of writing 2D arrays,I found some
> >> things potentially interesting.
> >>
> >> When there is no additional test in the loops,
> >> Apple's Instruments shows two orders of magnitude fewer
> >> branch instructions executed by the 2D subprogram
> >> compared to the 1D subprogram, 5M : 2G. This seems huge to me,
> >> but is reproducible. A naive look at the assembly listing offers
> >> some confirmation, mentioned below, though not on the same order.
> >>
> >> With the "mod" based test added to the respective loops the number
> >> of branch instructions executed by the 2D subprogram increases
> >> to about one half of that of the 1D subprogram's. Still better.
> >>
> >> The assembly listing of the subprograms without tests added has
> >>
> >> - [compute_1d] 3 pairs of forward je and 1 backward jne near
> >>    the end
> >>
> >> - [compute_2] 1 pair of backward jne near the end,
> >>
> >> It appears that unrolling yields two somewhat differently
> >> structured lists of instructions, but I'm drifting away
> >> from Ada.
> >>
> >> Compiling with profile data rearranges the jumps for 1D, adds jumps to 2D,
> >> and shortens both procedures. However, this slows both down using the latest
> >> GNAT GPL on Core i7; there is some speed-up of the 1D procedure with
> >> Debian's GNAT 4.4.5 on Xeon E5645, though. (-O2 -funroll-loops -gnatp)
> >>
> >> All of this breaks once I turn on -O3.
> >> Not sure whether this is a lottery or a mine field. ;-)
> >>
> >> Cheers,
> >> Georg
> > 
> > 
> > How can I turn off inlining for a function in GNAT?
> 
> Sometimes by reordering code, making sure the body hasn't
> been seen when the compiler sees the call statement.
> Or try separate compilation.  The following arrangement
> appears to prevent inline expansion of Inc, even when
> just the main unit is fed to gnatmake -O3 -gnatNp, so that
> GNAT translates everything else automatically, using the
> same switches.
> 
> -fno-inline is another switch to consider. However, it
> appears to be interfering with other optimizations (loop
> unrolling, vectorizer, from what I can guess).
> 
> package Prevent_Inline is
>    type List is array (Positive range <>) of Integer;
>    procedure Inc (X : in out Integer);
>    procedure Inc_All (A : in out List);
> end Prevent_Inline;
> 
> with Prevent_Inline.Aux;
> package body Prevent_Inline is
> 
>    procedure Inc (X : in out Integer) is
>    begin
>       X := X + 1;
>    end Inc;
> 
>    procedure Inc_All (A : in out List)
>      renames Prevent_Inline.Aux;
> 
> end Prevent_Inline;
> 
> procedure Prevent_Inline.Aux (A : in out List) is
> begin
>    for X of A loop
>       Inc (X);
>    end loop;
> end Prevent_Inline.Aux;
> 
> with Prevent_Inline;    use Prevent_Inline;
> procedure Test_Prevent_Inline is
>    X : List (1 .. 10);
> begin
>    Inc_All (X);
> end Test_Prevent_Inline;

Okay, I think I have tracked down the performance problem, but I am not sure how to fix it. It would appear that C++ code that returns a boolean from a function, generates a decision tree using tests and branches, whereas Ada is setting the result into a Boolean variable. This has the result that C++ is bailing out of the evaluation as soon as it can (IE if one side of an and is false, or one side of an or is true), but Ada is always evaluating all parts of the expressions.

Is this a difference in language semantics, and what is the best way to deal with it? Do I need to rewrite all 'and' and 'or' statements in conditionals as nested if statements to get the evaluate only as far as necessary semantics like C/C++?


Cheers,
Keean.