------=_Part_10263_32875881.1388728572210
Content-Type: text/plain; charset=ISO-8859-1

Inlining is one of the most powerful performance features of C++. Modern
compilers may attempt to inline anything, even non-inline functions. With
the advent of link time optimization / whole program optimization, inlining
is potentially and unpredictably on the table for any function in the
entire application.

Sometimes we want to write synthetic code, particularly for benchmarks
where we want to isolate a bit of code to test its performance. We don't
want any details of the caller interfering with the code to be tested. In
many cases, the compiler will even optimize out our test entirely if it
does not produce a meaningful result. In this important use case, inlining
can get in the way.

The best way to write such benchmarks is to use __attribute__((noinline))
or its proposed standard equivalent [[noinline]]. This attribute ensures a
function is compiled stand alone, without any influence from callers.Thus
we can be confident in isolating it and testing its performance portably
across all of our supported platforms.

Any objections?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_10263_32875881.1388728572210
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Inlining is one of the most powerful performance features =
of C++. Modern compilers may attempt to inline anything, even non-inline fu=
nctions. With the advent of link time optimization / whole program optimiza=
tion, inlining is potentially and unpredictably on the table for any functi=
on in the entire application.&nbsp;<div><br></div><div>Sometimes we want to=
 write synthetic code, particularly for benchmarks where we want to isolate=
 a bit of code to test its performance. We don't want any details of the ca=
ller interfering with the code to be tested. In many cases, the compiler wi=
ll even optimize out our test entirely if it does not produce a meaningful =
result. In this important use case, inlining can get in the way.</div><div>=
<br></div><div>The best way to write such benchmarks is to use __attribute_=
_((noinline)) or its proposed standard equivalent [[noinline]]. This attrib=
ute ensures a function is compiled stand alone, without any influence from =
callers.Thus we can be confident in isolating it and testing its performanc=
e portably across all of our supported platforms.</div><div><br></div><div>=
Any objections?</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_10263_32875881.1388728572210--

.

On 1/3/14 1:56 PM, fmatthew5876@gmail.com wrote:
> Inlining is one of the most powerful performance features of C++. Modern
> compilers may attempt to inline anything, even non-inline functions. With
> the advent of link time optimization / whole program optimization, inlining
> is potentially and unpredictably on the table for any function in the
> entire application.
>
> Sometimes we want to write synthetic code, particularly for benchmarks
> where we want to isolate a bit of code to test its performance. We don't
> want any details of the caller interfering with the code to be tested. In
> many cases, the compiler will even optimize out our test entirely if it
> does not produce a meaningful result. In this important use case, inlining
> can get in the way.
>
> The best way to write such benchmarks is to use __attribute__((noinline))
> or its proposed standard equivalent [[noinline]]. This attribute ensures a
> function is compiled stand alone, without any influence from callers.Thus
> we can be confident in isolating it and testing its performance portably
> across all of our supported platforms.
>
> Any objections?

Synthetic benchmarks don't sound like a valid use case. Anyway inlining
isn't the enemy; constant propagation is. A whole program optimizer
could determine that all call sites of a function have specific
arguments and optimize away without inlining. What proposal specifies
[[noinline]] and are you sure it absolutely guarantees translation in
isolation?

To counteract constant propagation for a synthetic benchmark, use
volatile. g++ -O3 compiles this program into an inlined, but not
trivialized, computation of 8! from factorial(varg), plus a constant
40320 resulting from factorial(nvarg).

int factorial( int x ) {
int ret = x;
while ( -- x ) ret *= x;
return ret;
}

int main() {
int nvarg = 8;
volatile int varg = 8;
return factorial( nvarg ) + factorial( varg );
}

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_411_13154631.1388766565469
Content-Type: text/plain; charset=ISO-8859-1



On Friday, January 3, 2014 6:34:59 AM UTC-5, David Krauss wrote:
>
>
> Synthetic benchmarks don't sound like a valid use case. Anyway inlining
> isn't the enemy; constant propagation is. A whole program optimizer
> could determine that all call sites of a function have specific
> arguments and optimize away without inlining.


