Re: Profiling Ada binaries

["Markus Schöpflin" <no.spam@spam.spam>]

Am 02.08.2016 um 01:36 schrieb Jeffrey R. Carter:
> On 08/01/2016 03:40 PM, rieachus@comcast.net wrote:
>> On Tuesday, July 26, 2016 at 4:37:31 AM UTC-4, Markus Schöpflin wrote:
>>
>>> Even using the non-generic versions I have not been able to get the
>>> hardware built-ins. The best I can achieve for a call to e.g. cos(X)
>>> is:
>>
>>>   call    ada__numerics__long_elementary_functions__cos
>>
>> Again GNAT docs to the rescue: 15.1 Machine code insertions:
>
> I think the OP would benefit from knowing why this is necessary.
>
> If you look at the body of Ada.Numerics.Long_Elementary_Functions.Cos,
> you'll probably find a call to {something that calls} the built-in
> function.
>
> If you look at the requirements for the Cos function in Annex A and Annex G
> (if implemented, which it is for GNAT), you'll find a number of
> requirements for accuracy and special cases. If you look at the definition
> of the built-in function, you'll likely find that it doesn't meet all of
> those requirements. Any call to Cos has to involve wrapping a call to the
> built-in function in code to ensure those requirements are met, so you
> won't find a call to the built-in function in the generated code.

I am aware of that. I was trying to state that you don't get the hardware
built-ins in GNAT, despite the claim of the grandparent poster.

We rely on the guarantees given by the Ada LRM in this case. To make matter
worse (performance wise), we use

   type F is new Float range Float'Range;

as the base float type to make sure that we don't silently run into +/-INF or
other IEEE corner cases. This forces us to use the generic versions in
Ada.Numerics.Generic_Elementary_Functions.

We could of course try

   subtype F is Float range Float'Range;

and use the non-generic versions found in Numerics.Elementary_Functions, which
might be faster than their generic counterpart.

But although we are doing a lot of trigonometric calculations in our code, the
performance hot spots are usually not caused by floating point arithmetic, so
fortunately I don't have to worry about this too much.

> Even if the built-in function met all the requirements, the desire for the
> compiler to be portable will result in the call to the built-in being
> squirrelled away, not produced by the code generator.
>
> The general rule, "If you need specific machine code, use a machine-code
> insertion," applies here. Of course, the result is non-portable code, while
> the call to the language-defined library function is portable.

Actually I don't agree with you here. I don't see a reason why GNAT shouldn't 
be able to generate code which uses the built-in HW primitives, at least when 
using an appropriate optimization level and inlining. The resulting binary 
isn't portable anyway.

Markus