Re: [001/nnn] poly_int: add poly-int.h

[Jeff Law <law at redhat dot com>]

On 11/13/2017 04:36 PM, Richard Sandiford wrote:
> Jeff Law <law@redhat.com> writes:
>> On 11/09/2017 04:06 AM, Richard Sandiford wrote:
>>
>>>> Let me say at the outset that I struggle to comprehend that a few
>>>> instructions is even a consideration when not optimizing, especially
>>>> in light of the bug the macro caused that would have been prevented
>>>> by using a function instead.  But...
>>>
>>> Many people still build at -O0 though.  One of the things I was asked
>>> for was the time it takes to build stage 2 with an -O0 stage 1
>>> (where stage 1 would usually be built by the host compiler).
>> I suspect folks are concerned about this because it potentially affects
>> their daily development cycle times.  So they're looking to see if the
>> introduction of the poly types has a significant impact.  It's a
>> legitimate question, particularly for the introduction of low level
>> infrastructure that potentially gets hit a lot.
>>
>> Richard, what were the results of that test (if it's elsewhere in the
>> thread I'll eventually find it...
> 
> On an x86_64 box I got:
> 
> real: +7%
> user: +8.6%
> 
> for building stage2 with an -O0 -g stage1.  For aarch64 with the
> NUM_POLY_INT_COEFFS==2 change it was:
> 
> real: +17%
> user: +20%
> 
> That's obviously not ideal, but C++11 would get rid of some of the
> inefficiencies, once we can switch to that.
Ouch.  But I guess to some extent it has to be expected given what
you've got to do under the hood.


> 
> You've probably already seen this, but it's compile-time neutral on
> x86_64 in terms of running a gcc built with --enable-checking=release,
> within a margin of about [-0.1%, 0.1%].
Good.  Presumably that's because it all just falls out and turns into
wi:: stuff on targets that don't need the poly stuff.


> 
> For aarch64 with NUM_POLY_INT_COEFFS==2, a gcc built with
> --enable-checking=release is ~1% slower when using -g and ~2%
> slower with -O2 -g.
That's not terrible given what's going on here.


I'm still pondering the whole construction/initialization and temporary
objects issue.    I may try to work through some of the actual patches,
then come back to those issues.


> 
>> I'm just starting to try and make some headway on this kit).
> 
> Thanks :-)  I guess it's going to be a real slog going through them,
> sorry, even despite the attempt to split them up.
No worries.  It's what we sign up for :-)  Your deep testing and long
history with the project really help in that if something goes wrong I
know you're going to be around to fix it.

Jeff