The behavior of [[noinline]] would need to prevent this behavior as well.
Essentially [[noinline] would create an optimization barrier at function
entry/exit.



> What proposal specifies
> [[noinline]] and are you sure it absolutely guarantees translation in
> isolation?
>

The proposal I will write, unless someone can convince me this is a bad
idea. I would specify it to do exactly that, translation in isolation. No
optimizations can leak into or out of the function.


>
> To counteract constant propagation for a synthetic benchmark, use
> volatile. g++ -O3 compiles this program into an inlined, but not
> trivialized, computation of 8! from factorial(varg), plus a constant
> 40320 resulting from factorial(nvarg).
>
> int factorial( int x ) {
> int ret = x;
> while ( -- x ) ret *= x;
> return ret;
> }
>
> int main() {
> int nvarg = 8;
> volatile int varg = 8;
> return factorial( nvarg ) + factorial( varg );
> }
>
>
volatile works for constant propagation, but inlining can still skew the
benchmark results if code from the call site is mixed into code from the
function intended to be tested and then optimized.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_411_13154631.1388766565469
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, January 3, 2014 6:34:59 AM UTC-5, David=
 Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Synthetic benchmarks don't sound like a valid use case. Anyway inlining=
=20
<br>isn't the enemy; constant propagation is. A whole program optimizer=20
<br>could determine that all call sites of a function have specific=20
<br>arguments and optimize away without inlining.</blockquote><div><br></di=
v><div>The behavior of [[noinline]] would need to prevent this behavior as =
well. Essentially [[noinline] would create an optimization barrier at funct=
ion entry/exit.</div><div><br></div><div>&nbsp;</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">What proposal specifies=20
<br>[[noinline]] and are you sure it absolutely guarantees translation in=
=20
<br>isolation?
<br></blockquote><div><br></div><div>The proposal I will write, unless some=
one can convince me this is a bad idea. I would specify it to do exactly th=
at, translation in isolation. No optimizations can leak into or out of the =
function.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">
<br>To counteract constant propagation for a synthetic benchmark, use=20
<br>volatile. g++ -O3 compiles this program into an inlined, but not=20
<br>trivialized, computation of 8! from factorial(varg), plus a constant=20
<br>40320 resulting from factorial(nvarg).
<br>
<br>int factorial( int x ) {
<br>int ret =3D x;
<br>while ( -- x ) ret *=3D x;
<br>return ret;
<br>}
<br>
<br>int main() {
<br>int nvarg =3D 8;
<br>volatile int varg =3D 8;
<br>return factorial( nvarg ) + factorial( varg );
<br>}
<br>
<br></blockquote><div><br></div><div>volatile works for constant propagatio=
n, but inlining can still skew the benchmark results if code from the call =
site is mixed into code from the function intended to be tested and then op=
timized.</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_411_13154631.1388766565469--

.

--089e011774f740198304ef145d5c
Content-Type: text/plain; charset=ISO-8859-1

Generally speaking, microbenchmarks like this aren't all that helpful for
determining useful performance data -- doing that requires a real world
application you want to make faster and a profiler.

In particular, the vendor-specific noinline attributes don't even do what
you want here.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal


On Fri, Jan 3, 2014 at 8:29 AM, <fmatthew5876@gmail.com> wrote:

>
>
> On Friday, January 3, 2014 6:34:59 AM UTC-5, David Krauss wrote:
>>
>>
>> Synthetic benchmarks don't sound like a valid use case. Anyway inlining
>> isn't the enemy; constant propagation is. A whole program optimizer
>> could determine that all call sites of a function have specific
>> arguments and optimize away without inlining.
>
>
> The behavior of [[noinline]] would need to prevent this behavior as well.
> Essentially [[noinline] would create an optimization barrier at function
> entry/exit.
>
>
>
>> What proposal specifies
>> [[noinline]] and are you sure it absolutely guarantees translation in
>> isolation?
>>
>
> The proposal I will write, unless someone can convince me this is a bad
> idea. I would specify it to do exactly that, translation in isolation. No
> optimizations can leak into or out of the function.
>
>
>>
>> To counteract constant propagation for a synthetic benchmark, use
>> volatile. g++ -O3 compiles this program into an inlined, but not
>> trivialized, computation of 8! from factorial(varg), plus a constant
>> 40320 resulting from factorial(nvarg).
>>
>> int factorial( int x ) {
>> int ret = x;
>> while ( -- x ) ret *= x;
>> return ret;
>> }
>>
>> int main() {
>> int nvarg = 8;
>> volatile int varg = 8;
>> return factorial( nvarg ) + factorial( varg );
>> }
>>
>>
> volatile works for constant propagation, but inlining can still skew the
> benchmark results if code from the call site is mixed into code from the
> function intended to be tested and then optimized.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e011774f740198304ef145d5c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Generally speaking, microbenchmarks like this aren&#39;t a=
ll that helpful for determining useful performance data -- doing that requi=
res a real world application you want to make faster and a profiler.<div><b=
r>

</div><div>In particular, the vendor-specific noinline attributes don&#39;t=
 even do what you want here.</div></div><div class=3D"gmail_extra"><br clea=
r=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"=
https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github.com/Bil=
lyONeal/</a></div>

<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div></div></=
div>
<br><br><div class=3D"gmail_quote">On Fri, Jan 3, 2014 at 8:29 AM,  <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">=
fmatthew5876@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">

<div dir=3D"ltr"><div class=3D"im"><br><br>On Friday, January 3, 2014 6:34:=
59 AM UTC-5, David Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>Synthetic benchmarks don&#39;t sound like a valid use case. Anyway inli=
ning=20
<br>isn&#39;t the enemy; constant propagation is. A whole program optimizer=
=20
<br>could determine that all call sites of a function have specific=20
<br>arguments and optimize away without inlining.</blockquote><div><br></di=
v></div><div>The behavior of [[noinline]] would need to prevent this behavi=
or as well. Essentially [[noinline] would create an optimization barrier at=
 function entry/exit.</div>

<div class=3D"im"><div><br></div><div>=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">What proposal specifies=20
<br>[[noinline]] and are you sure it absolutely guarantees translation in=
=20
<br>isolation?
<br></blockquote><div><br></div></div><div>The proposal I will write, unles=
s someone can convince me this is a bad idea. I would specify it to do exac=
tly that, translation in isolation. No optimizations can leak into or out o=
f the function.</div>

<div class=3D"im"><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>To counteract constant propagation for a synthetic benchmark, use=20
<br>volatile. g++ -O3 compiles this program into an inlined, but not=20
<br>trivialized, computation of 8! from factorial(varg), plus a constant=20
<br>40320 resulting from factorial(nvarg).
<br>
<br>int factorial( int x ) {
<br>int ret =3D x;
<br>while ( -- x ) ret *=3D x;
<br>return ret;
<br>}
<br>
<br>int main() {
<br>int nvarg =3D 8;
<br>volatile int varg =3D 8;
<br>return factorial( nvarg ) + factorial( varg );
<br>}
<br>
<br></blockquote><div><br></div></div><div>volatile works for constant prop=
agation, but inlining can still skew the benchmark results if code from the=
 call site is mixed into code from the function intended to be tested and t=
hen optimized.</div>

</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e011774f740198304ef145d5c--

.

On sexta-feira, 3 de janeiro de 2014 08:29:25, fmatthew5876@gmail.com wrote:
> On Friday, January 3, 2014 6:34:59 AM UTC-5, David Krauss wrote:
> > Synthetic benchmarks don't sound like a valid use case. Anyway inlining
> > isn't the enemy; constant propagation is. A whole program optimizer
> > could determine that all call sites of a function have specific
> > arguments and optimize away without inlining.
>
> The behavior of [[noinline]] would need to prevent this behavior as well.
> Essentially [[noinline] would create an optimization barrier at function
> entry/exit.

The attribute can be, at most, a non-binding suggestion to the compiler. The
compiler is freely allowed to ignore it, just like the inline keyword.

The one thing that the standardisation will get you is that you'll be allowed
to write the attribute and no compiler can complain about it.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 1/4/14 3:25 AM, Thiago Macieira wrote:
> The attribute can be, at most, a non-binding suggestion to the
> compiler. The compiler is freely allowed to ignore it, just like the
> inline keyword. The one thing that the standardisation will get you is
> that you'll be allowed to write the attribute and no compiler can
> complain about it.

Well, there's also disallowing an implementation from using the
"noinline" attribute-token to mean something different.

I doubt the total isolation rule would be popular, though, or
particularly meaningful. It would seem to disallow PGO, for one thing.

[[noinline]] looks like a directive to disable the function inliner,
which is useful in practical code is to reduce bloat. (I.e., an
application with megabytes of laundry list code should be compiled to
"threaded bytecode.") If indeed the proposal specifies it to disallow
all interprocedural optimizations and not just some, it would reduce the
practical value. (I rather doubt such can be stated in standard semantic
terms.)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 1/4/14 3:25 AM, Thiago Macieira wrote:
> The attribute can be, at most, a non-binding suggestion to the
> compiler. The compiler is freely allowed to ignore it, just like the
> inline keyword. The one thing that the standardisation will get you is
> that you'll be allowed to write the attribute and no compiler can
> complain about it.

Well, there's also disallowing an implementation from using the
"noinline" attribute-token to mean something different.

I doubt the total isolation rule would be popular, though, or
particularly meaningful. It would seem to disallow PGO, for one thing.

[[noinline]] looks like a directive to disable the function inliner,
which is useful in practical code is to reduce bloat. (I.e., an
application with megabytes of laundry list code should be compiled to
"threaded bytecode.") If indeed the proposal specifies it to disallow
all interprocedural optimizations and not just some, it would reduce the
practical value. (I rather doubt such can be stated in standard semantic
terms.)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.