------=_Part_3352_983302737.1474798298774
Content-Type: multipart/alternative;
 boundary="----=_Part_3353_1462957068.1474798298774"

------=_Part_3353_1462957068.1474798298774
Content-Type: text/plain; charset=UTF-8

Hello,

I am spinning around the idea of the possibility of submitting a language
change proposal to expose to the programmer with keywords to hint the
compiler in its optimization.

AFAIK the feature is not currently covered at language level and it is IMHO
sufficiently generic.

As an example it would be applicable to the singleton pattern, something
like:

T* singleton::get_instance() {
   if (p==0) unlikely {
      p = new singleton();
   }
   return p;
}

notice the new keyword "unlikely" which can be used by e.g. g++ to use its __builtin_expect
branch optimizer.

I would like to check if this sounds like a feasible proposal.

Thanks
Marcos Mayorga



--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/46a63948-ce90-423d-ad73-e482eea5ab20%40isocpp.org.

------=_Part_3353_1462957068.1474798298774
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>I am spinning around the idea of=
 the possibility of submitting a language change proposal to expose to the =
programmer with keywords to hint the compiler in its optimization.</div><di=
v><br></div><div>AFAIK the feature is not currently covered at language lev=
el and it is IMHO sufficiently generic.</div><div><br></div><div>As an exam=
ple it would be applicable to the singleton pattern, something like:<br><br=
>T* singleton::get_instance() {</div><div>=C2=A0 =C2=A0if (p=3D=3D0) unlike=
ly {</div><div>=C2=A0 =C2=A0 =C2=A0 p =3D new singleton();</div><div>=C2=A0=
 =C2=A0}</div><div>=C2=A0 =C2=A0return p;</div><div>}<br><br>notice the new=
 keyword &quot;unlikely&quot; which can be used by e.g. g++ to use its=C2=
=A0<span style=3D"color: rgb(84, 84, 84); font-family: arial, sans-serif; f=
ont-size: small; line-height: 18.2px;">__builtin_expect branch optimizer.</=
span></div><div><font color=3D"#545454" face=3D"arial, sans-serif" size=3D"=
2"><span style=3D"line-height: 18.2px;"><br></span></font>I would like to c=
heck if this sounds like a feasible proposal.</div><div><br></div><div>Than=
ks</div><div>Marcos Mayorga</div><div><br><br><br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/46a63948-ce90-423d-ad73-e482eea5ab20%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/46a63948-ce90-423d-ad73-e482eea5ab20=
%40isocpp.org</a>.<br />

------=_Part_3353_1462957068.1474798298774--

------=_Part_3352_983302737.1474798298774--

.

--001a113d4a98a53740053d537b73
Content-Type: text/plain; charset=UTF-8

I think most modern compilers take care of those optimizations already. Is
there a case you've found where this would be helpful?

/R

Den 25 sep 2016 12:11 skrev <mayorga.geek@gmail.com>:

> Hello,
>
> I am spinning around the idea of the possibility of submitting a language
> change proposal to expose to the programmer with keywords to hint the
> compiler in its optimization.
>
> AFAIK the feature is not currently covered at language level and it is
> IMHO sufficiently generic.
>
> As an example it would be applicable to the singleton pattern, something
> like:
>
> T* singleton::get_instance() {
>    if (p==0) unlikely {
>       p = new singleton();
>    }
>    return p;
> }
>
> notice the new keyword "unlikely" which can be used by e.g. g++ to use its __builtin_expect
> branch optimizer.
>
> I would like to check if this sounds like a feasible proposal.
>
> Thanks
> Marcos Mayorga
>
>
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/46a63948-ce90-423d-
> ad73-e482eea5ab20%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/46a63948-ce90-423d-ad73-e482eea5ab20%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEvHzA0-qGuR8dGALL66vQRS3PVrpKU%3DqjjsBF%2BVBYjGAWG1MA%40mail.gmail.com.

--001a113d4a98a53740053d537b73
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I think most modern compilers take care of those optimizatio=
ns already. Is there a case you&#39;ve found where this would be helpful? <=
/p>
<p dir=3D"ltr">/R</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">Den 25 sep 2016 1=
2:11 skrev  &lt;<a href=3D"mailto:mayorga.geek@gmail.com">mayorga.geek@gmai=
l.com</a>&gt;:<br type=3D"attribution"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">Hello,<div><br></div><div>I am spinning around the idea of the =
possibility of submitting a language change proposal to expose to the progr=
ammer with keywords to hint the compiler in its optimization.</div><div><br=
></div><div>AFAIK the feature is not currently covered at language level an=
d it is IMHO sufficiently generic.</div><div><br></div><div>As an example i=
t would be applicable to the singleton pattern, something like:<br><br>T* s=
ingleton::get_instance() {</div><div>=C2=A0 =C2=A0if (p=3D=3D0) unlikely {<=
/div><div>=C2=A0 =C2=A0 =C2=A0 p =3D new singleton();</div><div>=C2=A0 =C2=
=A0}</div><div>=C2=A0 =C2=A0return p;</div><div>}<br><br>notice the new key=
word &quot;unlikely&quot; which can be used by e.g. g++ to use its=C2=A0<sp=
an style=3D"color:rgb(84,84,84);font-family:arial,sans-serif;font-size:smal=
l;line-height:18.2px">__builtin_expect branch optimizer.</span></div><div><=
font color=3D"#545454" face=3D"arial, sans-serif" size=3D"2"><span style=3D=
"line-height:18.2px"><br></span></font>I would like to check if this sounds=
 like a feasible proposal.</div><div><br></div><div>Thanks</div><div>Marcos=
 Mayorga</div><div><br><br><br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/46a63948-ce90-423d-ad73-e482eea5ab20%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/46a6=
3948-ce90-423d-<wbr>ad73-e482eea5ab20%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEvHzA0-qGuR8dGALL66vQRS3PVrpKU%3Dqj=
jsBF%2BVBYjGAWG1MA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEvHzA0-qGuR=
8dGALL66vQRS3PVrpKU%3DqjjsBF%2BVBYjGAWG1MA%40mail.gmail.com</a>.<br />

--001a113d4a98a53740053d537b73--

.

--089e0122829c2dbda0053d53c4ad
Content-Type: text/plain; charset=UTF-8

This has come up several times within SG14:


   - https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/ohFcWdlvrh0
   - https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/TnPaGDHaPwQ
   (includes a proposal)


And somewhat related:

   - https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/v9wlDLp3L-E
   - https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/ybkhN9MFBa8
   - https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/6Nq1MK8kdTg


Hope this helps,
Carl


On 25 September 2016 at 13:40, Robert Bielik <robert.bielik@gmail.com>
wrote:

> I think most modern compilers take care of those optimizations already. Is
> there a case you've found where this would be helpful?
>
> /R
>
> Den 25 sep 2016 12:11 skrev <mayorga.geek@gmail.com>:
>
>> Hello,
>>
>> I am spinning around the idea of the possibility of submitting a language
>> change proposal to expose to the programmer with keywords to hint the
>> compiler in its optimization.
>>
>> AFAIK the feature is not currently covered at language level and it is
>> IMHO sufficiently generic.
>>
>> As an example it would be applicable to the singleton pattern, something
>> like:
>>
>> T* singleton::get_instance() {
>>    if (p==0) unlikely {
>>       p = new singleton();
>>    }
>>    return p;
>> }
>>
>> notice the new keyword "unlikely" which can be used by e.g. g++ to use
>> its __builtin_expect branch optimizer.
>>
>> I would like to check if this sounds like a feasible proposal.
>>
>> Thanks
>> Marcos Mayorga
>>
>>
>>
>> --
>> 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.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/46a63948-ce90-423d-ad73-
>> e482eea5ab20%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/46a63948-ce90-423d-ad73-e482eea5ab20%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAEvHzA0-qGuR8dGALL66vQRS3PVrpKU%
> 3DqjjsBF%2BVBYjGAWG1MA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEvHzA0-qGuR8dGALL66vQRS3PVrpKU%3DqjjsBF%2BVBYjGAWG1MA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGa0LWtA-_7%3DwtF1HbJGphABit7Yk5swL2jm5BCX4DF%3D9EGNcA%40mail.gmail.com.

--089e0122829c2dbda0053d53c4ad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This has come up several times within SG14:<div><br></div>=
<div><ul><li><a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topi=
c/sg14/ohFcWdlvrh0">https://groups.google.com/a/isocpp.org/forum/#!topic/sg=
14/ohFcWdlvrh0</a><br></li><li><a href=3D"https://groups.google.com/a/isocp=
p.org/forum/#!topic/sg14/TnPaGDHaPwQ">https://groups.google.com/a/isocpp.or=
g/forum/#!topic/sg14/TnPaGDHaPwQ</a> (includes a proposal)<br></li></ul></d=
iv><div><br></div><div>And somewhat related:</div><div><ul><li><a href=3D"h=
ttps://groups.google.com/a/isocpp.org/forum/#!topic/sg14/v9wlDLp3L-E">https=
://groups.google.com/a/isocpp.org/forum/#!topic/sg14/v9wlDLp3L-E</a><br></l=
i><li><a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/=
ybkhN9MFBa8">https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/ybkh=
N9MFBa8</a><br></li><li><a href=3D"https://groups.google.com/a/isocpp.org/f=
orum/#!topic/sg14/6Nq1MK8kdTg">https://groups.google.com/a/isocpp.org/forum=
/#!topic/sg14/6Nq1MK8kdTg</a><br></li></ul></div><div><br></div><div>Hope t=
his helps,</div><div>Carl</div><div><br></div></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">On 25 September 2016 at 13:40, Robert Bi=
elik <span dir=3D"ltr">&lt;<a href=3D"mailto:robert.bielik@gmail.com" targe=
t=3D"_blank">robert.bielik@gmail.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><p dir=3D"ltr">I think most modern compilers take care of=
 those optimizations already. Is there a case you&#39;ve found where this w=
ould be helpful? </p>
<p dir=3D"ltr">/R</p><div><div class=3D"h5">
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">Den 25 sep 2016 1=
2:11 skrev  &lt;<a href=3D"mailto:mayorga.geek@gmail.com" target=3D"_blank"=
>mayorga.geek@gmail.com</a>&gt;:<br type=3D"attribution"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Hello,<div><br></div><div>I am spinning arou=
nd the idea of the possibility of submitting a language change proposal to =
expose to the programmer with keywords to hint the compiler in its optimiza=
tion.</div><div><br></div><div>AFAIK the feature is not currently covered a=
t language level and it is IMHO sufficiently generic.</div><div><br></div><=
div>As an example it would be applicable to the singleton pattern, somethin=
g like:<br><br>T* singleton::get_instance() {</div><div>=C2=A0 =C2=A0if (p=
=3D=3D0) unlikely {</div><div>=C2=A0 =C2=A0 =C2=A0 p =3D new singleton();</=
div><div>=C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0return p;</div><div>}<br><br=
>notice the new keyword &quot;unlikely&quot; which can be used by e.g. g++ =
to use its=C2=A0<span style=3D"color:rgb(84,84,84);font-family:arial,sans-s=
erif;font-size:small;line-height:18.2px">__builtin_expect branch optimizer.=
</span></div><div><font color=3D"#545454" face=3D"arial, sans-serif" size=
=3D"2"><span style=3D"line-height:18.2px"><br></span></font>I would like to=
 check if this sounds like a feasible proposal.</div><div><br></div><div>Th=
anks</div><div>Marcos Mayorga</div><div><br><br><br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/46a63948-ce90-423d-ad73-e482eea5ab20%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/46a6=
3948-ce90-423d-ad73-<wbr>e482eea5ab20%40isocpp.org</a>.<br>
</blockquote></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEvHzA0-qGuR8dGALL66vQRS3PVrpKU%3Dqj=
jsBF%2BVBYjGAWG1MA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CAEvHzA0-<wbr>qGuR8dGALL66vQRS3PVrpKU%<wbr>3DqjjsBF%2BVB=
YjGAWG1MA%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGa0LWtA-_7%3DwtF1HbJGphABit7Yk5swL2=
jm5BCX4DF%3D9EGNcA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGa0LWtA-_7%=
3DwtF1HbJGphABit7Yk5swL2jm5BCX4DF%3D9EGNcA%40mail.gmail.com</a>.<br />

--089e0122829c2dbda0053d53c4ad--

.

On 09/25/16 13:11, mayorga.geek@gmail.com wrote:
> Hello,
>
> I am spinning around the idea of the possibility of submitting a
> language change proposal to expose to the programmer with keywords to
> hint the compiler in its optimization.
>
> AFAIK the feature is not currently covered at language level and it is
> IMHO sufficiently generic.
>
> As an example it would be applicable to the singleton pattern, something
> like:
>
> T* singleton::get_instance() {
>    if (p==0) unlikely {
>       p = new singleton();
>    }
>    return p;
> }
>
> notice the new keyword "unlikely" which can be used by e.g. g++ to use
> its __builtin_expect branch optimizer.
>
> I would like to check if this sounds like a feasible proposal.

I like the idea but I would suggest a different syntax:

   T* singleton::get_instance() {
      if (p==0) {
         [[unlikely]]
         p = new singleton();
      }
      return p;
   }

The attribute would apply to the branch associated with the statement
following the attribute. This allows (a) to ignore the attribute if the
compiler doesn't support it and (b) use the attribute in other contexts.
For example:

   switch (x) {
   case 1:
     // branch with no probability hints
     foo();
     break;

   case 2:
     // the most probable branch
     [[likely]]
     bar();
     break;

   default:
     // the least probable branch
     [[unlikely]]
     throw std::invalid_argument("unsupported x");
   }

or:

   for (int i = 0; i < n; ++i)
   {
     // Most often n <= 0, the loop is rarely executed
     [[unlikely]]
     baz();
   }

or:

   // The function is unlikely to be called ("cold" function)
   [[unlikely]] void handle_error();

   // The function is expected to be called often ("hot" function)
   [[likely]] void process_data();


--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2994274-139f-96b0-3ebd-36d19311709b%40gmail.com.

.

--001a113ff81228f70c053d5468ce
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 25/9/2016 9:36, "Andrey Semashev" <andrey.semashev@gmail.com> escribi=C3=
=B3:
>
> On 09/25/16 13:11, mayorga.geek@gmail.com wrote:
>>
>> Hello,
>>
>> I am spinning around the idea of the possibility of submitting a
>> language change proposal to expose to the programmer with keywords to
>> hint the compiler in its optimization.
>>
>> AFAIK the feature is not currently covered at language level and it is
>> IMHO sufficiently generic.
>>
>> As an example it would be applicable to the singleton pattern, something
>> like:
>>
>> T* singleton::get_instance() {
>>    if (p=3D=3D0) unlikely {
>>       p =3D new singleton();
>>    }
>>    return p;
>> }
>>
>> notice the new keyword "unlikely" which can be used by e.g. g++ to use
>> its __builtin_expect branch optimizer.
>>
>> I would like to check if this sounds like a feasible proposal.
>
>
> I like the idea but I would suggest a different syntax:
>
>
>   T* singleton::get_instance() {
>      if (p=3D=3D0) {
>         [[unlikely]]
>         p =3D new singleton();
>      }
>      return p;
>   }
>
> The attribute would apply to the branch associated with the statement
following the attribute. This allows (a) to ignore the attribute if the
compiler doesn't support it and (b) use the attribute in other contexts.
For example:

Everything involving a branch: if, while, for, switch, ?. Please when
proposing these sort of things, keep in mind that the world is not only
x86. There are other archs that don't have branch predictors. That's why an
(ignorable) attribute is what should be, if at ever standarized.

>
>   switch (x) {
>   case 1:
>     // branch with no probability hints
>     foo();
>     break;
>
>   case 2:
>     // the most probable branch
>     [[likely]]
>     bar();
>     break;
>
>   default:
>     // the least probable branch
>     [[unlikely]]
>     throw std::invalid_argument("unsupported x");
>   }
>
> or:
>
>   for (int i =3D 0; i < n; ++i)
>   {
>     // Most often n <=3D 0, the loop is rarely executed
>     [[unlikely]]
>     baz();
>   }
>
> or:
>
>   // The function is unlikely to be called ("cold" function)
>   [[unlikely]] void handle_error();
>
>   // The function is expected to be called often ("hot" function)
>   [[likely]] void process_data();
>
>
>
> --
> 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.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2994274-139f-=
96b0-3ebd-36d19311709b%40gmail.com
..

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-2%2B0XiEg1WkxwfdSez8UGTkKsX3_wDfT3QqsBtEu=
mN8Vg%40mail.gmail.com.

--001a113ff81228f70c053d5468ce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 9:36, &quot;Andrey Semashev&quot; &lt;<a href=
=3D"mailto:andrey.semashev@gmail.com">andrey.semashev@gmail.com</a>&gt; esc=
ribi=C3=B3:<br>
&gt;<br>
&gt; On 09/25/16 13:11, <a href=3D"mailto:mayorga.geek@gmail.com">mayorga.g=
eek@gmail.com</a> wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hello,<br>
&gt;&gt;<br>
&gt;&gt; I am spinning around the idea of the possibility of submitting a<b=
r>
&gt;&gt; language change proposal to expose to the programmer with keywords=
 to<br>
&gt;&gt; hint the compiler in its optimization.<br>
&gt;&gt;<br>
&gt;&gt; AFAIK the feature is not currently covered at language level and i=
t is<br>
&gt;&gt; IMHO sufficiently generic.<br>
&gt;&gt;<br>
&gt;&gt; As an example it would be applicable to the singleton pattern, som=
ething<br>
&gt;&gt; like:<br>
&gt;&gt;<br>
&gt;&gt; T* singleton::get_instance() {<br>
&gt;&gt; =C2=A0 =C2=A0if (p=3D=3D0) unlikely {<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0 p =3D new singleton();<br>
&gt;&gt; =C2=A0 =C2=A0}<br>
&gt;&gt; =C2=A0 =C2=A0return p;<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt; notice the new keyword &quot;unlikely&quot; which can be used by e=
..g. g++ to use<br>
&gt;&gt; its __builtin_expect branch optimizer.<br>
&gt;&gt;<br>
&gt;&gt; I would like to check if this sounds like a feasible proposal.<br>
&gt;<br>
&gt;<br>
&gt; I like the idea but I would suggest a different syntax:<br>
&gt;<br>
&gt;<br>
&gt; =C2=A0 T* singleton::get_instance() {<br>
&gt; =C2=A0 =C2=A0 =C2=A0if (p=3D=3D0) {<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 [[unlikely]]<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 p =3D new singleton();<br>
&gt; =C2=A0 =C2=A0 =C2=A0}<br>
&gt; =C2=A0 =C2=A0 =C2=A0return p;<br>
&gt; =C2=A0 }<br>
&gt;<br>
&gt; The attribute would apply to the branch associated with the statement =
following the attribute. This allows (a) to ignore the attribute if the com=
piler doesn&#39;t support it and (b) use the attribute in other contexts. F=
or example:</p>
<p dir=3D"ltr">Everything involving a branch: if, while, for, switch, ?. Pl=
ease when proposing these sort of things, keep in mind that the world is no=
t only x86. There are other archs that don&#39;t have branch predictors. Th=
at&#39;s why an (ignorable) attribute is what should be, if at ever standar=
ized.<br></p>
<p dir=3D"ltr">&gt;<br>
&gt; =C2=A0 switch (x) {<br>
&gt; =C2=A0 case 1:<br>
&gt; =C2=A0 =C2=A0 // branch with no probability hints<br>
&gt; =C2=A0 =C2=A0 foo();<br>
&gt; =C2=A0 =C2=A0 break;<br>
&gt;<br>
&gt; =C2=A0 case 2:<br>
&gt; =C2=A0 =C2=A0 // the most probable branch<br>
&gt; =C2=A0 =C2=A0 [[likely]]<br>
&gt; =C2=A0 =C2=A0 bar();<br>
&gt; =C2=A0 =C2=A0 break;<br>
&gt;<br>
&gt; =C2=A0 default:<br>
&gt; =C2=A0 =C2=A0 // the least probable branch<br>
&gt; =C2=A0 =C2=A0 [[unlikely]]<br>
&gt; =C2=A0 =C2=A0 throw std::invalid_argument(&quot;unsupported x&quot;);<=
br>
&gt; =C2=A0 }<br>
&gt;<br>
&gt; or:<br>
&gt;<br>
&gt; =C2=A0 for (int i =3D 0; i &lt; n; ++i)<br>
&gt; =C2=A0 {<br>
&gt; =C2=A0 =C2=A0 // Most often n &lt;=3D 0, the loop is rarely executed<b=
r>
&gt; =C2=A0 =C2=A0 [[unlikely]]<br>
&gt; =C2=A0 =C2=A0 baz();<br>
&gt; =C2=A0 }<br>
&gt;<br>
&gt; or:<br>
&gt;<br>
&gt; =C2=A0 // The function is unlikely to be called (&quot;cold&quot; func=
tion)<br>
&gt; =C2=A0 [[unlikely]] void handle_error();<br>
&gt;<br>
&gt; =C2=A0 // The function is expected to be called often (&quot;hot&quot;=
 function)<br>
&gt; =C2=A0 [[likely]] void process_data();<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/b2994274-139f-96b0-3ebd-36d19311=
709b%40gmail.com">https://groups.google.com/a/isocpp.org/d/msgid/std-propos=
als/b2994274-139f-96b0-3ebd-36d19311709b%40gmail.com</a>.<br></p>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2%2B0XiEg1WkxwfdSez8UGTkKsX3_w=
DfT3QqsBtEumN8Vg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2%2B0XiE=
g1WkxwfdSez8UGTkKsX3_wDfT3QqsBtEumN8Vg%40mail.gmail.com</a>.<br />

--001a113ff81228f70c053d5468ce--

.

On 09/25/16 14:40, Robert Bielik wrote:
> I think most modern compilers take care of those optimizations already.
> Is there a case you've found where this would be helpful?

Compilers only make such calls as part of profile-guided optimizations,
and more often than not such optimizations are difficult to apply in
practice because they require running the instrumented code on realistic
input data. Often the developer already knows the most probable
(intended) workflow of the code, and a way to communicate that knowledge
to the compiler would be useful.

I have used __builtin_expect in gcc for this purpose. In practice it
allows to improve hot code locality. For instance, with such a hint the
compiler can move improbable branches out of a tight loop or make the
intended execution of a function more streamlined (e.g. move the code of
constructing and throwing an exception due to a failed parameter check
after the end of the function, making the successful branch more compact).

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8576927d-ce74-dc2f-308c-69b76e8c43ab%40gmail.com.

.

On 09/25/16 15:46, dgutson . wrote:
> El 25/9/2016 9:36, "Andrey Semashev" <andrey.semashev@gmail.com
> <mailto:andrey.semashev@gmail.com>> escribi=C3=B3:
>>
>> I like the idea but I would suggest a different syntax:
>>
>>
>>   T* singleton::get_instance() {
>>      if (p=3D=3D0) {
>>         [[unlikely]]
>>         p =3D new singleton();
>>      }
>>      return p;
>>   }
>>
>> The attribute would apply to the branch associated with the statement
>> following the attribute. This allows (a) to ignore the attribute if the
>> compiler doesn't support it and (b) use the attribute in other contexts.
>
> Everything involving a branch: if, while, for, switch, ?.

Yes, no reason to stop on the 'if' statement alone.

> Please when
> proposing these sort of things, keep in mind that the world is not only
> x86. There are other archs that don't have branch predictors. That's why
> an (ignorable) attribute is what should be, if at ever standarized.

Exactly.

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1fc299fa-fb38-d3d1-1e41-0055df185c76%40gmail.com=
..

.

------=_Part_3659_1796220717.1474808574399
Content-Type: multipart/alternative;
 boundary="----=_Part_3660_159912148.1474808574400"

------=_Part_3660_159912148.1474808574400
Content-Type: text/plain; charset=UTF-8

Hi Robert, thanks for the post.
In fact compilers can take care of optimizations but they can never ignore
what the programmer has in mind regarding the application domain. e.g. I
design a queue storing orders to be processed, if the order belongs to
special customers the algorithm sets a reduced commission in the prize.
Only the programmer knows there are 1 out 1000 special customer so the
branch is unlikely and I want the language has a mean to indicate this fact.

Marcos

On Sunday, 25 September 2016 12:40:51 UTC+1, Robert Bielik wrote:
>
> I think most modern compilers take care of those optimizations already. Is
> there a case you've found where this would be helpful?
>
> /R
>
> Den 25 sep 2016 12:11 skrev <mayorg...@gmail.com <javascript:>>:
>
>> Hello,
>>
>> I am spinning around the idea of the possibility of submitting a language
>> change proposal to expose to the programmer with keywords to hint the
>> compiler in its optimization.
>>
>> AFAIK the feature is not currently covered at language level and it is
>> IMHO sufficiently generic.
>>
>> As an example it would be applicable to the singleton pattern, something
>> like:
>>
>> T* singleton::get_instance() {
>>    if (p==0) unlikely {
>>       p = new singleton();
>>    }
>>    return p;
>> }
>>
>> notice the new keyword "unlikely" which can be used by e.g. g++ to use
>> its __builtin_expect branch optimizer.
>>
>> I would like to check if this sounds like a feasible proposal.
>>
>> Thanks
>> Marcos Mayorga
>>
>>
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/46a63948-ce90-423d-ad73-e482eea5ab20%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/46a63948-ce90-423d-ad73-e482eea5ab20%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3132117c-3648-497d-8598-8d30bc47a759%40isocpp.org.

------=_Part_3660_159912148.1474808574400
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Robert, thanks for the post.<div>In fact compilers can =
take care of optimizations but they can never ignore what the programmer ha=
s in mind regarding the application domain. e.g. I design a queue storing o=
rders to be processed, if the order belongs to special customers the algori=
thm sets a reduced commission in the prize. Only the programmer knows there=
 are 1 out 1000 special customer so the branch is unlikely and I want the l=
anguage has a mean to indicate this fact.</div><div><br></div><div>Marcos</=
div><div><br>On Sunday, 25 September 2016 12:40:51 UTC+1, Robert Bielik  wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">I think mos=
t modern compilers take care of those optimizations already. Is there a cas=
e you&#39;ve found where this would be helpful? </p>
<p dir=3D"ltr">/R</p>
<div><br><div class=3D"gmail_quote">Den 25 sep 2016 12:11 skrev  &lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PGualKdeBAAJ" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tr=
ue;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">mayorg...@g=
mail.com</a>&gt;:<br type=3D"attribution"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">Hello,<div><br></div><div>I am spinning around the idea of t=
he possibility of submitting a language change proposal to expose to the pr=
ogrammer with keywords to hint the compiler in its optimization.</div><div>=
<br></div><div>AFAIK the feature is not currently covered at language level=
 and it is IMHO sufficiently generic.</div><div><br></div><div>As an exampl=
e it would be applicable to the singleton pattern, something like:<br><br>T=
* singleton::get_instance() {</div><div>=C2=A0 =C2=A0if (p=3D=3D0) unlikely=
 {</div><div>=C2=A0 =C2=A0 =C2=A0 p =3D new singleton();</div><div>=C2=A0 =
=C2=A0}</div><div>=C2=A0 =C2=A0return p;</div><div>}<br><br>notice the new =
keyword &quot;unlikely&quot; which can be used by e.g. g++ to use its=C2=A0=
<span style=3D"color:rgb(84,84,84);font-family:arial,sans-serif;font-size:s=
mall;line-height:18.2px">__builtin_expect branch optimizer.</span></div><di=
v><font color=3D"#545454" face=3D"arial, sans-serif" size=3D"2"><span style=
=3D"line-height:18.2px"><br></span></font>I would like to check if this sou=
nds like a feasible proposal.</div><div><br></div><div>Thanks</div><div>Mar=
cos Mayorga</div><div><br><br><br></div></div>

<p></p>

-- <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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
PGualKdeBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"PGualKdeBAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/46a63948-ce90-423d-ad73-e482eea5ab20%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/46a63948-ce90-423d-ad73-e482eea5ab20%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/46a63948-ce90-423d-ad73-e482eea5ab20%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/46a63948-ce90-423d-<wbr>ad73-=
e482eea5ab20%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>
</blockquote></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3132117c-3648-497d-8598-8d30bc47a759%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3132117c-3648-497d-8598-8d30bc47a759=
%40isocpp.org</a>.<br />

------=_Part_3660_159912148.1474808574400--

------=_Part_3659_1796220717.1474808574399--

.

------=_Part_628_384520819.1474808757089
Content-Type: multipart/alternative;
 boundary="----=_Part_629_1022494413.1474808757089"

------=_Part_629_1022494413.1474808757089
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

Thank you for the work on syntax, I really see you are up to have a
standard mean to indicate the likeliness of every possible branch.
Marcos

On Sunday, 25 September 2016 13:36:49 UTC+1, Andrey Semashev wrote:
>
> On 09/25/16 13:11, mayorg...@gmail.com <javascript:> wrote:
> > Hello,
> >
> > I am spinning around the idea of the possibility of submitting a
> > language change proposal to expose to the programmer with keywords to
> > hint the compiler in its optimization.
> >
> > AFAIK the feature is not currently covered at language level and it is
> > IMHO sufficiently generic.
> >
> > As an example it would be applicable to the singleton pattern, something
> > like:
> >
> > T* singleton::get_instance() {
> >    if (p==0) unlikely {
> >       p = new singleton();
> >    }
> >    return p;
> > }
> >
> > notice the new keyword "unlikely" which can be used by e.g. g++ to use
> > its __builtin_expect branch optimizer.
> >
> > I would like to check if this sounds like a feasible proposal.
>
> I like the idea but I would suggest a different syntax:
>
>    T* singleton::get_instance() {
>       if (p==0) {
>          [[unlikely]]
>          p = new singleton();
>       }
>       return p;
>    }
>
> The attribute would apply to the branch associated with the statement
> following the attribute. This allows (a) to ignore the attribute if the
> compiler doesn't support it and (b) use the attribute in other contexts.
> For example:
>
>    switch (x) {
>    case 1:
>      // branch with no probability hints
>      foo();
>      break;
>
>    case 2:
>      // the most probable branch
>      [[likely]]
>      bar();
>      break;
>
>    default:
>      // the least probable branch
>      [[unlikely]]
>      throw std::invalid_argument("unsupported x");
>    }
>
> or:
>
>    for (int i = 0; i < n; ++i)
>    {
>      // Most often n <= 0, the loop is rarely executed
>      [[unlikely]]
>      baz();
>    }
>
> or:
>
>    // The function is unlikely to be called ("cold" function)
>    [[unlikely]] void handle_error();
>
>    // The function is expected to be called often ("hot" function)
>    [[likely]] void process_data();
>
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88ce9e84-87e7-4ad1-a06b-79098a05ace8%40isocpp.org.

------=_Part_629_1022494413.1474808757089
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Andrey,<div><br></div><div>Thank you for the work on sy=
ntax, I really see you are up to have a standard mean to indicate the likel=
iness of every possible branch.</div><div>Marcos<br><br>On Sunday, 25 Septe=
mber 2016 13:36:49 UTC+1, Andrey Semashev  wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">On 09/25/16 13:11, <a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"AYKknrVhBAAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#3=
9;javascript:&#39;;return true;">mayorg...@gmail.com</a> wrote:
<br>&gt; Hello,
<br>&gt;
<br>&gt; I am spinning around the idea of the possibility of submitting a
<br>&gt; language change proposal to expose to the programmer with keywords=
 to
<br>&gt; hint the compiler in its optimization.
<br>&gt;
<br>&gt; AFAIK the feature is not currently covered at language level and i=
t is
<br>&gt; IMHO sufficiently generic.
<br>&gt;
<br>&gt; As an example it would be applicable to the singleton pattern, som=
ething
<br>&gt; like:
<br>&gt;
<br>&gt; T* singleton::get_instance() {
<br>&gt; =C2=A0 =C2=A0if (p=3D=3D0) unlikely {
<br>&gt; =C2=A0 =C2=A0 =C2=A0 p =3D new singleton();
<br>&gt; =C2=A0 =C2=A0}
<br>&gt; =C2=A0 =C2=A0return p;
<br>&gt; }
<br>&gt;
<br>&gt; notice the new keyword &quot;unlikely&quot; which can be used by e=
..g. g++ to use
<br>&gt; its __builtin_expect branch optimizer.
<br>&gt;
<br>&gt; I would like to check if this sounds like a feasible proposal.
<br>
<br>I like the idea but I would suggest a different syntax:
<br>
<br>=C2=A0 =C2=A0T* singleton::get_instance() {
<br>=C2=A0 =C2=A0 =C2=A0 if (p=3D=3D0) {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[[unlikely]]
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0p =3D new singleton();
<br>=C2=A0 =C2=A0 =C2=A0 }
<br>=C2=A0 =C2=A0 =C2=A0 return p;
<br>=C2=A0 =C2=A0}
<br>
<br>The attribute would apply to the branch associated with the statement=
=20
<br>following the attribute. This allows (a) to ignore the attribute if the=
=20
<br>compiler doesn&#39;t support it and (b) use the attribute in other cont=
exts.=20
<br>For example:
<br>
<br>=C2=A0 =C2=A0switch (x) {
<br>=C2=A0 =C2=A0case 1:
<br>=C2=A0 =C2=A0 =C2=A0// branch with no probability hints
<br>=C2=A0 =C2=A0 =C2=A0foo();
<br>=C2=A0 =C2=A0 =C2=A0break;
<br>
<br>=C2=A0 =C2=A0case 2:
<br>=C2=A0 =C2=A0 =C2=A0// the most probable branch
<br>=C2=A0 =C2=A0 =C2=A0[[likely]]
<br>=C2=A0 =C2=A0 =C2=A0bar();
<br>=C2=A0 =C2=A0 =C2=A0break;
<br>
<br>=C2=A0 =C2=A0default:
<br>=C2=A0 =C2=A0 =C2=A0// the least probable branch
<br>=C2=A0 =C2=A0 =C2=A0[[unlikely]]
<br>=C2=A0 =C2=A0 =C2=A0throw std::invalid_argument(&quot;<wbr>unsupported =
x&quot;);
<br>=C2=A0 =C2=A0}
<br>
<br>or:
<br>
<br>=C2=A0 =C2=A0for (int i =3D 0; i &lt; n; ++i)
<br>=C2=A0 =C2=A0{
<br>=C2=A0 =C2=A0 =C2=A0// Most often n &lt;=3D 0, the loop is rarely execu=
ted
<br>=C2=A0 =C2=A0 =C2=A0[[unlikely]]
<br>=C2=A0 =C2=A0 =C2=A0baz();
<br>=C2=A0 =C2=A0}
<br>
<br>or:
<br>
<br>=C2=A0 =C2=A0// The function is unlikely to be called (&quot;cold&quot;=
 function)
<br>=C2=A0 =C2=A0[[unlikely]] void handle_error();
<br>
<br>=C2=A0 =C2=A0// The function is expected to be called often (&quot;hot&=
quot; function)
<br>=C2=A0 =C2=A0[[likely]] void process_data();
<br>
<br>
<br></blockquote></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/88ce9e84-87e7-4ad1-a06b-79098a05ace8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/88ce9e84-87e7-4ad1-a06b-79098a05ace8=
%40isocpp.org</a>.<br />

------=_Part_629_1022494413.1474808757089--

------=_Part_628_384520819.1474808757089--

.

--001a11442c6c5c8a43053d54ac95
Content-Type: text/plain; charset=UTF-8

But that's just it. You're starting with 'compilers should do X' then
jumping somehow to the conclusion of 'the language should do X'.

The proper place for such attributes IMHO is in the compiler. And the good
ones already have them.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFRiQQO94R-R1980Cx61W_Lpi0sYJvFb2Ewsb7BNPfbOQ%40mail.gmail.com.

--001a11442c6c5c8a43053d54ac95
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>But that&#39;s just it. You&#39;re starting with &#39=
;compilers should do X&#39; then jumping somehow to the conclusion of &#39;=
the language should do X&#39;.<br><br></div>The proper place for such attri=
butes IMHO is in the compiler. And the good ones already have them.<br></di=
v>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFRiQQO94R-R1980Cx61W_Lpi0sYJvF=
b2Ewsb7BNPfbOQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFRiQQO94R-=
R1980Cx61W_Lpi0sYJvFb2Ewsb7BNPfbOQ%40mail.gmail.com</a>.<br />

--001a11442c6c5c8a43053d54ac95--

.

------=_Part_174_914445349.1474809367952
Content-Type: multipart/alternative;
 boundary="----=_Part_175_1462189266.1474809367952"

------=_Part_175_1462189266.1474809367952
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The compiler does not know the application domain, and AFAIK some of them=
=20
has set this prediction random. In general I think this applicable to any=
=20
computer language, the programmer should have a mean to hint the compiler=
=20
when sometimes is obvious you=C5=95e programming a corner case branch, if t=
he=20
compiler ignores these hints it will just generate less optimized code for=
=20
a real case execution.

On Sunday, 25 September 2016 14:06:03 UTC+1, D. B. wrote:
>
> But that's just it. You're starting with 'compilers should do X' then=20
> jumping somehow to the conclusion of 'the language should do X'.
>
> The proper place for such attributes IMHO is in the compiler. And the goo=
d=20
> ones already have them.
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8ecef61d-9942-4ad7-a2a5-af1cf244a995%40isocpp.or=
g.

------=_Part_175_1462189266.1474809367952
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The compiler does not know the application domain, and AFA=
IK some of them has set this prediction random. In general I think this app=
licable to any computer language, the programmer should have a mean to hint=
 the compiler when sometimes is obvious you=C5=95e programming a corner cas=
e branch, if the compiler ignores these hints it will just generate less op=
timized code for a real case execution.<br><br>On Sunday, 25 September 2016=
 14:06:03 UTC+1, D. B.  wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div>But that&#39;s just it. You&#39;re starting with &#39=
;compilers should do X&#39; then jumping somehow to the conclusion of &#39;=
the language should do X&#39;.<br><br></div>The proper place for such attri=
butes IMHO is in the compiler. And the good ones already have them.<br></di=
v>
</blockquote></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8ecef61d-9942-4ad7-a2a5-af1cf244a995%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8ecef61d-9942-4ad7-a2a5-af1cf244a995=
%40isocpp.org</a>.<br />

------=_Part_175_1462189266.1474809367952--

------=_Part_174_914445349.1474809367952--

.

--001a113fb554783862053d550d1f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 25/9/2016 10:16, <mayorga.geek@gmail.com> escribi=C3=B3:
>
> The compiler does not know the application domain, and AFAIK some of them
has set this prediction random. In general I think this applicable to any
computer language, the programmer should have a mean to hint the compiler
when sometimes is obvious you=C5=95e programming a corner case branch, if t=
he
compiler ignores these hints it will just generate less optimized code for
a real case execution.

But why a standard attribute? Go to your compiler vendor and ask to provide
an attribute. Think in portability.
So my question remains: why an architecture-specific feature should be
standard, when the language provides the syntax? Please answer.

>
>
> On Sunday, 25 September 2016 14:06:03 UTC+1, D. B. wrote:
>>
>> But that's just it. You're starting with 'compilers should do X' then
jumping somehow to the conclusion of 'the language should do X'.
>>
>> The proper place for such attributes IMHO is in the compiler. And the
good ones already have them.
>
> --
> 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.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8ecef61d-9942-=
4ad7-a2a5-af1cf244a995%40isocpp.org
..

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-2mJwLMZ7JhA49ndwLS1zZh5Yafap5beCC%2BZ4dHB=
dtJvw%40mail.gmail.com.

--001a113fb554783862053d550d1f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 10:16, &lt;<a href=3D"mailto:mayorga.geek@gmail=
..com">mayorga.geek@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; The compiler does not know the application domain, and AFAIK some of t=
hem has set this prediction random. In general I think this applicable to a=
ny computer language, the programmer should have a mean to hint the compile=
r when sometimes is obvious you=C5=95e programming a corner case branch, if=
 the compiler ignores these hints it will just generate less optimized code=
 for a real case execution.</p>
<p dir=3D"ltr">But why a standard attribute? Go to your compiler vendor and=
 ask to provide an attribute. Think in portability.<br>
So my question remains: why an architecture-specific feature should be stan=
dard, when the language provides the syntax? Please answer.</p>
<p dir=3D"ltr">&gt;<br>
&gt;<br>
&gt; On Sunday, 25 September 2016 14:06:03 UTC+1, D. B. wrote:<br>
&gt;&gt;<br>
&gt;&gt; But that&#39;s just it. You&#39;re starting with &#39;compilers sh=
ould do X&#39; then jumping somehow to the conclusion of &#39;the language =
should do X&#39;.<br>
&gt;&gt;<br>
&gt;&gt; The proper place for such attributes IMHO is in the compiler. And =
the good ones already have them.<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/8ecef61d-9942-4ad7-a2a5-af1cf244=
a995%40isocpp.org">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/8ecef61d-9942-4ad7-a2a5-af1cf244a995%40isocpp.org</a>.<br></p>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2mJwLMZ7JhA49ndwLS1zZh5Yafap5b=
eCC%2BZ4dHBdtJvw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2mJwLMZ7=
JhA49ndwLS1zZh5Yafap5beCC%2BZ4dHBdtJvw%40mail.gmail.com</a>.<br />

--001a113fb554783862053d550d1f--

.

> But why a standard attribute? Go to your compiler vendor and ask to provi=
de an attribute. Think in portability.
> So my question remains: why an architecture-specific feature should be st=
andard, when the language provides the syntax? Please answer.

Why is this attribute architecture-specific? The compiler may as well use t=
he attribute for optimization of code locality, having the common branch be=
 closer. It is obviously implementation and platform specific as to what ex=
tend the hint can be used.

I would extend this to be more than [[likely]] and [[unlikely]] but [[branc=
h_probability: (likely|unlikely|value that must add up to 1.0 across all br=
anches)]] which might be more than current generation of compilers and arch=
itecture can handle (the probability values case), but seems more flexible =
and only adds one attribute with argument rather than two attributes. The n=
ame may also include =E2=80=9Ehint=E2=80=9C to make it explicit this is onl=
y an optimization and may not have any effect.

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/716602A1-5556-4D1C-93BF-A0B2F58001CB%40googlemai=
l.com.

.

--001a114abfb2160bf4053d554aab
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 25/9/2016 10:45, "'Bernd L=C3=B6rwald' via ISO C++ Standard - Future
Proposals" <std-proposals@isocpp.org> escribi=C3=B3:
>
>
> > But why a standard attribute? Go to your compiler vendor and ask to
provide an attribute. Think in portability.
> > So my question remains: why an architecture-specific feature should be
standard, when the language provides the syntax? Please answer.
>
> Why is this attribute architecture-specific? The compiler may as well use
the attribute for optimization of code locality, having the common branch
be closer. It is obviously implementation and platform specific as to what
extend the hint can be used.

Isn't code locality also applicable to architectures that have icache,
again thinking in x86 and therefore yet another example of arch-specific?
If so I can think of many architectures where this feature would be non
applicable. I still don't see the point to make this standard.

>
> I would extend this to be more than [[likely]] and [[unlikely]] but
[[branch_probability: (likely|unlikely|value that must add up to 1.0 across
all branches)]] which might be more than current generation of compilers
and architecture can handle (the probability values case), but seems more
flexible and only adds one attribute with argument rather than two
attributes. The name may also include =E2=80=9Ehint=E2=80=9C to make it exp=
licit this is
only an optimization and may not have any effect.

And I like your idea, but for an x86 compiler vendor :)

>
> --
> 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.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/716602A1-5556-=
4D1C-93BF-A0B2F58001CB%40googlemail.com
..

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-3TC6zwfPEHc%2B_rRUL0a8N8hr7-eHaa_hpGYh1tt=
KPkSQ%40mail.gmail.com.

--001a114abfb2160bf4053d554aab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 10:45, &quot;&#39;Bernd L=C3=B6rwald&#39; via I=
SO C++ Standard - Future Proposals&quot; &lt;<a href=3D"mailto:std-proposal=
s@isocpp.org">std-proposals@isocpp.org</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt;<br>
&gt; &gt; But why a standard attribute? Go to your compiler vendor and ask =
to provide an attribute. Think in portability.<br>
&gt; &gt; So my question remains: why an architecture-specific feature shou=
ld be standard, when the language provides the syntax? Please answer.<br>
&gt;<br>
&gt; Why is this attribute architecture-specific? The compiler may as well =
use the attribute for optimization of code locality, having the common bran=
ch be closer. It is obviously implementation and platform specific as to wh=
at extend the hint can be used.</p>
<p dir=3D"ltr">Isn&#39;t code locality also applicable to architectures tha=
t have icache, again thinking in x86 and therefore yet another example of a=
rch-specific? If so I can think of many architectures where this feature wo=
uld be non applicable. I still don&#39;t see the point to make this standar=
d.</p>
<p dir=3D"ltr">&gt;<br>
&gt; I would extend this to be more than [[likely]] and [[unlikely]] but [[=
branch_probability: (likely|unlikely|value that must add up to 1.0 across a=
ll branches)]] which might be more than current generation of compilers and=
 architecture can handle (the probability values case), but seems more flex=
ible and only adds one attribute with argument rather than two attributes. =
The name may also include =E2=80=9Ehint=E2=80=9C to make it explicit this i=
s only an optimization and may not have any effect.</p>
<p dir=3D"ltr">And I like your idea, but for an x86 compiler vendor :)</p>
<p dir=3D"ltr">&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/716602A1-5556-4D1C-93BF-A0B2F580=
01CB%40googlemail.com">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/716602A1-5556-4D1C-93BF-A0B2F58001CB%40googlemail.com</a>.<br></p>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3TC6zwfPEHc%2B_rRUL0a8N8hr7-eH=
aa_hpGYh1ttKPkSQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3TC6zwfP=
EHc%2B_rRUL0a8N8hr7-eHaa_hpGYh1ttKPkSQ%40mail.gmail.com</a>.<br />

--001a114abfb2160bf4053d554aab--

.

------=_Part_3471_2123484340.1474811591137
Content-Type: multipart/alternative;
 boundary="----=_Part_3472_888510992.1474811591137"

------=_Part_3472_888510992.1474811591137
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I normally have to define the following snippet in my code:
#ifdef __GNUC__
# if (__GNUC__ >=3D 3)
#  define likely(x)     __builtin_expect ((x), 1)
#  define unlikely(x)   __builtin_expect ((x), 0)
# else
#  define likely(x)     (x)
#  define unlikely(x)   (x)
# endif
#else
# define likely(x)      (x)
# define unlikely(x)    (x)
#endif

then I use these macros in statements like
if (likely(cond)) ...

Then I think when I do that kind of predictions while programming is=20
because I know what I am saying that this branch is likely to be executed=
=20
unless some corner case happens. Or programming corner cases I do=20
if(unlikely(cond))... exactly the same thing.

Then my activity is using my domain knowledge to state in my program such=
=20
thing, something the compiler is not able to know, and for these cases=20
which I think are pretty abundant the language should be keen to give=20
support on accepting such hints, to give support for stating thoughts, that=
=20
is all about. Then the compiler will generate assembler based on all=20
inputs.=20
So my question could turn into how a programming language would prevent a=
=20
programmer to communicate his/her intent?

This is not a compiler feature, the compiler know low level facts,=20
depending on the arch its task is to generate optimized assembler. It can=
=20
optimize based on its target platform knowledge but it will never know the=
=20
application domain and the higher level stuff only the programmer knows,=20
i.e. the programmer knows when he is coding a corner case that has low=20
chances of execution.

Looking at it from the most abstract point of view I can I would say the=20
language should allow to gather this input from the programmer, then the=20
compiler would make it the best as it can. It is all about capturing the=20
programmer's intent.



On Sunday, 25 September 2016 14:33:15 UTC+1, dgutson wrote:
>
> El 25/9/2016 10:16, <mayorg...@gmail.com <javascript:>> escribi=C3=B3:
> >
> > The compiler does not know the application domain, and AFAIK some of=20
> them has set this prediction random. In general I think this applicable t=
o=20
> any computer language, the programmer should have a mean to hint the=20
> compiler when sometimes is obvious you=C5=95e programming a corner case b=
ranch,=20
> if the compiler ignores these hints it will just generate less optimized=
=20
> code for a real case execution.
>
> But why a standard attribute? Go to your compiler vendor and ask to=20
> provide an attribute. Think in portability.
> So my question remains: why an architecture-specific feature should be=20
> standard, when the language provides the syntax? Please answer.
>
> >
> >
> > On Sunday, 25 September 2016 14:06:03 UTC+1, D. B. wrote:
> >>
> >> But that's just it. You're starting with 'compilers should do X' then=
=20
> jumping somehow to the conclusion of 'the language should do X'.
> >>
> >> The proper place for such attributes IMHO is in the compiler. And the=
=20
> good ones already have them.
> >
> > --=20
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
> > To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8ecef61d-994=
2-4ad7-a2a5-af1cf244a995%40isocpp.org
> .
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/430b835a-c055-4db9-8cdc-952b4578a4f7%40isocpp.or=
g.

------=_Part_3472_888510992.1474811591137
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I normally have to define the following snippet in my code=
:<br><div>#ifdef __GNUC__</div><div># if (__GNUC__ &gt;=3D 3)</div><div># =
=C2=A0define likely(x) =C2=A0 =C2=A0 __builtin_expect ((x), 1)</div><div># =
=C2=A0define unlikely(x) =C2=A0 __builtin_expect ((x), 0)</div><div># else<=
/div><div># =C2=A0define likely(x) =C2=A0 =C2=A0 (x)</div><div># =C2=A0defi=
ne unlikely(x) =C2=A0 (x)</div><div># endif</div><div>#else</div><div># def=
ine likely(x) =C2=A0 =C2=A0 =C2=A0(x)</div><div># define unlikely(x) =C2=A0=
 =C2=A0(x)</div><div>#endif</div><div><br>then I use these macros in statem=
ents like</div><div>if (likely(cond)) ...</div><div><br></div><div>Then I t=
hink when I do that kind of predictions while programming is because I know=
 what I am saying that this branch is likely to be executed unless some cor=
ner case happens. Or programming corner cases I do if(unlikely(cond))... ex=
actly the same thing.</div><div><br></div><div>Then my activity is using my=
 domain knowledge to state in my program such thing, something the compiler=
 is not able to know, and for these cases which I think are pretty abundant=
 the language should be keen to give support on accepting such hints, to gi=
ve support for stating thoughts, that is all about. Then the compiler will =
generate assembler based on all inputs.=C2=A0</div><div>So my question coul=
d turn into how a programming language would prevent a programmer to commun=
icate his/her intent?</div><div><br></div><div>This is not a compiler featu=
re, the compiler know low level facts, depending on the arch its task is to=
 generate optimized assembler. It can optimize based on its target platform=
 knowledge but it will never know the application domain and the higher lev=
el stuff only the programmer knows, i.e. the programmer knows when he is co=
ding a corner case that has low chances of execution.</div><div><br></div><=
div>Looking at it from the most abstract point of view I can I would say th=
e language should allow to gather this input from the programmer, then the =
compiler would make it the best as it can. It is all about capturing the pr=
ogrammer&#39;s intent.<br></div><div><br></div><div><br></div><br>On Sunday=
, 25 September 2016 14:33:15 UTC+1, dgutson  wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 10:16, &lt;<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"Qex8x8lkBAAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">mayorg...@gmail.com</a>&gt; escribi=C3=
=B3:<br>
&gt;<br>
&gt; The compiler does not know the application domain, and AFAIK some of t=
hem has set this prediction random. In general I think this applicable to a=
ny computer language, the programmer should have a mean to hint the compile=
r when sometimes is obvious you=C5=95e programming a corner case branch, if=
 the compiler ignores these hints it will just generate less optimized code=
 for a real case execution.</p>
<p dir=3D"ltr">But why a standard attribute? Go to your compiler vendor and=
 ask to provide an attribute. Think in portability.<br>
So my question remains: why an architecture-specific feature should be stan=
dard, when the language provides the syntax? Please answer.</p>
<p dir=3D"ltr">&gt;<br>
&gt;<br>
&gt; On Sunday, 25 September 2016 14:06:03 UTC+1, D. B. wrote:<br>
&gt;&gt;<br>
&gt;&gt; But that&#39;s just it. You&#39;re starting with &#39;compilers sh=
ould do X&#39; then jumping somehow to the conclusion of &#39;the language =
should do X&#39;.<br>
&gt;&gt;<br>
&gt;&gt; The proper place for such attributes IMHO is in the compiler. And =
the good ones already have them.<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"Qex8x8lkBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">std-proposal...@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"Qex8x8lkBAAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/8ecef61d-9942-4ad7-a2a5-af1cf244=
a995%40isocpp.org" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8ec=
ef61d-9942-4ad7-a2a5-af1cf244a995%40isocpp.org&#39;;return true;" onclick=
=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/8ecef61d-9942-4ad7-a2a5-af1cf244a995%40isocpp.org&#39;;return true;"=
>https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/8ec=
ef61d-9942-4ad7-<wbr>a2a5-af1cf244a995%40isocpp.org</a><wbr>.<br></p>
</blockquote></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/430b835a-c055-4db9-8cdc-952b4578a4f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/430b835a-c055-4db9-8cdc-952b4578a4f7=
%40isocpp.org</a>.<br />

------=_Part_3472_888510992.1474811591137--

------=_Part_3471_2123484340.1474811591137--

.

--001a113eb1347ccc97053d558181
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 25/9/2016 10:53, <mayorga.geek@gmail.com> escribi=C3=B3:
>
> I normally have to define the following snippet in my code:
> #ifdef __GNUC__
> # if (__GNUC__ >=3D 3)
> #  define likely(x)     __builtin_expect ((x), 1)
> #  define unlikely(x)   __builtin_expect ((x), 0)
> # else
> #  define likely(x)     (x)
> #  define unlikely(x)   (x)
> # endif
> #else
> # define likely(x)      (x)
> # define unlikely(x)    (x)
> #endif
>
> then I use these macros in statements like
> if (likely(cond)) ...

Yes, http://lxr.free-electrons.com/source/tools/include/linux/compiler.h#L3=
5
has been there for ages and the whole kernel use them.

See, I agree this feature is useful for optimizations where the
architecture provides hw support, and useless in most embedded archs. I
don't see this very useful as a documentation feature.
My oppinion is that this should not be standard.
However I don't want to prevent you to pursue the idea.
So my suggestion is: go and write a proposal with all the info you gathered
from this discussion, write a gcc plugin supporting this feature as an
attribute, and provide benchmarks in the paper.
Then present it in wg21 or look for a champion to present it for you.

This being said, I don't see the point to continue with this discussion. At
least for me.
>
> Then I think when I do that kind of predictions while programming is
because I know what I am saying that this branch is likely to be executed
unless some corner case happens. Or programming corner cases I do
if(unlikely(cond))... exactly the same thing.
>
> Then my activity is using my domain knowledge to state in my program such
thing, something the compiler is not able to know, and for these cases
which I think are pretty abundant the language should be keen to give
support on accepting such hints, to give support for stating thoughts, that
is all about. Then the compiler will generate assembler based on all
inputs.
> So my question could turn into how a programming language would prevent a
programmer to communicate his/her intent?
>
> This is not a compiler feature, the compiler know low level facts,
depending on the arch its task is to generate optimized assembler. It can
optimize based on its target platform knowledge but it will never know the
application domain and the higher level stuff only the programmer knows,
i.e. the programmer knows when he is coding a corner case that has low
chances of execution.
>
> Looking at it from the most abstract point of view I can I would say the
language should allow to gather this input from the programmer, then the
compiler would make it the best as it can. It is all about capturing the
programmer's intent.
>
>
>
> On Sunday, 25 September 2016 14:33:15 UTC+1, dgutson wrote:
>>
>> El 25/9/2016 10:16, <mayorg...@gmail.com> escribi=C3=B3:
>> >
>> > The compiler does not know the application domain, and AFAIK some of
them has set this prediction random. In general I think this applicable to
any computer language, the programmer should have a mean to hint the
compiler when sometimes is obvious you=C5=95e programming a corner case bra=
nch,
if the compiler ignores these hints it will just generate less optimized
code for a real case execution.
>>
>> But why a standard attribute? Go to your compiler vendor and ask to
provide an attribute. Think in portability.
>> So my question remains: why an architecture-specific feature should be
standard, when the language provides the syntax? Please answer.
>>
>> >
>> >
>> > On Sunday, 25 September 2016 14:06:03 UTC+1, D. B. wrote:
>> >>
>> >> But that's just it. You're starting with 'compilers should do X' then
jumping somehow to the conclusion of 'the language should do X'.
>> >>
>> >> The proper place for such attributes IMHO is in the compiler. And the
good ones already have them.
>> >
>> > --
>> > 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-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@isocpp.org.
>>
>> > To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8ecef61d-9942-=
4ad7-a2a5-af1cf244a995%40isocpp.org
..
>
> --
> 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.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/430b835a-c055-=
4db9-8cdc-952b4578a4f7%40isocpp.org
..

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-2A13tyFywuYOQUTBbneX_f-PHhaynXpuUfb16fxAU=
NoA%40mail.gmail.com.

--001a113eb1347ccc97053d558181
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 10:53, &lt;<a href=3D"mailto:mayorga.geek@gmail=
..com">mayorga.geek@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; I normally have to define the following snippet in my code:<br>
&gt; #ifdef __GNUC__<br>
&gt; # if (__GNUC__ &gt;=3D 3)<br>
&gt; # =C2=A0define likely(x) =C2=A0 =C2=A0 __builtin_expect ((x), 1)<br>
&gt; # =C2=A0define unlikely(x) =C2=A0 __builtin_expect ((x), 0)<br>
&gt; # else<br>
&gt; # =C2=A0define likely(x) =C2=A0 =C2=A0 (x)<br>
&gt; # =C2=A0define unlikely(x) =C2=A0 (x)<br>
&gt; # endif<br>
&gt; #else<br>
&gt; # define likely(x) =C2=A0 =C2=A0 =C2=A0(x)<br>
&gt; # define unlikely(x) =C2=A0 =C2=A0(x)<br>
&gt; #endif<br>
&gt;<br>
&gt; then I use these macros in statements like<br>
&gt; if (likely(cond)) ...</p>
<p dir=3D"ltr">Yes, <a href=3D"http://lxr.free-electrons.com/source/tools/i=
nclude/linux/compiler.h#L35">http://lxr.free-electrons.com/source/tools/inc=
lude/linux/compiler.h#L35</a> has been there for ages and the whole kernel =
use them.</p>
<p dir=3D"ltr">See, I agree this feature is useful for optimizations where =
the architecture provides hw support, and useless in most embedded archs. I=
 don&#39;t see this very useful as a documentation feature.<br>
My oppinion is that this should not be standard.<br>
However I don&#39;t want to prevent you to pursue the idea.<br>
So my suggestion is: go and write a proposal with all the info you gathered=
 from this discussion, write a gcc plugin supporting this feature as an att=
ribute, and provide benchmarks in the paper.<br>
Then present it in wg21 or look for a champion to present it for you.</p>
<p dir=3D"ltr">This being said, I don&#39;t see the point to continue with =
this discussion. At least for me.<br>
&gt;<br>
&gt; Then I think when I do that kind of predictions while programming is b=
ecause I know what I am saying that this branch is likely to be executed un=
less some corner case happens. Or programming corner cases I do if(unlikely=
(cond))... exactly the same thing.<br>
&gt;<br>
&gt; Then my activity is using my domain knowledge to state in my program s=
uch thing, something the compiler is not able to know, and for these cases =
which I think are pretty abundant the language should be keen to give suppo=
rt on accepting such hints, to give support for stating thoughts, that is a=
ll about. Then the compiler will generate assembler based on all inputs.=C2=
=A0<br>
&gt; So my question could turn into how a programming language would preven=
t a programmer to communicate his/her intent?<br>
&gt;<br>
&gt; This is not a compiler feature, the compiler know low level facts, dep=
ending on the arch its task is to generate optimized assembler. It can opti=
mize based on its target platform knowledge but it will never know the appl=
ication domain and the higher level stuff only the programmer knows, i.e. t=
he programmer knows when he is coding a corner case that has low chances of=
 execution.<br>
&gt;<br>
&gt; Looking at it from the most abstract point of view I can I would say t=
he language should allow to gather this input from the programmer, then the=
 compiler would make it the best as it can. It is all about capturing the p=
rogrammer&#39;s intent.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Sunday, 25 September 2016 14:33:15 UTC+1, dgutson wrote:<br>
&gt;&gt;<br>
&gt;&gt; El 25/9/2016 10:16, &lt;<a href=3D"mailto:mayorg...@gmail.com">may=
org...@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The compiler does not know the application domain, and AFAIK =
some of them has set this prediction random. In general I think this applic=
able to any computer language, the programmer should have a mean to hint th=
e compiler when sometimes is obvious you=C5=95e programming a corner case b=
ranch, if the compiler ignores these hints it will just generate less optim=
ized code for a real case execution.<br>
&gt;&gt;<br>
&gt;&gt; But why a standard attribute? Go to your compiler vendor and ask t=
o provide an attribute. Think in portability.<br>
&gt;&gt; So my question remains: why an architecture-specific feature shoul=
d be standard, when the language provides the syntax? Please answer.<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Sunday, 25 September 2016 14:06:03 UTC+1, D. B. wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; But that&#39;s just it. You&#39;re starting with &#39;com=
pilers should do X&#39; then jumping somehow to the conclusion of &#39;the =
language should do X&#39;.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; The proper place for such attributes IMHO is in the compi=
ler. And the good ones already have them.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -- <br>
&gt;&gt; &gt; You received this message because you are subscribed to the G=
oogle Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt;&gt; &gt; To unsubscribe from this group and stop receiving emails from=
 it, send an email to <a href=3D"mailto:std-proposal...@isocpp.org">std-pro=
posal...@isocpp.org</a>.<br>
&gt;&gt; &gt; To post to this group, send email to <a href=3D"mailto:std-pr=
....@isocpp.org">std-pr...@isocpp.org</a>.<br>
&gt;&gt;<br>
&gt;&gt; &gt; To view this discussion on the web visit <a href=3D"https://g=
roups.google.com/a/isocpp.org/d/msgid/std-proposals/8ecef61d-9942-4ad7-a2a5=
-af1cf244a995%40isocpp.org">https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/8ecef61d-9942-4ad7-a2a5-af1cf244a995%40isocpp.org</a>.<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/430b835a-c055-4db9-8cdc-952b4578=
a4f7%40isocpp.org">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/430b835a-c055-4db9-8cdc-952b4578a4f7%40isocpp.org</a>.<br></p>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2A13tyFywuYOQUTBbneX_f-PHhaynX=
puUfb16fxAUNoA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2A13tyFywu=
YOQUTBbneX_f-PHhaynXpuUfb16fxAUNoA%40mail.gmail.com</a>.<br />

--001a113eb1347ccc97053d558181--

.

On 09/25/16 16:33, dgutson . wrote:
> El 25/9/2016 10:16, <mayorga.geek@gmail.com
> <mailto:mayorga.geek@gmail.com>> escribi=C3=B3:
>>
>> The compiler does not know the application domain, and AFAIK some of
> them has set this prediction random. In general I think this applicable
> to any computer language, the programmer should have a mean to hint the
> compiler when sometimes is obvious you=C5=95e programming a corner case
> branch, if the compiler ignores these hints it will just generate less
> optimized code for a real case execution.
>
> But why a standard attribute? Go to your compiler vendor and ask to
> provide an attribute. Think in portability.
> So my question remains: why an architecture-specific feature should be
> standard, when the language provides the syntax? Please answer.

If I may, my answer is the same reason we have the standard in the first=20
place - to have a portable tool for that. Yes, we have compiler-specific=20
intrinsics now, but the point of standardizing is to relieve the=20
developers from having to define macros on top of them over and over again.

Also, I disagree with you calling it an architecture-specific feature.=20
Even if an architecture lacks hardware branch prediction hints, like x86=20
or IA-64, or even the branch predictor itself (which, I think, is rare=20
these days), the hint can still be used to organize and optimize code.=20
For instance, besides code locality, the hint may instruct the compiler=20
to optimize less frequently executed sections for size rather than speed=20
or move them to a different section altogether. Such behavior is not=20
architecture specific.

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/abeb6c76-63dd-5814-bf3f-d5564c8fdfe7%40gmail.com=
..

.

On 09/25/16 16:44, 'Bernd L=C3=B6rwald' via ISO C++ Standard - Future=20
Proposals wrote:
>
> I would extend this to be more than [[likely]] and [[unlikely]] but [[bra=
nch_probability: (likely|unlikely|value that must add up to 1.0 across all =
branches)]] which might be more than current generation of compilers and ar=
chitecture can handle (the probability values case), but seems more flexibl=
e and only adds one attribute with argument rather than two attributes. The=
 name may also include =E2=80=9Ehint=E2=80=9C to make it explicit this is o=
nly an optimization and may not have any effect.

The [[branch_probability]] syntax would probably make it unusable in the=20
function declaration to mark cold and hot functions. One could argue we=20
need a separate attribute for that, but I think it would mean=20
essentially the same - the code that is less likely to execute is cold,=20
and the code that is more likely to execute is hot.

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/636647da-a3aa-adae-4f40-74cccc260e06%40gmail.com=
..

.

--001a113ea2064abeab053d55d352
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 25/9/2016 11:14, "Andrey Semashev" <andrey.semashev@gmail.com> escribi=
=C3=B3:
>
> On 09/25/16 16:33, dgutson . wrote:
>>
>> El 25/9/2016 10:16, <mayorga.geek@gmail.com
>> <mailto:mayorga.geek@gmail.com>> escribi=C3=B3:
>>
>>>
>>> The compiler does not know the application domain, and AFAIK some of
>>
>> them has set this prediction random. In general I think this applicable
>> to any computer language, the programmer should have a mean to hint the
>> compiler when sometimes is obvious you=C5=95e programming a corner case
>> branch, if the compiler ignores these hints it will just generate less
>> optimized code for a real case execution.
>>
>> But why a standard attribute? Go to your compiler vendor and ask to
>> provide an attribute. Think in portability.
>> So my question remains: why an architecture-specific feature should be
>> standard, when the language provides the syntax? Please answer.
>
>
> If I may, my answer is the same reason we have the standard in the first
place - to have a portable tool for that. Yes, we have compiler-specific
intrinsics now, but the point of standardizing is to relieve the developers
from having to define macros on top of them over and over again.
>
> Also, I disagree with you calling it an architecture-specific feature.
Even if an architecture lacks hardware branch prediction hints, like x86 or
IA-64, or even the branch predictor itself (which, I think, is rare these
days), the hint can still be used to organize and optimize code. For
instance, besides code locality, the hint may instruct the compiler to
optimize less frequently executed sections for size rather than speed or
move them to a different section altogether. Such behavior is not
architecture specific.

Please show me exactly how would this arch-nonspecific optimization work
either for speed or size and I will believe you :)
I don't see any.

>
>
> --
> 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.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/abeb6c76-63dd-=
5814-bf3f-d5564c8fdfe7%40gmail.com
..

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-0p9iwWZ4bMefkxeeRs9_hnpezK3iL94DGsQ4cFV-%=
3D%2BjQ%40mail.gmail.com.

--001a113ea2064abeab053d55d352
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 11:14, &quot;Andrey Semashev&quot; &lt;<a href=
=3D"mailto:andrey.semashev@gmail.com">andrey.semashev@gmail.com</a>&gt; esc=
ribi=C3=B3:<br>
&gt;<br>
&gt; On 09/25/16 16:33, dgutson . wrote:<br>
&gt;&gt;<br>
&gt;&gt; El 25/9/2016 10:16, &lt;<a href=3D"mailto:mayorga.geek@gmail.com">=
mayorga.geek@gmail.com</a><br>
&gt;&gt; &lt;mailto:<a href=3D"mailto:mayorga.geek@gmail.com">mayorga.geek@=
gmail.com</a>&gt;&gt; escribi=C3=B3:<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The compiler does not know the application domain, and AFAIK s=
ome of<br>
&gt;&gt;<br>
&gt;&gt; them has set this prediction random. In general I think this appli=
cable<br>
&gt;&gt; to any computer language, the programmer should have a mean to hin=
t the<br>
&gt;&gt; compiler when sometimes is obvious you=C5=95e programming a corner=
 case<br>
&gt;&gt; branch, if the compiler ignores these hints it will just generate =
less<br>
&gt;&gt; optimized code for a real case execution.<br>
&gt;&gt;<br>
&gt;&gt; But why a standard attribute? Go to your compiler vendor and ask t=
o<br>
&gt;&gt; provide an attribute. Think in portability.<br>
&gt;&gt; So my question remains: why an architecture-specific feature shoul=
d be<br>
&gt;&gt; standard, when the language provides the syntax? Please answer.<br=
>
&gt;<br>
&gt;<br>
&gt; If I may, my answer is the same reason we have the standard in the fir=
st place - to have a portable tool for that. Yes, we have compiler-specific=
 intrinsics now, but the point of standardizing is to relieve the developer=
s from having to define macros on top of them over and over again.<br>
&gt;<br>
&gt; Also, I disagree with you calling it an architecture-specific feature.=
 Even if an architecture lacks hardware branch prediction hints, like x86 o=
r IA-64, or even the branch predictor itself (which, I think, is rare these=
 days), the hint can still be used to organize and optimize code. For insta=
nce, besides code locality, the hint may instruct the compiler to optimize =
less frequently executed sections for size rather than speed or move them t=
o a different section altogether. Such behavior is not architecture specifi=
c.</p>
<p dir=3D"ltr">Please show me exactly how would this arch-nonspecific optim=
ization work either for speed or size and I will believe you :)<br>
I don&#39;t see any.</p>
<p dir=3D"ltr">&gt;<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/abeb6c76-63dd-5814-bf3f-d5564c8f=
dfe7%40gmail.com">https://groups.google.com/a/isocpp.org/d/msgid/std-propos=
als/abeb6c76-63dd-5814-bf3f-d5564c8fdfe7%40gmail.com</a>.<br></p>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0p9iwWZ4bMefkxeeRs9_hnpezK3iL9=
4DGsQ4cFV-%3D%2BjQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0p9iwW=
Z4bMefkxeeRs9_hnpezK3iL94DGsQ4cFV-%3D%2BjQ%40mail.gmail.com</a>.<br />

--001a113ea2064abeab053d55d352--

.

On 09/25/16 17:28, dgutson . wrote:
> El 25/9/2016 11:14, "Andrey Semashev" <andrey.semashev@gmail.com
> <mailto:andrey.semashev@gmail.com>> escribi=C3=B3:
>>
>> Also, I disagree with you calling it an architecture-specific feature.
> Even if an architecture lacks hardware branch prediction hints, like x86
> or IA-64, or even the branch predictor itself (which, I think, is rare
> these days), the hint can still be used to organize and optimize code.
> For instance, besides code locality, the hint may instruct the compiler
> to optimize less frequently executed sections for size rather than speed
> or move them to a different section altogether. Such behavior is not
> architecture specific.
>
> Please show me exactly how would this arch-nonspecific optimization work
> either for speed or size and I will believe you :)
> I don't see any.

Gcc has attributes hot and cold[1]. I know it's not what was originally=20
proposed in this thread, and it only works on function level, but it=20
does affect codegen and has nothing arch-specific about it. Well, unless=20
you say that optimizing for speed or size in general is an arch-specific=20
thing. Which would be true to some degree, but not enough for me to=20
agree. :)

[1]=20
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-F=
unction-Attributes

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f7a1c157-3ee4-1eaa-b222-d87ad85626c7%40gmail.com=
..

.

------=_Part_3500_873788012.1474814922235
Content-Type: multipart/alternative;
 boundary="----=_Part_3501_1063229454.1474814922236"

------=_Part_3501_1063229454.1474814922236
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It seems obvious that the g++ flag __builtin_expect is able to improve=20
performance,=20
tl,dr of=20
http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html is=
=20
This optimized version runs significantly faster (1.95 versus 2.28 seconds)=
=20
than our version that used __builtin_expect()

So that means some compilers on some archs can take advantage of user input=
=20
regarding branch hinting.

IMHO a language devoted for performance should allow to specify this=20
important kind of hint, and this is generalised to all chips because these=
=20
hints come from the domain knowledge of the programmer. Then every compiler=
=20
will make it the best as it can to generate the fastest code (not sure=20
about how it will improve size but performance is important enough), the=20
worst thing it may happen is the compiler ignores the hint and generate=20
regular code, this responsibility is forwarded to the compiler=20
implementation, but the program will still reflect the programmer's intent,=
=20
and this is what this proposal is about, a computer language is the=20
interface to convert domain knowledge into assembler, and branch hinting=20
belongs to this side, the programmer's side.



On Sunday, 25 September 2016 15:28:36 UTC+1, dgutson wrote:
>
> El 25/9/2016 11:14, "Andrey Semashev" <andrey....@gmail.com <javascript:>=
>=20
> escribi=C3=B3:
> >
> > On 09/25/16 16:33, dgutson . wrote:
> >>
> >> El 25/9/2016 10:16, <mayorg...@gmail.com <javascript:>
> >> <mailto:mayorg...@gmail.com <javascript:>>> escribi=C3=B3:
> >>
> >>>
> >>> The compiler does not know the application domain, and AFAIK some of
> >>
> >> them has set this prediction random. In general I think this applicabl=
e
> >> to any computer language, the programmer should have a mean to hint th=
e
> >> compiler when sometimes is obvious you=C5=95e programming a corner cas=
e
> >> branch, if the compiler ignores these hints it will just generate less
> >> optimized code for a real case execution.
> >>
> >> But why a standard attribute? Go to your compiler vendor and ask to
> >> provide an attribute. Think in portability.
> >> So my question remains: why an architecture-specific feature should be
> >> standard, when the language provides the syntax? Please answer.
> >
> >
> > If I may, my answer is the same reason we have the standard in the firs=
t=20
> place - to have a portable tool for that. Yes, we have compiler-specific=
=20
> intrinsics now, but the point of standardizing is to relieve the develope=
rs=20
> from having to define macros on top of them over and over again.
> >
> > Also, I disagree with you calling it an architecture-specific feature.=
=20
> Even if an architecture lacks hardware branch prediction hints, like x86 =
or=20
> IA-64, or even the branch predictor itself (which, I think, is rare these=
=20
> days), the hint can still be used to organize and optimize code. For=20
> instance, besides code locality, the hint may instruct the compiler to=20
> optimize less frequently executed sections for size rather than speed or=
=20
> move them to a different section altogether. Such behavior is not=20
> architecture specific.
>
> Please show me exactly how would this arch-nonspecific optimization work=
=20
> either for speed or size and I will believe you :)
> I don't see any.
>
> >
> >
> > --=20
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
> > To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/abeb6c76-63d=
d-5814-bf3f-d5564c8fdfe7%40gmail.com
> .
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/061acc9a-1c08-4c1b-acea-0b879847322b%40isocpp.or=
g.

------=_Part_3501_1063229454.1474814922236
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It seems obvious that the g++ flag __builtin_expect is abl=
e to improve performance,=C2=A0<div>tl,dr of http://blog.man7.org/2012/10/h=
ow-much-do-builtinexpect-likely-and.html is=C2=A0<div><span style=3D"color:=
 rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20.8px;">This o=
ptimized version runs significantly faster (1.95 versus 2.28 seconds) than =
our version that used=C2=A0</span><span style=3D"color: rgb(51, 51, 51); li=
ne-height: 20.8px; font-family: &#39;Courier New&#39;, Courier, monospace;"=
>__builtin_expect()</span><br><br>So that means some compilers on some arch=
s can take advantage of user input regarding branch hinting.</div><div><br>=
</div><div>IMHO a language devoted for performance should allow to specify =
this important kind of hint, and this is generalised to all chips because t=
hese hints come from the domain knowledge of the programmer. Then every com=
piler will make it the best as it can to generate the fastest code (not sur=
e about how it will improve size but performance is important enough), the =
worst thing it may happen is the compiler ignores the hint and generate reg=
ular code, this responsibility is forwarded to the compiler implementation,=
 but the program will still reflect the programmer&#39;s intent, and this i=
s what this proposal is about, a computer language is the interface to conv=
ert domain knowledge into assembler, and branch hinting belongs to this sid=
e, the programmer&#39;s side.</div><div><br></div><div><br></div><div><br>O=
n Sunday, 25 September 2016 15:28:36 UTC+1, dgutson  wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 11:14, &quot;Andrey Semashev&quot; &lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"maJq_M5nBAAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">andrey....@g=
mail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; On 09/25/16 16:33, dgutson . wrote:<br>
&gt;&gt;<br>
&gt;&gt; El 25/9/2016 10:16, &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"maJq_M5nBAAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">mayorg...@gmail.com</a><br>
&gt;&gt; &lt;mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"maJq_M5nBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;=
;return true;">mayorg...@gmail.com</a><wbr>&gt;&gt; escribi=C3=B3:<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The compiler does not know the application domain, and AFAIK s=
ome of<br>
&gt;&gt;<br>
&gt;&gt; them has set this prediction random. In general I think this appli=
cable<br>
&gt;&gt; to any computer language, the programmer should have a mean to hin=
t the<br>
&gt;&gt; compiler when sometimes is obvious you=C5=95e programming a corner=
 case<br>
&gt;&gt; branch, if the compiler ignores these hints it will just generate =
less<br>
&gt;&gt; optimized code for a real case execution.<br>
&gt;&gt;<br>
&gt;&gt; But why a standard attribute? Go to your compiler vendor and ask t=
o<br>
&gt;&gt; provide an attribute. Think in portability.<br>
&gt;&gt; So my question remains: why an architecture-specific feature shoul=
d be<br>
&gt;&gt; standard, when the language provides the syntax? Please answer.<br=
>
&gt;<br>
&gt;<br>
&gt; If I may, my answer is the same reason we have the standard in the fir=
st place - to have a portable tool for that. Yes, we have compiler-specific=
 intrinsics now, but the point of standardizing is to relieve the developer=
s from having to define macros on top of them over and over again.<br>
&gt;<br>
&gt; Also, I disagree with you calling it an architecture-specific feature.=
 Even if an architecture lacks hardware branch prediction hints, like x86 o=
r IA-64, or even the branch predictor itself (which, I think, is rare these=
 days), the hint can still be used to organize and optimize code. For insta=
nce, besides code locality, the hint may instruct the compiler to optimize =
less frequently executed sections for size rather than speed or move them t=
o a different section altogether. Such behavior is not architecture specifi=
c.</p>
<p dir=3D"ltr">Please show me exactly how would this arch-nonspecific optim=
ization work either for speed or size and I will believe you :)<br>
I don&#39;t see any.</p>
<p dir=3D"ltr">&gt;<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"maJq_M5nBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">std-proposal...@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"maJq_M5nBAAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/abeb6c76-63dd-5814-bf3f-d5564c8f=
dfe7%40gmail.com" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/abeb=
6c76-63dd-5814-bf3f-d5564c8fdfe7%40gmail.com&#39;;return true;" onclick=3D"=
this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/abeb6c76-63dd-5814-bf3f-d5564c8fdfe7%40gmail.com&#39;;return true;">http=
s://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/abeb6c76=
-63dd-5814-<wbr>bf3f-d5564c8fdfe7%40gmail.com</a>.<br></p>
</blockquote></div></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/061acc9a-1c08-4c1b-acea-0b879847322b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/061acc9a-1c08-4c1b-acea-0b879847322b=
%40isocpp.org</a>.<br />

------=_Part_3501_1063229454.1474814922236--

------=_Part_3500_873788012.1474814922235--

.

------=_Part_3397_1030156195.1474815620585
Content-Type: multipart/alternative;
 boundary="----=_Part_3398_1705523233.1474815620585"

------=_Part_3398_1705523233.1474815620585
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Just to throw some more thoughts out there (this is always a thorny topic):

   - What about when the likely branch is not the one that you want to=20
   optimize for?
   - As others have said, having a probability that is more expressible=20
   than just likely/unlikely might be useful (i.e. 20% likely)
   - As others have said, what about switches, and if-elseif branches? I.e.=
=20
   when it's a group of branches that you really want to control
   - Maybe even having an attribute such as "base PGO on this branch" might=
=20
   be useful/effective (so that when you are doing profiling, the optimizer=
=20
   will place more emphasis on what you think are the important paths)
   - What about when branches are globally correlated, such as:

if (x =3D=3D 1)
 x =3D 0;
if (y =3D=3D 1)
 y =3D 0;
if (x !=3D y)
 do_something()

In the above code, if the first two branches are taken, we know that the=20
third won't be. This is something that the x86 branch predictor will pick=
=20
up on, but single attributes in the language will not be able to address.=
=20
In other words, static branch predictor hints (that refer to a single=20
branch target) only get you so far.

And some more thoughts:

   - What is the guidance between conditional jumps v.s. predicated=20
   instructions (e.g. conditional moves in x86)? I.e. how should a language=
=20
   branch prediction facility influence this? I.e. at what point should you=
=20
   prefer predicated instructions instead of conditional jumps?
   - What about loop unrolling... should compiler hints have an impact here=
=20
   (such as unrolling to fewer than N iterations, or unrolling to fewer=20
   iterations than N/branches within the loop)?
   - What about issuing prefetch instructions (both for data and=20
   instructions)
   - As others have said, in x86 there are no branch prediction=20
   instructions (after Pentium or thereabouts), so any hints would be stati=
c=20
   only

I agree that all of this is architecture specific, and that a high level=20
language feature can be ignored, but I am not sure exactly what compilers=
=20
should do if they are told that something is predictable, i.e. the right=20
choice for one case could be the wrong choice for someone else. Hence the=
=20
recommendation to use PGO (which I also dislike as it tends to overfit for=
=20
the given test case).

Also, in my experience (on x86), the hardware branch prediction facilities=
=20
are *really* good at predicting branches (even if patterns are irregular).=
=20
And branch predictors need to be good these days, as instruction pipelines=
=20
are deep, superscalar execution is everything, and the cost of=20
misprediction is high.

So for me, I tend to not really need language-supported branch prediction,=
=20
and it's only very occasionally where I need to use the built-in hints that=
=20
my compiler supports. In other words, most of the time the compiler and=20
hardware are good enough (it's nothing short of amazing how well loop=20
unrolling works these days), and if not, I can usually remove the cold path=
=20
just by coding differently (i.e. I agree that the programmer has domain=20
knowledge, but this can be leveraged without needing to rely on compiler=20
optimisations or run-time support). The only time I've seen branch=20
prediction really useful is when there is a rarely called branch (i.e. with=
=20
zero branch prediction history), yet when it is called, we don't want to=20
miss.

Going all the way back to the start again, what is the purpose of such a=20
proposal? Is it for speed? If so, that's fine, but it needs to be=20
demonstrated (on multiple architectures), and for sufficiently general use=
=20
cases. Because just saying that we should have more explicit branch=20
prediction hints is one thing, but unless compiler implementors agree that=
=20
this would help, and there's a clear benefit to end-users, I can't see this=
=20
getting much traction. I'd also love to see some input here from a CPU=20
developer. For the record, I would like to see support for this, but I am=
=20
wary of the questions such a proposal raises.

On Sunday, 25 September 2016 16:48:42 UTC+2, mayorg...@gmail.com wrote:
>
> It seems obvious that the g++ flag __builtin_expect is able to improve=20
> performance,=20
> tl,dr of=20
> http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html is=
=20
> This optimized version runs significantly faster (1.95 versus 2.28=20
> seconds) than our version that used __builtin_expect()
>
> So that means some compilers on some archs can take advantage of user=20
> input regarding branch hinting.
>
> IMHO a language devoted for performance should allow to specify this=20
> important kind of hint, and this is generalised to all chips because thes=
e=20
> hints come from the domain knowledge of the programmer. Then every compil=
er=20
> will make it the best as it can to generate the fastest code (not sure=20
> about how it will improve size but performance is important enough), the=
=20
> worst thing it may happen is the compiler ignores the hint and generate=
=20
> regular code, this responsibility is forwarded to the compiler=20
> implementation, but the program will still reflect the programmer's inten=
t,=20
> and this is what this proposal is about, a computer language is the=20
> interface to convert domain knowledge into assembler, and branch hinting=
=20
> belongs to this side, the programmer's side.
>
>
>
> On Sunday, 25 September 2016 15:28:36 UTC+1, dgutson wrote:
>>
>> El 25/9/2016 11:14, "Andrey Semashev" <andrey....@gmail.com> escribi=C3=
=B3:
>> >
>> > On 09/25/16 16:33, dgutson . wrote:
>> >>
>> >> El 25/9/2016 10:16, <mayorg...@gmail.com
>> >> <mailto:mayorg...@gmail.com>> escribi=C3=B3:
>> >>
>> >>>
>> >>> The compiler does not know the application domain, and AFAIK some of
>> >>
>> >> them has set this prediction random. In general I think this applicab=
le
>> >> to any computer language, the programmer should have a mean to hint t=
he
>> >> compiler when sometimes is obvious you=C5=95e programming a corner ca=
se
>> >> branch, if the compiler ignores these hints it will just generate les=
s
>> >> optimized code for a real case execution.
>> >>
>> >> But why a standard attribute? Go to your compiler vendor and ask to
>> >> provide an attribute. Think in portability.
>> >> So my question remains: why an architecture-specific feature should b=
e
>> >> standard, when the language provides the syntax? Please answer.
>> >
>> >
>> > If I may, my answer is the same reason we have the standard in the=20
>> first place - to have a portable tool for that. Yes, we have=20
>> compiler-specific intrinsics now, but the point of standardizing is to=
=20
>> relieve the developers from having to define macros on top of them over =
and=20
>> over again.
>> >
>> > Also, I disagree with you calling it an architecture-specific feature.=
=20
>> Even if an architecture lacks hardware branch prediction hints, like x86=
 or=20
>> IA-64, or even the branch predictor itself (which, I think, is rare thes=
e=20
>> days), the hint can still be used to organize and optimize code. For=20
>> instance, besides code locality, the hint may instruct the compiler to=
=20
>> optimize less frequently executed sections for size rather than speed or=
=20
>> move them to a different section altogether. Such behavior is not=20
>> architecture specific.
>>
>> Please show me exactly how would this arch-nonspecific optimization work=
=20
>> either for speed or size and I will believe you :)
>> I don't see any.
>>
>> >
>> >
>> > --=20
>> > You received this message because you are subscribed to the Google=20
>> Groups "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this group and stop receiving emails from it, send=
=20
>> an email to std-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@isocpp.org.
>> > To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/abeb6c76-63=
dd-5814-bf3f-d5564c8fdfe7%40gmail.com
>> .
>>
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/dae4b638-9959-4bd1-9e02-d2ff4a1ba91a%40isocpp.or=
g.

------=_Part_3398_1705523233.1474815620585
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style=3D"font-family: arial, sans-serif; font-size: s=
mall;">Just to throw some more thoughts out there (this is always a thorny =
topic):</div><div style=3D"font-family: arial, helvetica, sans-serif;"><ul =
style=3D"font-family: arial, sans-serif; font-size: small;"><li>What about =
when the likely branch is not the one that you want to optimize for?</li><l=
i>As others have said, having a probability that is more expressible than j=
ust likely/unlikely might be useful (i.e. 20% likely)</li><li>As others hav=
e said, what about switches, and if-elseif branches? I.e. when it&#39;s a g=
roup of branches that you really want to control</li><li>Maybe even having =
an attribute such as &quot;base PGO on this branch&quot; might be useful/ef=
fective (so that when you are doing profiling, the optimizer will place mor=
e emphasis on what you think are the important paths)</li><li>What about wh=
en branches are globally correlated, such as:</li></ul><div style=3D"font-f=
amily: arial, sans-serif; font-size: small;"><div class=3D"gmail-prettyprin=
t" style=3D"border-width: 1px; border-style: solid; border-color: rgb(187, =
187, 187); background-color: rgb(250, 250, 250); word-wrap: break-word;"><c=
ode class=3D"gmail-prettyprint"><div class=3D"gmail-subprettyprint"><span c=
lass=3D"gmail-styled-by-prettify" style=3D"color: rgb(0, 0, 136);">if</span=
><span class=3D"gmail-styled-by-prettify" style=3D"color: rgb(0, 0, 0);">=
=C2=A0</span><span class=3D"gmail-styled-by-prettify" style=3D"color: rgb(1=
02, 102, 0);">(</span><span class=3D"gmail-styled-by-prettify" style=3D"col=
or: rgb(0, 0, 0);">x=C2=A0</span><span class=3D"gmail-styled-by-prettify" s=
tyle=3D"color: rgb(102, 102, 0);">=3D=3D</span><span class=3D"gmail-styled-=
by-prettify" style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span class=3D"gma=
il-styled-by-prettify" style=3D"color: rgb(0, 102, 102);">1</span><span cla=
ss=3D"gmail-styled-by-prettify" style=3D"color: rgb(102, 102, 0);">)</span>=
<span class=3D"gmail-styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br=
>=C2=A0x=C2=A0</span><span class=3D"gmail-styled-by-prettify" style=3D"colo=
r: rgb(102, 102, 0);">=3D</span><span class=3D"gmail-styled-by-prettify" st=
yle=3D"color: rgb(0, 0, 0);">=C2=A0</span><span class=3D"gmail-styled-by-pr=
ettify" style=3D"color: rgb(0, 102, 102);">0</span><span class=3D"gmail-sty=
led-by-prettify" style=3D"color: rgb(102, 102, 0);">;</span><span class=3D"=
gmail-styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br></span><span c=
lass=3D"gmail-styled-by-prettify" style=3D"color: rgb(0, 0, 136);">if</span=
><span class=3D"gmail-styled-by-prettify" style=3D"color: rgb(0, 0, 0);">=
=C2=A0</span><span class=3D"gmail-styled-by-prettify" style=3D"color: rgb(1=
02, 102, 0);">(</span><span class=3D"gmail-styled-by-prettify" style=3D"col=
or: rgb(0, 0, 0);">y=C2=A0</span><span class=3D"gmail-styled-by-prettify" s=
tyle=3D"color: rgb(102, 102, 0);">=3D=3D</span><span class=3D"gmail-styled-=
by-prettify" style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span class=3D"gma=
il-styled-by-prettify" style=3D"color: rgb(0, 102, 102);">1</span><span cla=
ss=3D"gmail-styled-by-prettify" style=3D"color: rgb(102, 102, 0);">)</span>=
<span class=3D"gmail-styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br=
>=C2=A0y=C2=A0</span><span class=3D"gmail-styled-by-prettify" style=3D"colo=
r: rgb(102, 102, 0);">=3D</span><span class=3D"gmail-styled-by-prettify" st=
yle=3D"color: rgb(0, 0, 0);">=C2=A0</span><font color=3D"#006666"><span cla=
ss=3D"gmail-styled-by-prettify">0</span><span class=3D"gmail-styled-by-pret=
tify" style=3D"color: rgb(102, 102, 0);">;</span></font><span class=3D"gmai=
l-styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br></span><span class=
=3D"gmail-styled-by-prettify" style=3D"color: rgb(0, 0, 136);">if</span><sp=
an class=3D"gmail-styled-by-prettify" style=3D"color: rgb(0, 0, 0);">=C2=A0=
</span><span class=3D"gmail-styled-by-prettify" style=3D"color: rgb(102, 10=
2, 0);">(</span><font color=3D"#000000"><span class=3D"gmail-styled-by-pret=
tify">x=C2=A0</span><span class=3D"gmail-styled-by-prettify" style=3D"color=
: rgb(102, 102, 0);">!=3D</span><span class=3D"gmail-styled-by-prettify">=
=C2=A0y</span></font><span class=3D"gmail-styled-by-prettify" style=3D"colo=
r: rgb(102, 102, 0);">)</span><span class=3D"gmail-styled-by-prettify" styl=
e=3D"color: rgb(0, 0, 0);"><br>=C2=A0do_something</span><span class=3D"gmai=
l-styled-by-prettify" style=3D"color: rgb(102, 102, 0);">()</span><span cla=
ss=3D"gmail-styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br></span><=
font color=3D"#666600"></font></div></code></div><div><br></div>In the abov=
e code, if the first two branches are taken, we know that the third won&#39=
;t be. This is something that the x86 branch predictor will pick up on, but=
 single attributes in the language will not be able to address. In other wo=
rds, static branch predictor hints (that refer to a single branch target) o=
nly get you so far.</div><div style=3D"font-family: arial, sans-serif; font=
-size: small;"><br></div><div style=3D"font-family: arial, sans-serif; font=
-size: small;">And some more thoughts:</div><div><ul><li><font face=3D"aria=
l, sans-serif" size=3D"2">What is the guidance between conditional jumps v.=
s. predicated instructions (e.g. conditional moves in x86)? I.e. how should=
 a language branch prediction facility influence this? I.e. at what point s=
hould you prefer predicated instructions instead of conditional jumps?</fon=
t></li><li><font face=3D"arial, sans-serif" size=3D"2">What about loop unro=
lling... should compiler hints have an impact here (such as unrolling to fe=
wer than N iterations, or unrolling to fewer iterations than N/branches wit=
hin the loop)?</font></li><li><font face=3D"arial, sans-serif" size=3D"2">W=
hat about issuing prefetch instructions (both for data and instructions)</f=
ont></li><li><font face=3D"arial, sans-serif" size=3D"2">As others have sai=
d, in x86 there are no branch prediction instructions (after Pentium or the=
reabouts), so any hints would be static only</font></li></ul><div><font fac=
e=3D"arial, sans-serif" size=3D"2">I agree that all of this is architecture=
 specific, and that a high level language feature can be ignored, but I am =
not sure exactly what compilers should do if they are told that something i=
s predictable, i.e. the right choice for one case could be the wrong choice=
 for someone else. Hence the recommendation to use PGO (which I also dislik=
e as it tends to overfit for the given test case).</font></div><div><font f=
ace=3D"arial, sans-serif" size=3D"2"><br></font></div><div>Also, in my expe=
rience (on x86), the hardware branch prediction facilities are *really* goo=
d at predicting branches (even if patterns are irregular). And branch predi=
ctors need to be good these days, as instruction pipelines are deep, supers=
calar execution is everything, and the cost of misprediction is high.</div>=
</div></div><div style=3D"font-family: arial, helvetica, sans-serif;"><br><=
/div><div style=3D"font-family: arial, helvetica, sans-serif;">So for me, I=
 tend to not really need language-supported branch prediction, and it&#39;s=
 only very occasionally where I need to use the built-in hints that my comp=
iler supports. In other words, most of the time the compiler and hardware a=
re good enough (it&#39;s nothing short of amazing how well loop unrolling w=
orks these days), and if not, I can usually remove the cold path just by co=
ding differently (i.e. I agree that the programmer has domain knowledge, bu=
t this can be leveraged without needing to rely on compiler optimisations o=
r run-time support). The only time I&#39;ve seen branch prediction really u=
seful is when there is a rarely called branch (i.e. with zero branch predic=
tion history), yet when it is called, we don&#39;t want to miss.</div><div =
style=3D"font-family: arial, helvetica, sans-serif;"><br></div><div style=
=3D"font-family: arial, helvetica, sans-serif;">Going all the way back to t=
he start again, what is the purpose of such a proposal? Is it for speed? If=
 so, that&#39;s fine, but it needs to be demonstrated (on multiple architec=
tures), and for sufficiently general use cases. Because just saying that we=
 should have more explicit branch prediction hints is one thing, but unless=
 compiler implementors agree that this would help, and there&#39;s a clear =
benefit to end-users, I can&#39;t see this getting much traction. I&#39;d a=
lso love to see some input here from a CPU developer. For the record, I wou=
ld like to see support for this, but I am wary of the questions such a prop=
osal raises.</div><br>On Sunday, 25 September 2016 16:48:42 UTC+2, mayorg..=
..@gmail.com  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">It seems obvious that the g++ flag __builtin_expect is able to improv=
e performance,=C2=A0<div>tl,dr of <a href=3D"http://blog.man7.org/2012/10/h=
ow-much-do-builtinexpect-likely-and.html" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F=
%2Fblog.man7.org%2F2012%2F10%2Fhow-much-do-builtinexpect-likely-and.html\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHopGQzNCbwNy7n41_tzQtlDcnLvw&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%=
3A%2F%2Fblog.man7.org%2F2012%2F10%2Fhow-much-do-builtinexpect-likely-and.ht=
ml\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHopGQzNCbwNy7n41_tzQtlDcnLvw&#39=
;;return true;">http://blog.man7.org/2012/10/<wbr>how-much-do-builtinexpect=
-<wbr>likely-and.html</a> is=C2=A0<div><span style=3D"color:rgb(51,51,51);f=
ont-family:Georgia,serif;line-height:20.8px">This optimized version runs si=
gnificantly faster (1.95 versus 2.28 seconds) than our version that used=C2=
=A0</span><span style=3D"color:rgb(51,51,51);line-height:20.8px;font-family=
:&#39;Courier New&#39;,Courier,monospace">__builtin_expect()</span><br><br>=
So that means some compilers on some archs can take advantage of user input=
 regarding branch hinting.</div><div><br></div><div>IMHO a language devoted=
 for performance should allow to specify this important kind of hint, and t=
his is generalised to all chips because these hints come from the domain kn=
owledge of the programmer. Then every compiler will make it the best as it =
can to generate the fastest code (not sure about how it will improve size b=
ut performance is important enough), the worst thing it may happen is the c=
ompiler ignores the hint and generate regular code, this responsibility is =
forwarded to the compiler implementation, but the program will still reflec=
t the programmer&#39;s intent, and this is what this proposal is about, a c=
omputer language is the interface to convert domain knowledge into assemble=
r, and branch hinting belongs to this side, the programmer&#39;s side.</div=
><div><br></div><div><br></div><div><br>On Sunday, 25 September 2016 15:28:=
36 UTC+1, dgutson  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"=
ltr"></p>
<p dir=3D"ltr">El 25/9/2016 11:14, &quot;Andrey Semashev&quot; &lt;<a rel=
=3D"nofollow">andrey....@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; On 09/25/16 16:33, dgutson . wrote:<br>
&gt;&gt;<br>
&gt;&gt; El 25/9/2016 10:16, &lt;<a rel=3D"nofollow">mayorg...@gmail.com</a=
><br>
&gt;&gt; &lt;mailto:<a rel=3D"nofollow">mayorg...@gmail.com</a>&gt;&gt; esc=
ribi=C3=B3:<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The compiler does not know the application domain, and AFAIK s=
ome of<br>
&gt;&gt;<br>
&gt;&gt; them has set this prediction random. In general I think this appli=
cable<br>
&gt;&gt; to any computer language, the programmer should have a mean to hin=
t the<br>
&gt;&gt; compiler when sometimes is obvious you=C5=95e programming a corner=
 case<br>
&gt;&gt; branch, if the compiler ignores these hints it will just generate =
less<br>
&gt;&gt; optimized code for a real case execution.<br>
&gt;&gt;<br>
&gt;&gt; But why a standard attribute? Go to your compiler vendor and ask t=
o<br>
&gt;&gt; provide an attribute. Think in portability.<br>
&gt;&gt; So my question remains: why an architecture-specific feature shoul=
d be<br>
&gt;&gt; standard, when the language provides the syntax? Please answer.<br=
>
&gt;<br>
&gt;<br>
&gt; If I may, my answer is the same reason we have the standard in the fir=
st place - to have a portable tool for that. Yes, we have compiler-specific=
 intrinsics now, but the point of standardizing is to relieve the developer=
s from having to define macros on top of them over and over again.<br>
&gt;<br>
&gt; Also, I disagree with you calling it an architecture-specific feature.=
 Even if an architecture lacks hardware branch prediction hints, like x86 o=
r IA-64, or even the branch predictor itself (which, I think, is rare these=
 days), the hint can still be used to organize and optimize code. For insta=
nce, besides code locality, the hint may instruct the compiler to optimize =
less frequently executed sections for size rather than speed or move them t=
o a different section altogether. Such behavior is not architecture specifi=
c.</p>
<p dir=3D"ltr">Please show me exactly how would this arch-nonspecific optim=
ization work either for speed or size and I will believe you :)<br>
I don&#39;t see any.</p>
<p dir=3D"ltr">&gt;<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...@iso=
cpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/abeb6c76-63dd-5814-bf3f-d5564c8f=
dfe7%40gmail.com" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.hr=
ef=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/abeb=
6c76-63dd-5814-bf3f-d5564c8fdfe7%40gmail.com&#39;;return true;" onclick=3D"=
this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/abeb6c76-63dd-5814-bf3f-d5564c8fdfe7%40gmail.com&#39;;return true;">http=
s://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/abeb6c76=
-63dd-5814-<wbr>bf3f-d5564c8fdfe7%40gmail.com</a>.<br></p>
</blockquote></div></div></div></blockquote></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dae4b638-9959-4bd1-9e02-d2ff4a1ba91a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dae4b638-9959-4bd1-9e02-d2ff4a1ba91a=
%40isocpp.org</a>.<br />

------=_Part_3398_1705523233.1474815620585--

------=_Part_3397_1030156195.1474815620585--

.

------=_Part_3436_155595654.1474823750700
Content-Type: multipart/alternative;
 boundary="----=_Part_3437_242701051.1474823750701"

------=_Part_3437_242701051.1474823750701
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Sunday, 25 September 2016 16:00:21 UTC+1, Carl Cook wrote:
>
> Just to throw some more thoughts out there (this is always a thorny topic=
):
>
>    - What about when the likely branch is not the one that you want to=20
>    optimize for?
>
> I understand you mean if the programmer make a mistake qualifying the=20
branch, as a result of a mistake the program would not be optimized well.=
=20
Which is normal, when coding if the programmer makes a mistake in the=20
condition the program would enter the wrong branch resulting in a glitch.=
=20
The programmer is who controls the result and this mechanism would be a=20
mean to allow him to do the task better.


>    - As others have said, having a probability that is more expressible=
=20
>    than just likely/unlikely might be useful (i.e. 20% likely)
>
> At every decision point the processor has only two choices either load=20
branch1 instructions or branch2 into the pipeline, I cannot make sense of=
=20
such level of qualification, there are only 2 real choices for the=20
processor, and the real % of likeliness will determine which choice are the=
=20
most frequently executed, if the programmer sets one branch is more likely=
=20
than the other the processor should just load the indicated branch, unless=
=20
other lower level indicators suggest the opposite, the net result should be=
=20
fastest binaries for the compiled platform.
=20

>
>    - As others have said, what about switches, and if-elseif branches?=20
>    I.e. when it's a group of branches that you really want to control
>
> the hint is applicable everytime the processor decides which instruction=
=20
are to be loaded in the execution pipeline, so in a multibranch if like

if (true|false) {
}
else if (true|false) {
}
else {
}

is equivalent to

if (true|false) {
}
else {
  if (true|false) {
  }
  else {
  }
}
=20
switch as a list of branches could be qualified as well, an also the=20
operator ?:=20


>    - Maybe even having an attribute such as "base PGO on this branch"=20
>    might be useful/effective (so that when you are doing profiling, the=
=20
>    optimizer will place more emphasis on what you think are the important=
=20
>    paths)
>    - What about when branches are globally correlated, such as:
>
> if (x =3D=3D 1)
>  x =3D 0;
> if (y =3D=3D 1)
>  y =3D 0;
> if (x !=3D y)
>  do_something()
>
> In the above code, if the first two branches are taken, we know that the=
=20
> third won't be. This is something that the x86 branch predictor will pick=
=20
> up on, but single attributes in the language will not be able to address.=
=20
> In other words, static branch predictor hints (that refer to a single=20
> branch target) only get you so far.
>
>
branches labeled at 'origin' can be tracked by the compiler and on every=20
decision point load the right branch based on how well this tracking is=20
performed.
=20

> And some more thoughts:
>
>    - What is the guidance between conditional jumps v.s. predicated=20
>    instructions (e.g. conditional moves in x86)? I.e. how should a langua=
ge=20
>    branch prediction facility influence this? I.e. at what point should y=
ou=20
>    prefer predicated instructions instead of conditional jumps?
>
>
>    - What about loop unrolling... should compiler hints have an impact=20
>    here (such as unrolling to fewer than N iterations, or unrolling to fe=
wer=20
>    iterations than N/branches within the loop)?
>
>
>    - What about issuing prefetch instructions (both for data and=20
>    instructions)
>    - As others have said, in x86 there are no branch prediction=20
>    instructions (after Pentium or thereabouts), so any hints would be sta=
tic=20
>    only
>
> I think this assembly logic belong to compiler manufacturers rather than =
a=20
language spec. Specifying likeliness in the program means the compiler has=
=20
more data as input to generate better assembly.
Once a feature is defined in the language spec compiler manufacturers will=
=20
do their best to translate this aditional information to assembly, the=20
point is whether the C++ standard should allow programmers to qualify the=
=20
likeliness of their branches or not.
It should because the programmer knows more of the application domain than=
=20
the compiler, which only knows arch details, then the compiler should take=
=20
all the information available and decide what assembly must be generated.
=20

> I agree that all of this is architecture specific, and that a high level=
=20
> language feature can be ignored, but I am not sure exactly what compilers=
=20
> should do if they are told that something is predictable, i.e. the right=
=20
> choice for one case could be the wrong choice for someone else. Hence the=
=20
> recommendation to use PGO (which I also dislike as it tends to overfit fo=
r=20
> the given test case).
>
> PGO requires additional effort and I have never seen anybody doing this i=
n=20
real life, but it can be useful to warn which branches the programmer=20
failed or not to qualify, i.e. PGO as unit test for branch prediction
=20

> Also, in my experience (on x86), the hardware branch prediction facilitie=
s=20
> are *really* good at predicting branches (even if patterns are irregular)=
..=20
> And branch predictors need to be good these days, as instruction pipeline=
s=20
> are deep, superscalar execution is everything, and the cost of=20
> misprediction is high.
>
> That=C5=9B why there is a need to be able to specify this at language lev=
el=20
when the programmers knows the if they are coding is an unlikely corner=20
case, even I think you could save the underlying layers of algorithms=20
(either sw of hw) watts : )

=20

> So for me, I tend to not really need language-supported branch prediction=
,=20
> and it's only very occasionally where I need to use the built-in hints th=
at=20
> my compiler supports. In other words, most of the time the compiler and=
=20
> hardware are good enough (it's nothing short of amazing how well loop=20
> unrolling works these days), and if not, I can usually remove the cold pa=
th=20
> just by coding differently (i.e. I agree that the programmer has domain=
=20
> knowledge, but this can be leveraged without needing to rely on compiler=
=20
> optimisations or run-time support). The only time I've seen branch=20
> prediction really useful is when there is a rarely called branch (i.e. wi=
th=20
> zero branch prediction history), yet when it is called, we don't want to=
=20
> miss.
>
> Going all the way back to the start again, what is the purpose of such a=
=20
> proposal? Is it for speed? If so, that's fine, but it needs to be=20
> demonstrated (on multiple architectures), and for sufficiently general us=
e=20
> cases. Because just saying that we should have more explicit branch=20
> prediction hints is one thing, but unless compiler implementors agree tha=
t=20
> this would help, and there's a clear benefit to end-users, I can't see th=
is=20
> getting much traction. I'd also love to see some input here from a CPU=20
> developer. For the record, I would like to see support for this, but I am=
=20
> wary of the questions such a proposal raises.
>
> On Sunday, 25 September 2016 16:48:42 UTC+2, mayorg...@gmail.com wrote:
>>
>> It seems obvious that the g++ flag __builtin_expect is able to improve=
=20
>> performance,=20
>> tl,dr of=20
>> http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html=
=20
>> is=20
>> This optimized version runs significantly faster (1.95 versus 2.28=20
>> seconds) than our version that used __builtin_expect()
>>
>> So that means some compilers on some archs can take advantage of user=20
>> input regarding branch hinting.
>>
>> IMHO a language devoted for performance should allow to specify this=20
>> important kind of hint, and this is generalised to all chips because the=
se=20
>> hints come from the domain knowledge of the programmer. Then every compi=
ler=20
>> will make it the best as it can to generate the fastest code (not sure=
=20
>> about how it will improve size but performance is important enough), the=
=20
>> worst thing it may happen is the compiler ignores the hint and generate=
=20
>> regular code, this responsibility is forwarded to the compiler=20
>> implementation, but the program will still reflect the programmer's inte=
nt,=20
>> and this is what this proposal is about, a computer language is the=20
>> interface to convert domain knowledge into assembler, and branch hinting=
=20
>> belongs to this side, the programmer's side.
>>
>>
>>
>> On Sunday, 25 September 2016 15:28:36 UTC+1, dgutson wrote:
>>>
>>> El 25/9/2016 11:14, "Andrey Semashev" <andrey....@gmail.com> escribi=C3=
=B3:
>>> >
>>> > On 09/25/16 16:33, dgutson . wrote:
>>> >>
>>> >> El 25/9/2016 10:16, <mayorg...@gmail.com
>>> >> <mailto:mayorg...@gmail.com>> escribi=C3=B3:
>>> >>
>>> >>>
>>> >>> The compiler does not know the application domain, and AFAIK some o=
f
>>> >>
>>> >> them has set this prediction random. In general I think this=20
>>> applicable
>>> >> to any computer language, the programmer should have a mean to hint=
=20
>>> the
>>> >> compiler when sometimes is obvious you=C5=95e programming a corner c=
ase
>>> >> branch, if the compiler ignores these hints it will just generate le=
ss
>>> >> optimized code for a real case execution.
>>> >>
>>> >> But why a standard attribute? Go to your compiler vendor and ask to
>>> >> provide an attribute. Think in portability.
>>> >> So my question remains: why an architecture-specific feature should =
be
>>> >> standard, when the language provides the syntax? Please answer.
>>> >
>>> >
>>> > If I may, my answer is the same reason we have the standard in the=20
>>> first place - to have a portable tool for that. Yes, we have=20
>>> compiler-specific intrinsics now, but the point of standardizing is to=
=20
>>> relieve the developers from having to define macros on top of them over=
 and=20
>>> over again.
>>> >
>>> > Also, I disagree with you calling it an architecture-specific feature=
..=20
>>> Even if an architecture lacks hardware branch prediction hints, like x8=
6 or=20
>>> IA-64, or even the branch predictor itself (which, I think, is rare the=
se=20
>>> days), the hint can still be used to organize and optimize code. For=20
>>> instance, besides code locality, the hint may instruct the compiler to=
=20
>>> optimize less frequently executed sections for size rather than speed o=
r=20
>>> move them to a different section altogether. Such behavior is not=20
>>> architecture specific.
>>>
>>> Please show me exactly how would this arch-nonspecific optimization wor=
k=20
>>> either for speed or size and I will believe you :)
>>> I don't see any.
>>>
>>> >
>>> >
>>> > --=20
>>> > You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> > To unsubscribe from this group and stop receiving emails from it, sen=
d=20
>>> an email to std-proposal...@isocpp.org.
>>> > To post to this group, send email to std-pr...@isocpp.org.
>>> > To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/abeb6c76-6=
3dd-5814-bf3f-d5564c8fdfe7%40gmail.com
>>> .
>>>
>>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/129f364a-072b-4281-8e11-a6870e21f69f%40isocpp.or=
g.

------=_Part_3437_242701051.1474823750701
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, 25 September 2016 16:00:21 UTC+1, Carl =
Cook  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div style=3D"font-family:arial,sans-serif;font-size:small">Just to throw so=
me more thoughts out there (this is always a thorny topic):</div><div style=
=3D"font-family:arial,helvetica,sans-serif"><ul style=3D"font-family:arial,=
sans-serif;font-size:small"><li>What about when the likely branch is not th=
e one that you want to optimize for?</li></ul></div></div></blockquote><div=
>I understand you mean if the programmer make a mistake qualifying the bran=
ch, as a result of a mistake the program would not be optimized well. Which=
 is normal, when coding if the programmer makes a mistake in the condition =
the program would enter the wrong branch resulting in a glitch. The program=
mer is who controls the result and this mechanism would be a mean to allow =
him to do the task better.</div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div style=3D"font-family:arial,helvetica=
,sans-serif"><ul style=3D"font-family:arial,sans-serif;font-size:small"><li=
>As others have said, having a probability that is more expressible than ju=
st likely/unlikely might be useful (i.e. 20% likely)</li></ul></div></div><=
/blockquote><div>At every decision point the processor has only two choices=
 either load branch1 instructions or branch2 into the pipeline, I cannot ma=
ke sense of such level of qualification, there are only 2 real choices for =
the processor, and the real % of likeliness will determine which choice are=
 the most frequently executed, if the programmer sets one branch is more li=
kely than the other the processor should just load the indicated branch, un=
less other lower level indicators suggest the opposite, the net result shou=
ld be fastest binaries for the compiled platform.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div style=3D"fo=
nt-family:arial,helvetica,sans-serif"><ul style=3D"font-family:arial,sans-s=
erif;font-size:small"><li>As others have said, what about switches, and if-=
elseif branches? I.e. when it&#39;s a group of branches that you really wan=
t to control</li></ul></div></div></blockquote><div>the hint is applicable =
everytime the processor decides which instruction are to be loaded in the e=
xecution pipeline, so in a multibranch if like</div><div><br></div><div>if =
(true|false) {</div><div>}</div><div>else if (true|false) {</div><div>}</di=
v><div>else {</div><div>}</div><div><br></div><div>is equivalent to</div><d=
iv><br></div><div><div>if (true|false) {</div><div>}</div><div>else {</div>=
<div>=C2=A0 if (true|false) {</div><div>=C2=A0 }</div><div><div>=C2=A0 else=
 {</div><div>=C2=A0 }</div></div><div>}</div></div><div>=C2=A0</div><div>sw=
itch as a list of branches could be qualified as well, an also the operator=
 ?:=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif"><ul =
style=3D"font-family:arial,sans-serif;font-size:small"><li>Maybe even havin=
g an attribute such as &quot;base PGO on this branch&quot; might be useful/=
effective (so that when you are doing profiling, the optimizer will place m=
ore emphasis on what you think are the important paths)</li><li>What about =
when branches are globally correlated, such as:</li></ul><div style=3D"font=
-family:arial,sans-serif;font-size:small"><div style=3D"border-width:1px;bo=
rder-style:solid;border-color:rgb(187,187,187);background-color:rgb(250,250=
,250);word-wrap:break-word"><code><div><span style=3D"color:rgb(0,0,136)">i=
f</span><span style=3D"color:rgb(0,0,0)">=C2=A0</span><span style=3D"color:=
rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">x=C2=A0</span><spa=
n style=3D"color:rgb(102,102,0)">=3D=3D</span><span style=3D"color:rgb(0,0,=
0)">=C2=A0</span><span style=3D"color:rgb(0,102,102)">1</span><span style=
=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"><br>=C2=
=A0x=C2=A0</span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=
=3D"color:rgb(0,0,0)">=C2=A0</span><span style=3D"color:rgb(0,102,102)">0</=
span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(=
0,0,0)"><br></span><span style=3D"color:rgb(0,0,136)">if</span><span style=
=3D"color:rgb(0,0,0)">=C2=A0</span><span style=3D"color:rgb(102,102,0)">(</=
span><span style=3D"color:rgb(0,0,0)">y=C2=A0</span><span style=3D"color:rg=
b(102,102,0)">=3D=3D</span><span style=3D"color:rgb(0,0,0)">=C2=A0</span><s=
pan style=3D"color:rgb(0,102,102)">1</span><span style=3D"color:rgb(102,102=
,0)">)</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0y=C2=A0</span><span=
 style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)">=
=C2=A0</span><font color=3D"#006666"><span>0</span><span style=3D"color:rgb=
(102,102,0)">;</span></font><span style=3D"color:rgb(0,0,0)"><br></span><sp=
an style=3D"color:rgb(0,0,136)">if</span><span style=3D"color:rgb(0,0,0)">=
=C2=A0</span><span style=3D"color:rgb(102,102,0)">(</span><font color=3D"#0=
00000"><span>x=C2=A0</span><span style=3D"color:rgb(102,102,0)">!=3D</span>=
<span>=C2=A0y</span></font><span style=3D"color:rgb(102,102,0)">)</span><sp=
an style=3D"color:rgb(0,0,0)"><br>=C2=A0do_something</span><span style=3D"c=
olor:rgb(102,102,0)">()</span><span style=3D"color:rgb(0,0,0)"><br></span><=
font color=3D"#666600"></font></div></code></div><div><br></div>In the abov=
e code, if the first two branches are taken, we know that the third won&#39=
;t be. This is something that the x86 branch predictor will pick up on, but=
 single attributes in the language will not be able to address. In other wo=
rds, static branch predictor hints (that refer to a single branch target) o=
nly get you so far.</div><div style=3D"font-family:arial,sans-serif;font-si=
ze:small"><br></div></div></div></blockquote><div><br></div><div>branches l=
abeled at &#39;origin&#39; can be tracked by the compiler and on every deci=
sion point load the right branch based on how well this tracking is perform=
ed.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif"><div sty=
le=3D"font-family:arial,sans-serif;font-size:small"></div><div style=3D"fon=
t-family:arial,sans-serif;font-size:small">And some more thoughts:</div><di=
v><ul><li><font face=3D"arial, sans-serif" size=3D"2">What is the guidance =
between conditional jumps v.s. predicated instructions (e.g. conditional mo=
ves in x86)? I.e. how should a language branch prediction facility influenc=
e this? I.e. at what point should you prefer predicated instructions instea=
d of conditional jumps?</font></li></ul></div></div></div></blockquote><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div style=3D"fon=
t-family:arial,helvetica,sans-serif"><div><ul><li><font face=3D"arial, sans=
-serif" size=3D"2">What about loop unrolling... should compiler hints have =
an impact here (such as unrolling to fewer than N iterations, or unrolling =
to fewer iterations than N/branches within the loop)?</font></li></ul></div=
></div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif"><div><ul=
><li><font face=3D"arial, sans-serif" size=3D"2">What about issuing prefetc=
h instructions (both for data and instructions)</font></li><li><font face=
=3D"arial, sans-serif" size=3D"2">As others have said, in x86 there are no =
branch prediction instructions (after Pentium or thereabouts), so any hints=
 would be static only</font></li></ul></div></div></div></blockquote><div>I=
 think this assembly logic belong to compiler manufacturers rather than a l=
anguage spec. Specifying likeliness in the program means the compiler has m=
ore data as input to generate better assembly.<br></div><div>Once a feature=
 is defined in the language spec compiler manufacturers will do their best =
to translate this aditional information to assembly, the point is whether t=
he C++ standard should allow programmers to qualify the likeliness of their=
 branches or not.</div><div>It should because the programmer knows more of =
the application domain than the compiler, which only knows arch details, th=
en the compiler should take all the information available and decide what a=
ssembly must be generated.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div style=3D"font-family:arial,helveti=
ca,sans-serif"><div><div><font face=3D"arial, sans-serif" size=3D"2">I agre=
e that all of this is architecture specific, and that a high level language=
 feature can be ignored, but I am not sure exactly what compilers should do=
 if they are told that something is predictable, i.e. the right choice for =
one case could be the wrong choice for someone else. Hence the recommendati=
on to use PGO (which I also dislike as it tends to overfit for the given te=
st case).</font></div><div><font face=3D"arial, sans-serif" size=3D"2"><br>=
</font></div></div></div></div></blockquote><div>PGO requires additional ef=
fort and I have never seen anybody doing this in real life, but it can be u=
seful to warn which branches the programmer failed or not to qualify, i.e. =
PGO as unit test for branch prediction</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div style=3D"font-family:a=
rial,helvetica,sans-serif"><div><div><font face=3D"arial, sans-serif" size=
=3D"2"></font></div><div>Also, in my experience (on x86), the hardware bran=
ch prediction facilities are *really* good at predicting branches (even if =
patterns are irregular). And branch predictors need to be good these days, =
as instruction pipelines are deep, superscalar execution is everything, and=
 the cost of misprediction is high.</div></div></div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif"><br></div></div></blockquote><div>That=C5=
=9B why there is a need to be able to specify this at language level when t=
he programmers knows the if they are coding is an unlikely corner case, eve=
n I think you could save the underlying layers of algorithms (either sw of =
hw) watts : )</div><div><br></div><div>=C2=A0<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div style=3D"font-family:arial,h=
elvetica,sans-serif"></div><div style=3D"font-family:arial,helvetica,sans-s=
erif">So for me, I tend to not really need language-supported branch predic=
tion, and it&#39;s only very occasionally where I need to use the built-in =
hints that my compiler supports. In other words, most of the time the compi=
ler and hardware are good enough (it&#39;s nothing short of amazing how wel=
l loop unrolling works these days), and if not, I can usually remove the co=
ld path just by coding differently (i.e. I agree that the programmer has do=
main knowledge, but this can be leveraged without needing to rely on compil=
er optimisations or run-time support). The only time I&#39;ve seen branch p=
rediction really useful is when there is a rarely called branch (i.e. with =
zero branch prediction history), yet when it is called, we don&#39;t want t=
o miss.</div><div style=3D"font-family:arial,helvetica,sans-serif"><br></di=
v><div style=3D"font-family:arial,helvetica,sans-serif">Going all the way b=
ack to the start again, what is the purpose of such a proposal? Is it for s=
peed? If so, that&#39;s fine, but it needs to be demonstrated (on multiple =
architectures), and for sufficiently general use cases. Because just saying=
 that we should have more explicit branch prediction hints is one thing, bu=
t unless compiler implementors agree that this would help, and there&#39;s =
a clear benefit to end-users, I can&#39;t see this getting much traction. I=
&#39;d also love to see some input here from a CPU developer. For the recor=
d, I would like to see support for this, but I am wary of the questions suc=
h a proposal raises.</div><br>On Sunday, 25 September 2016 16:48:42 UTC+2, =
<a>mayorg...@gmail.com</a>  wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">It seems obvious that the g++ flag __builtin_expect is ab=
le to improve performance,=C2=A0<div>tl,dr of <a href=3D"http://blog.man7.o=
rg/2012/10/how-much-do-builtinexpect-likely-and.html" rel=3D"nofollow" targ=
et=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fblog.man7.org%2F2012%2F10%2Fhow-much-do-builtinexpect-likely=
-and.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHopGQzNCbwNy7n41_tzQtlDcn=
Lvw&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/ur=
l?q\x3dhttp%3A%2F%2Fblog.man7.org%2F2012%2F10%2Fhow-much-do-builtinexpect-l=
ikely-and.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHopGQzNCbwNy7n41_tzQ=
tlDcnLvw&#39;;return true;">http://blog.man7.org/2012/10/<wbr>how-much-do-b=
uiltinexpect-<wbr>likely-and.html</a> is=C2=A0<div><span style=3D"color:rgb=
(51,51,51);font-family:Georgia,serif;line-height:20.8px">This optimized ver=
sion runs significantly faster (1.95 versus 2.28 seconds) than our version =
that used=C2=A0</span><span style=3D"color:rgb(51,51,51);line-height:20.8px=
;font-family:&#39;Courier New&#39;,Courier,monospace">__builtin_expect()</s=
pan><br><br>So that means some compilers on some archs can take advantage o=
f user input regarding branch hinting.</div><div><br></div><div>IMHO a lang=
uage devoted for performance should allow to specify this important kind of=
 hint, and this is generalised to all chips because these hints come from t=
he domain knowledge of the programmer. Then every compiler will make it the=
 best as it can to generate the fastest code (not sure about how it will im=
prove size but performance is important enough), the worst thing it may hap=
pen is the compiler ignores the hint and generate regular code, this respon=
sibility is forwarded to the compiler implementation, but the program will =
still reflect the programmer&#39;s intent, and this is what this proposal i=
s about, a computer language is the interface to convert domain knowledge i=
nto assembler, and branch hinting belongs to this side, the programmer&#39;=
s side.</div><div><br></div><div><br></div><div><br>On Sunday, 25 September=
 2016 15:28:36 UTC+1, dgutson  wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 11:14, &quot;Andrey Semashev&quot; &lt;<a rel=
=3D"nofollow">andrey....@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; On 09/25/16 16:33, dgutson . wrote:<br>
&gt;&gt;<br>
&gt;&gt; El 25/9/2016 10:16, &lt;<a rel=3D"nofollow">mayorg...@gmail.com</a=
><br>
&gt;&gt; &lt;mailto:<a rel=3D"nofollow">mayorg...@gmail.com</a>&gt;&gt; esc=
ribi=C3=B3:<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The compiler does not know the application domain, and AFAIK s=
ome of<br>
&gt;&gt;<br>
&gt;&gt; them has set this prediction random. In general I think this appli=
cable<br>
&gt;&gt; to any computer language, the programmer should have a mean to hin=
t the<br>
&gt;&gt; compiler when sometimes is obvious you=C5=95e programming a corner=
 case<br>
&gt;&gt; branch, if the compiler ignores these hints it will just generate =
less<br>
&gt;&gt; optimized code for a real case execution.<br>
&gt;&gt;<br>
&gt;&gt; But why a standard attribute? Go to your compiler vendor and ask t=
o<br>
&gt;&gt; provide an attribute. Think in portability.<br>
&gt;&gt; So my question remains: why an architecture-specific feature shoul=
d be<br>
&gt;&gt; standard, when the language provides the syntax? Please answer.<br=
>
&gt;<br>
&gt;<br>
&gt; If I may, my answer is the same reason we have the standard in the fir=
st place - to have a portable tool for that. Yes, we have compiler-specific=
 intrinsics now, but the point of standardizing is to relieve the developer=
s from having to define macros on top of them over and over again.<br>
&gt;<br>
&gt; Also, I disagree with you calling it an architecture-specific feature.=
 Even if an architecture lacks hardware branch prediction hints, like x86 o=
r IA-64, or even the branch predictor itself (which, I think, is rare these=
 days), the hint can still be used to organize and optimize code. For insta=
nce, besides code locality, the hint may instruct the compiler to optimize =
less frequently executed sections for size rather than speed or move them t=
o a different section altogether. Such behavior is not architecture specifi=
c.</p>
<p dir=3D"ltr">Please show me exactly how would this arch-nonspecific optim=
ization work either for speed or size and I will believe you :)<br>
I don&#39;t see any.</p>
<p dir=3D"ltr">&gt;<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...@iso=
cpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/abeb6c76-63dd-5814-bf3f-d5564c8f=
dfe7%40gmail.com" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.hr=
ef=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/abeb=
6c76-63dd-5814-bf3f-d5564c8fdfe7%40gmail.com&#39;;return true;" onclick=3D"=
this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/abeb6c76-63dd-5814-bf3f-d5564c8fdfe7%40gmail.com&#39;;return true;">http=
s://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/abeb6c76=
-63dd-5814-<wbr>bf3f-d5564c8fdfe7%40gmail.com</a>.<br></p>
</blockquote></div></div></div></blockquote></div></blockquote></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/129f364a-072b-4281-8e11-a6870e21f69f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/129f364a-072b-4281-8e11-a6870e21f69f=
%40isocpp.org</a>.<br />

------=_Part_3437_242701051.1474823750701--

------=_Part_3436_155595654.1474823750700--

.

--089e0122efe011e37e053d58b292
Content-Type: text/plain; charset=UTF-8

On Sun, Sep 25, 2016 at 6:15 PM, <mayorga.geek@gmail.com> wrote:

>
> I think this assembly logic belong to compiler manufacturers rather than a
> language spec.
>


Just to play devil's advocate, asking for branch probability annotation
might have a 'slippery slope' effect, where adding that raises a lot of
follow-up questions, like those to which you were responding here -
possibly more than it answers. If we can have one simple thing that you
think applies to the language generally, then why not all the others that
it suggests?

(this is not to say 'slippery slope' is always or usually a valid
rhetorical target, just provoke more debate ;-)

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE4TrMuDRA%2BnrSUt4W6NdoTCRZ%2Bvu-qNit5vyrMrUMjfQ%40mail.gmail.com.

--089e0122efe011e37e053d58b292
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Sep 25, 2016 at 6:15 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:mayor=
ga.geek@gmail.com" target=3D"_blank">mayorga.geek@gmail.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div dir=3D=
"ltr">I think this assembly logic belong to compiler manufacturers rather t=
han a language spec.</div></blockquote><div><br>=C2=A0<br></div><div>Just t=
o play devil&#39;s advocate, asking for branch probability annotation might=
 have a &#39;slippery slope&#39; effect, where adding that raises a lot of =
follow-up questions, like those to which you were responding here - possibl=
y more than it answers. If we can have one simple thing that you think appl=
ies to the language generally, then why not all the others that it suggests=
?<br><br></div><div>(this is not to say &#39;slippery slope&#39; is always =
or usually a valid rhetorical target, just provoke more debate ;-)<br><br><=
/div></div></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhE4TrMuDRA%2BnrSUt4W6NdoTCRZ%2B=
vu-qNit5vyrMrUMjfQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE4TrMu=
DRA%2BnrSUt4W6NdoTCRZ%2Bvu-qNit5vyrMrUMjfQ%40mail.gmail.com</a>.<br />

--089e0122efe011e37e053d58b292--

.

On domingo, 25 de setembro de 2016 03:11:38 PDT mayorga.geek@gmail.com wrote:
> As an example it would be applicable to the singleton pattern, something
> like:
>
> T* singleton::get_instance() {
>    if (p==0) unlikely {
>       p = new singleton();
>    }
>    return p;
> }

Please don't make it a keyword of if or other constructs. The GCC built-in can
be used in other statements too, mainly the ternay operator, but even outside
too. Real examples:

    readBuffer += Q_LIKELY(codec) ? codec->toUnicode(buf, bytesRead,
&readConverterState)
                                  : QString::fromLatin1(buf, bytesRead);

    return Q_LIKELY(qMetaTypeGuiHelper) ? qMetaTypeGuiHelper[type -
QMetaType::FirstGuiType].size : 0;

    if (CanBeSmall)
        return Q_LIKELY(b);
    return Q_UNLIKELY(b);

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2863106.bDlAIeQjvp%40tjmaciei-mobl1.

.

On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:
> Everything involving a branch: if, while, for, switch, ?. Please when
> proposing these sort of things, keep in mind that the world is not only
> x86. There are other archs that don't have branch predictors. That's why an
> (ignorable) attribute is what should be, if at ever standarized.

When you say "there are other archs that don't" (besides x86), you mean "most
archs do, but there are a couple of processor SKUs that don't". There are
modern x86 that don't have pipelining or branch prediction (Quark MCUs) and
most modern architectures do have that (ARM, MIPS, Sparc, POWER).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjmaciei-mobl1.

.

--94eb2c05aacaba98d3053d59ed93
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 25/9/2016 15:34, "Thiago Macieira" <thiago@macieira.org> escribi=C3=B3:
>
> On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:
> > Everything involving a branch: if, while, for, switch, ?. Please when
> > proposing these sort of things, keep in mind that the world is not only
> > x86. There are other archs that don't have branch predictors. That's
why an
> > (ignorable) attribute is what should be, if at ever standarized.
>
> When you say "there are other archs that don't" (besides x86), you mean
"most
> archs do, but there are a couple of processor SKUs that don't". There are
> modern x86 that don't have pipelining or branch prediction (Quark MCUs)
and
> most modern architectures do have that (ARM, MIPS, Sparc, POWER).

This would lead to a sterile discussion I'm not interested to enter which
is at the edge of personal knowledge.
Small IoT processors, or even just saying "ARM" is missing too much
information, since subfamilies differ too much (A, R, M, etc.).

Sorry guys I'm leaving this discussion. It's pointless for me to keep
participating.
If there's a paper I will read it.

   Daniel

>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> 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.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2T=
nsQj%40tjmaciei-mobl1
..

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-1ZG7s2pW9YUXFqYo8Xr%3DRAzrooGHp3dTu8HpBrj=
oyCOw%40mail.gmail.com.

--94eb2c05aacaba98d3053d59ed93
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 15:34, &quot;Thiago Macieira&quot; &lt;<a href=
=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>&gt; escribi=C3=B3:<=
br>
&gt;<br>
&gt; On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:<br>
&gt; &gt; Everything involving a branch: if, while, for, switch, ?. Please =
when<br>
&gt; &gt; proposing these sort of things, keep in mind that the world is no=
t only<br>
&gt; &gt; x86. There are other archs that don&#39;t have branch predictors.=
 That&#39;s why an<br>
&gt; &gt; (ignorable) attribute is what should be, if at ever standarized.<=
br>
&gt;<br>
&gt; When you say &quot;there are other archs that don&#39;t&quot; (besides=
 x86), you mean &quot;most<br>
&gt; archs do, but there are a couple of processor SKUs that don&#39;t&quot=
;. There are<br>
&gt; modern x86 that don&#39;t have pipelining or branch prediction (Quark =
MCUs) and<br>
&gt; most modern architectures do have that (ARM, MIPS, Sparc, POWER).</p>
<p dir=3D"ltr">This would lead to a sterile discussion I&#39;m not interest=
ed to enter which is at the edge of personal knowledge.<br>
Small IoT processors, or even just saying &quot;ARM&quot; is missing too mu=
ch information, since subfamilies differ too much (A, R, M, etc.).</p>
<p dir=3D"ltr">Sorry guys I&#39;m leaving this discussion. It&#39;s pointle=
ss for me to keep participating.<br>
If there&#39;s a paper I will read it.</p>
<p dir=3D"ltr">=C2=A0=C2=A0 Daniel </p>
<p dir=3D"ltr">&gt;<br>
&gt; --<br>
&gt; Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info">macieir=
a.info</a> - thiago (AT) <a href=3D"http://kde.org">kde.org</a><br>
&gt; =C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<=
br>
&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjmaciei-mo=
bl1">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.D=
cAR2TnsQj%40tjmaciei-mobl1</a>.<br></p>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG7s2pW9YUXFqYo8Xr%3DRAzrooGH=
p3dTu8HpBrjoyCOw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG7s2pW=
9YUXFqYo8Xr%3DRAzrooGHp3dTu8HpBrjoyCOw%40mail.gmail.com</a>.<br />

--94eb2c05aacaba98d3053d59ed93--

.

--089e0122829cf4d9af053d5a01eb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Maybe it is best to keep this discussion within SG14 for now (especially
considering there is already at least one proposal for branch prediction
within that group at present).


On 25 September 2016 at 21:22, dgutson . <danielgutson@gmail.com> wrote:

> El 25/9/2016 15:34, "Thiago Macieira" <thiago@macieira.org> escribi=C3=B3=
:
> >
> > On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:
> > > Everything involving a branch: if, while, for, switch, ?. Please when
> > > proposing these sort of things, keep in mind that the world is not on=
ly
> > > x86. There are other archs that don't have branch predictors. That's
> why an
> > > (ignorable) attribute is what should be, if at ever standarized.
> >
> > When you say "there are other archs that don't" (besides x86), you mean
> "most
> > archs do, but there are a couple of processor SKUs that don't". There a=
re
> > modern x86 that don't have pipelining or branch prediction (Quark MCUs)
> and
> > most modern architectures do have that (ARM, MIPS, Sparc, POWER).
>
> This would lead to a sterile discussion I'm not interested to enter which
> is at the edge of personal knowledge.
> Small IoT processors, or even just saying "ARM" is missing too much
> information, since subfamilies differ too much (A, R, M, etc.).
>
> Sorry guys I'm leaving this discussion. It's pointless for me to keep
> participating.
> If there's a paper I will read it.
>
>    Daniel
>
> >
> > --
> > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> >    Software Architect - Intel Open Source Technology Center
> >
> > --
> > 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.
> > To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjmaciei-mobl1.
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG7s2pW9YUXFqYo8Xr%
> 3DRAzrooGHp3dTu8HpBrjoyCOw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG7=
s2pW9YUXFqYo8Xr%3DRAzrooGHp3dTu8HpBrjoyCOw%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAGa0LWvbj98GLkG%3D4ZAo06EQCkYPq9XK420FQsFh5e2Mo=
gWpYg%40mail.gmail.com.

--089e0122829cf4d9af053d5a01eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Maybe it is best to keep this discussion within SG14 for n=
ow (especially considering there is already at least one proposal for branc=
h prediction within that group at present).<div><br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On 25 September 2016 at 21:=
22, dgutson . <span dir=3D"ltr">&lt;<a href=3D"mailto:danielgutson@gmail.co=
m" target=3D"_blank">danielgutson@gmail.com</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><span class=3D""><p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 15:34, &quot;Thiago Macieira&quot; &lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t; escribi=C3=B3:<br>
&gt;<br>
&gt; On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:<br>
&gt; &gt; Everything involving a branch: if, while, for, switch, ?. Please =
when<br>
&gt; &gt; proposing these sort of things, keep in mind that the world is no=
t only<br>
&gt; &gt; x86. There are other archs that don&#39;t have branch predictors.=
 That&#39;s why an<br>
&gt; &gt; (ignorable) attribute is what should be, if at ever standarized.<=
br>
&gt;<br>
&gt; When you say &quot;there are other archs that don&#39;t&quot; (besides=
 x86), you mean &quot;most<br>
&gt; archs do, but there are a couple of processor SKUs that don&#39;t&quot=
;. There are<br>
&gt; modern x86 that don&#39;t have pipelining or branch prediction (Quark =
MCUs) and<br>
&gt; most modern architectures do have that (ARM, MIPS, Sparc, POWER).</p>
</span><p dir=3D"ltr">This would lead to a sterile discussion I&#39;m not i=
nterested to enter which is at the edge of personal knowledge.<br>
Small IoT processors, or even just saying &quot;ARM&quot; is missing too mu=
ch information, since subfamilies differ too much (A, R, M, etc.).</p>
<p dir=3D"ltr">Sorry guys I&#39;m leaving this discussion. It&#39;s pointle=
ss for me to keep participating.<br>
If there&#39;s a paper I will read it.</p>
<p dir=3D"ltr">=C2=A0=C2=A0 Daniel </p><span class=3D"">
<p dir=3D"ltr">&gt;<br>
&gt; --<br>
&gt; Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a><br>
&gt; =C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<=
br>
&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" targ=
et=3D"_blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjmaciei-mo=
bl1" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/1755889.DcAR2TnsQj%<wbr>40tjmaciei-mobl1</a>.<br></p>

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG7s2pW9YUXFqYo8Xr%3DRAzrooGH=
p3dTu8HpBrjoyCOw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAFdMc-<wbr>1ZG7s2pW9YUXFqYo8Xr%<wbr>3DRAzrooGHp3dTu8HpBrj=
oyCOw%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGa0LWvbj98GLkG%3D4ZAo06EQCkYPq9XK42=
0FQsFh5e2MogWpYg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGa0LWvbj98GLk=
G%3D4ZAo06EQCkYPq9XK420FQsFh5e2MogWpYg%40mail.gmail.com</a>.<br />

--089e0122829cf4d9af053d5a01eb--

.

------=_Part_3901_1646838095.1474833348229
Content-Type: multipart/alternative;
 boundary="----=_Part_3902_1034370080.1474833348229"

------=_Part_3902_1034370080.1474833348229
Content-Type: text/plain; charset=UTF-8

I Know that are more use cases implied included the ternary operator, you
show how QT uses that macro and many other forms that can be seen out there
which demonstrates the need of the programmer to state this functionality.
The proposal would address all use cases in which branch prediction exist.


On Sunday, 25 September 2016 19:21:47 UTC+1, Thiago Macieira wrote:
>
> On domingo, 25 de setembro de 2016 03:11:38 PDT mayorg...@gmail.com
> <javascript:> wrote:
> > As an example it would be applicable to the singleton pattern, something
> > like:
> >
> > T* singleton::get_instance() {
> >    if (p==0) unlikely {
> >       p = new singleton();
> >    }
> >    return p;
> > }
>
> Please don't make it a keyword of if or other constructs. The GCC built-in
> can
> be used in other statements too, mainly the ternay operator, but even
> outside
> too. Real examples:
>
>     readBuffer += Q_LIKELY(codec) ? codec->toUnicode(buf, bytesRead,
> &readConverterState)
>                                   : QString::fromLatin1(buf, bytesRead);
>
>     return Q_LIKELY(qMetaTypeGuiHelper) ? qMetaTypeGuiHelper[type -
> QMetaType::FirstGuiType].size : 0;
>
>     if (CanBeSmall)
>         return Q_LIKELY(b);
>     return Q_UNLIKELY(b);
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/812405d5-57ca-488d-8d1b-82be4f692256%40isocpp.org.

------=_Part_3902_1034370080.1474833348229
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I Know that are more use cases implied included the ternar=
y operator, you show how QT uses that macro and many other forms that can b=
e seen out there which demonstrates the need of the programmer to state thi=
s functionality.<div>The proposal would address all use cases in which bran=
ch prediction exist.</div><div><br><br>On Sunday, 25 September 2016 19:21:4=
7 UTC+1, Thiago Macieira  wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">On domingo, 25 de setembro de 2016 03:11:38 PDT <a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"7mvMhoh0BAAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;">mayorg...@gmail.com</a> wrote:
<br>&gt; As an example it would be applicable to the singleton pattern, som=
ething
<br>&gt; like:
<br>&gt;=20
<br>&gt; T* singleton::get_instance() {
<br>&gt; =C2=A0 =C2=A0if (p=3D=3D0) unlikely {
<br>&gt; =C2=A0 =C2=A0 =C2=A0 p =3D new singleton();
<br>&gt; =C2=A0 =C2=A0}
<br>&gt; =C2=A0 =C2=A0return p;
<br>&gt; }
<br>
<br>Please don&#39;t make it a keyword of if or other constructs. The GCC b=
uilt-in can=20
<br>be used in other statements too, mainly the ternay operator, but even o=
utside=20
<br>too. Real examples:
<br>
<br>=C2=A0 =C2=A0 readBuffer +=3D Q_LIKELY(codec) ? codec-&gt;toUnicode(buf=
, bytesRead,=20
<br>&amp;readConverterState)
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : QString::fromLatin1(buf,=
 bytesRead);
<br>
<br>=C2=A0 =C2=A0 return Q_LIKELY(qMetaTypeGuiHelper) ? qMetaTypeGuiHelper[=
type -=20
<br>QMetaType::FirstGuiType].size : 0;
<br>
<br>=C2=A0 =C2=A0 if (CanBeSmall)
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return Q_LIKELY(b);
<br>=C2=A0 =C2=A0 return Q_UNLIKELY(b);
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/812405d5-57ca-488d-8d1b-82be4f692256%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/812405d5-57ca-488d-8d1b-82be4f692256=
%40isocpp.org</a>.<br />

------=_Part_3902_1034370080.1474833348229--

------=_Part_3901_1646838095.1474833348229--

.

------=_Part_3875_1192767072.1474833398663
Content-Type: multipart/alternative;
 boundary="----=_Part_3876_324494966.1474833398663"

------=_Part_3876_324494966.1474833398663
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'll look at it thanks

On Sunday, 25 September 2016 20:27:54 UTC+1, Carl Cook wrote:
>
> Maybe it is best to keep this discussion within SG14 for now (especially=
=20
> considering there is already at least one proposal for branch prediction=
=20
> within that group at present).
>
>
> On 25 September 2016 at 21:22, dgutson . <daniel...@gmail.com=20
> <javascript:>> wrote:
>
>> El 25/9/2016 15:34, "Thiago Macieira" <thi...@macieira.org <javascript:>=
>=20
>> escribi=C3=B3:
>> >
>> > On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:
>> > > Everything involving a branch: if, while, for, switch, ?. Please whe=
n
>> > > proposing these sort of things, keep in mind that the world is not=
=20
>> only
>> > > x86. There are other archs that don't have branch predictors. That's=
=20
>> why an
>> > > (ignorable) attribute is what should be, if at ever standarized.
>> >
>> > When you say "there are other archs that don't" (besides x86), you mea=
n=20
>> "most
>> > archs do, but there are a couple of processor SKUs that don't". There=
=20
>> are
>> > modern x86 that don't have pipelining or branch prediction (Quark MCUs=
)=20
>> and
>> > most modern architectures do have that (ARM, MIPS, Sparc, POWER).
>>
>> This would lead to a sterile discussion I'm not interested to enter whic=
h=20
>> is at the edge of personal knowledge.
>> Small IoT processors, or even just saying "ARM" is missing too much=20
>> information, since subfamilies differ too much (A, R, M, etc.).
>>
>> Sorry guys I'm leaving this discussion. It's pointless for me to keep=20
>> participating.
>> If there's a paper I will read it.
>>
>>    Daniel=20
>>
>> >
>> > --
>> > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> >    Software Architect - Intel Open Source Technology Center
>> >
>> > --
>> > You received this message because you are subscribed to the Google=20
>> Groups "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this group and stop receiving emails from it, send=
=20
>> an email to std-proposal...@isocpp.org <javascript:>.
>> > To post to this group, send email to std-pr...@isocpp.org <javascript:=
>
>> .
>> > To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcA=
R2TnsQj%40tjmaciei-mobl1
>> .
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG7=
s2pW9YUXFqYo8Xr%3DRAzrooGHp3dTu8HpBrjoyCOw%40mail.gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG=
7s2pW9YUXFqYo8Xr%3DRAzrooGHp3dTu8HpBrjoyCOw%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
>
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b4e5794d-9974-4ab8-9299-946c02b04054%40isocpp.or=
g.

------=_Part_3876_324494966.1474833398663
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ll look at it thanks<br><br>On Sunday, 25 September =
2016 20:27:54 UTC+1, Carl Cook  wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr">Maybe it is best to keep this discussion within SG=
14 for now (especially considering there is already at least one proposal f=
or branch prediction within that group at present).<div><br></div></div><di=
v><br><div class=3D"gmail_quote">On 25 September 2016 at 21:22, dgutson . <=
span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"pr2EOCR4BAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39=
;;return true;">daniel...@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><span><p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 15:34, &quot;Thiago Macieira&quot; &lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"pr2EOCR4BAAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">thi...@macie=
ira.org</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:<br>
&gt; &gt; Everything involving a branch: if, while, for, switch, ?. Please =
when<br>
&gt; &gt; proposing these sort of things, keep in mind that the world is no=
t only<br>
&gt; &gt; x86. There are other archs that don&#39;t have branch predictors.=
 That&#39;s why an<br>
&gt; &gt; (ignorable) attribute is what should be, if at ever standarized.<=
br>
&gt;<br>
&gt; When you say &quot;there are other archs that don&#39;t&quot; (besides=
 x86), you mean &quot;most<br>
&gt; archs do, but there are a couple of processor SKUs that don&#39;t&quot=
;. There are<br>
&gt; modern x86 that don&#39;t have pipelining or branch prediction (Quark =
MCUs) and<br>
&gt; most modern architectures do have that (ARM, MIPS, Sparc, POWER).</p>
</span><p dir=3D"ltr">This would lead to a sterile discussion I&#39;m not i=
nterested to enter which is at the edge of personal knowledge.<br>
Small IoT processors, or even just saying &quot;ARM&quot; is missing too mu=
ch information, since subfamilies differ too much (A, R, M, etc.).</p>
<p dir=3D"ltr">Sorry guys I&#39;m leaving this discussion. It&#39;s pointle=
ss for me to keep participating.<br>
If there&#39;s a paper I will read it.</p>
<p dir=3D"ltr">=C2=A0=C2=A0 Daniel </p><span>
<p dir=3D"ltr">&gt;<br>
&gt; --<br>
&gt; Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
><br>
&gt; =C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<=
br>
&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"pr2EOCR4BAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">std-proposal...@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"pr2EOCR4BAAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjmaciei-mo=
bl1" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQ=
j%40tjmaciei-mobl1&#39;;return true;" onclick=3D"this.href=3D&#39;https://g=
roups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tj=
maciei-mobl1&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org=
/d/msgid/std-<wbr>proposals/1755889.DcAR2TnsQj%<wbr>40tjmaciei-mobl1</a>.<b=
r></p>

<p></p>

-- <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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
pr2EOCR4BAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"pr2EOCR4BAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG7s2pW9YUXFqYo8Xr%3DRAzrooGH=
p3dTu8HpBrjoyCOw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG7s2pW9YUX=
FqYo8Xr%3DRAzrooGHp3dTu8HpBrjoyCOw%40mail.gmail.com?utm_medium\x3demail\x26=
utm_source\x3dfooter&#39;;return true;" onclick=3D"this.href=3D&#39;https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG7s2pW9YUXFq=
Yo8Xr%3DRAzrooGHp3dTu8HpBrjoyCOw%40mail.gmail.com?utm_medium\x3demail\x26ut=
m_source\x3dfooter&#39;;return true;">https://groups.google.com/a/<wbr>isoc=
pp.org/d/msgid/std-<wbr>proposals/CAFdMc-<wbr>1ZG7s2pW9YUXFqYo8Xr%<wbr>3DRA=
zrooGHp3dTu8HpBrjoyCOw%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b4e5794d-9974-4ab8-9299-946c02b04054%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b4e5794d-9974-4ab8-9299-946c02b04054=
%40isocpp.org</a>.<br />

------=_Part_3876_324494966.1474833398663--

------=_Part_3875_1192767072.1474833398663--

.

------=_Part_476_1842301847.1474834080567
Content-Type: multipart/alternative;
 boundary="----=_Part_477_46516769.1474834080567"

------=_Part_477_46516769.1474834080567
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Sunday, 25 September 2016 20:56:39 UTC+1, mayorg...@gmail.com wrote:
>
> I'll look at it thanks
>
> On Sunday, 25 September 2016 20:27:54 UTC+1, Carl Cook wrote:
>>
>> Maybe it is best to keep this discussion within SG14 for now (especially=
=20
>> considering there is already at least one proposal for branch prediction=
=20
>> within that group at present).
>>
>>
>> On 25 September 2016 at 21:22, dgutson . <daniel...@gmail.com> wrote:
>>
>>> El 25/9/2016 15:34, "Thiago Macieira" <thi...@macieira.org> escribi=C3=
=B3:
>>> >
>>> > On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:
>>> > > Everything involving a branch: if, while, for, switch, ?. Please wh=
en
>>> > > proposing these sort of things, keep in mind that the world is not=
=20
>>> only
>>> > > x86. There are other archs that don't have branch predictors. That'=
s=20
>>> why an
>>> > > (ignorable) attribute is what should be, if at ever standarized.
>>> >
>>> > When you say "there are other archs that don't" (besides x86), you=20
>>> mean "most
>>> > archs do, but there are a couple of processor SKUs that don't". There=
=20
>>> are
>>> > modern x86 that don't have pipelining or branch prediction (Quark=20
>>> MCUs) and
>>> > most modern architectures do have that (ARM, MIPS, Sparc, POWER).
>>>
>>> This would lead to a sterile discussion I'm not interested to enter=20
>>> which is at the edge of personal knowledge.
>>> Small IoT processors, or even just saying "ARM" is missing too much=20
>>> information, since subfamilies differ too much (A, R, M, etc.).
>>>
>>> Sorry guys I'm leaving this discussion. It's pointless for me to keep=
=20
>>> participating.
>>> If there's a paper I will read it.
>>>
>>>    Daniel
>>>
>>
beside the current status of compilers and microprocessor and how they=20
would digest the information provided by the programmer to produce assembly=
=20
there is a need to code branch likeliness just because the programmer knows=
=20
application domain and the compiler doesn't.
As technology evolves a program might be recompiled for a still not=20
designed processor which might know what to do with this bit of information=
=20
found in the code effectively. Don't forget that C++ is the mean to state=
=20
human intent, high level, and I personally have found a significant number=
=20
of cases in which I've been in the need of using it, I then use=20
compiler'specific keywords.
Sorry if I repeat key concepts among all my answers.

=20

> >
>>> > --
>>> > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>> >    Software Architect - Intel Open Source Technology Center
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> > To unsubscribe from this group and stop receiving emails from it, sen=
d=20
>>> an email to std-proposal...@isocpp.org.
>>> > To post to this group, send email to std-pr...@isocpp.org.
>>> > To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.Dc=
AR2TnsQj%40tjmaciei-mobl1
>>> .
>>>
>>> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG=
7s2pW9YUXFqYo8Xr%3DRAzrooGHp3dTu8HpBrjoyCOw%40mail.gmail.com=20
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1Z=
G7s2pW9YUXFqYo8Xr%3DRAzrooGHp3dTu8HpBrjoyCOw%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
>>> .
>>>
>>
>>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6fc74c71-500a-4b78-81b8-3bf82ff7c2c1%40isocpp.or=
g.

------=_Part_477_46516769.1474834080567
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, 25 September 2016 20:56:39 UTC+1, mayor=
g...@gmail.com  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">I&#39;ll look at it thanks<br><br>On Sunday, 25 September 2016 20:=
27:54 UTC+1, Carl Cook  wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">Maybe it is best to keep this discussion within SG14 for now (e=
specially considering there is already at least one proposal for branch pre=
diction within that group at present).<div><br></div></div><div><br><div cl=
ass=3D"gmail_quote">On 25 September 2016 at 21:22, dgutson . <span dir=3D"l=
tr">&lt;<a rel=3D"nofollow">daniel...@gmail.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><span><p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 15:34, &quot;Thiago Macieira&quot; &lt;<a rel=
=3D"nofollow">thi...@macieira.org</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:<br>
&gt; &gt; Everything involving a branch: if, while, for, switch, ?. Please =
when<br>
&gt; &gt; proposing these sort of things, keep in mind that the world is no=
t only<br>
&gt; &gt; x86. There are other archs that don&#39;t have branch predictors.=
 That&#39;s why an<br>
&gt; &gt; (ignorable) attribute is what should be, if at ever standarized.<=
br>
&gt;<br>
&gt; When you say &quot;there are other archs that don&#39;t&quot; (besides=
 x86), you mean &quot;most<br>
&gt; archs do, but there are a couple of processor SKUs that don&#39;t&quot=
;. There are<br>
&gt; modern x86 that don&#39;t have pipelining or branch prediction (Quark =
MCUs) and<br>
&gt; most modern architectures do have that (ARM, MIPS, Sparc, POWER).</p>
</span><p dir=3D"ltr">This would lead to a sterile discussion I&#39;m not i=
nterested to enter which is at the edge of personal knowledge.<br>
Small IoT processors, or even just saying &quot;ARM&quot; is missing too mu=
ch information, since subfamilies differ too much (A, R, M, etc.).</p>
<p dir=3D"ltr">Sorry guys I&#39;m leaving this discussion. It&#39;s pointle=
ss for me to keep participating.<br>
If there&#39;s a paper I will read it.</p>
<p dir=3D"ltr">=C2=A0=C2=A0 Daniel</p></blockquote></div></div></blockquote=
></div></blockquote><div><br></div><div>beside the current status of compil=
ers and microprocessor and how they would digest the information provided b=
y the programmer to produce assembly there is a need to code branch likelin=
ess just because the programmer knows application domain and the compiler d=
oesn&#39;t.</div><div>As technology evolves a program might be recompiled f=
or a still not designed processor which might know what to do with this bit=
 of information found in the code effectively. Don&#39;t forget that C++ is=
 the mean to state human intent, high level, and I personally have found a =
significant number of cases in which I&#39;ve been in the need of using it,=
 I then use compiler&#39;specific keywords.</div><div>Sorry if I repeat key=
 concepts among all my answers.</div><div><br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div><div class=3D"gmail_quote"><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><p dir=3D"ltr"> </p><span>
<p dir=3D"ltr">&gt;<br>
&gt; --<br>
&gt; Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"=
nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.goog=
le.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3=
dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return tr=
ue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" rel=3D"nofo=
llow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.c=
om/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHG=
RJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a>=
<br>
&gt; =C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<=
br>
&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...@iso=
cpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjmaciei-mo=
bl1" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQ=
j%40tjmaciei-mobl1&#39;;return true;" onclick=3D"this.href=3D&#39;https://g=
roups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tj=
maciei-mobl1&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org=
/d/msgid/std-<wbr>proposals/1755889.DcAR2TnsQj%<wbr>40tjmaciei-mobl1</a>.<b=
r></p>

<p></p>

-- <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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG7s2pW9YUXFqYo8Xr%3DRAzrooGH=
p3dTu8HpBrjoyCOw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG7s2pW9YUX=
FqYo8Xr%3DRAzrooGHp3dTu8HpBrjoyCOw%40mail.gmail.com?utm_medium\x3demail\x26=
utm_source\x3dfooter&#39;;return true;" onclick=3D"this.href=3D&#39;https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1ZG7s2pW9YUXFq=
Yo8Xr%3DRAzrooGHp3dTu8HpBrjoyCOw%40mail.gmail.com?utm_medium\x3demail\x26ut=
m_source\x3dfooter&#39;;return true;">https://groups.google.com/a/<wbr>isoc=
pp.org/d/msgid/std-<wbr>proposals/CAFdMc-<wbr>1ZG7s2pW9YUXFqYo8Xr%<wbr>3DRA=
zrooGHp3dTu8HpBrjoyCOw%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>
</blockquote></div></blockquote></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6fc74c71-500a-4b78-81b8-3bf82ff7c2c1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6fc74c71-500a-4b78-81b8-3bf82ff7c2c1=
%40isocpp.org</a>.<br />

------=_Part_477_46516769.1474834080567--

------=_Part_476_1842301847.1474834080567--

.

--001a113acda03c6910053d5a9925
Content-Type: text/plain; charset=UTF-8

This thread is conflating HW branch history with other issues.

likely / unlikely hints would not help a machine endowed with branch
history HW predict a given branch once such a machine had executed that
branch a few times.  Rather such a machine would rely on the contents of
its branch history table.

That said, nearly every machine - no matter how tiny or massive -
implements the simplistic heuristic that, in the absence of better
information (either for lack of a branch history HW or because the branch
being looked-up is not present in the history table), a backward branch is
predicted taken and a forward branch not taken.  Implementing that
heuristic rarely requires nothing more than inspecting the sign of the
PC-relative branch displacement.

likely / unlikely keywords are more useful during compilation (as opposed
to execution) since they enable more thoughtful basic block layout,
hopefully leading to better i-cache utilization.

There is a vague analogy between a HW branch history table and
profile-based optimization.  Profile collection is effectively a means of
conveying execution history to the compilation toolchain.  Once that
happens likely / unlikely hints in the source code become less valuable.

/john


On Sun, Sep 25, 2016 at 2:34 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:
> > Everything involving a branch: if, while, for, switch, ?. Please when
> > proposing these sort of things, keep in mind that the world is not only
> > x86. There are other archs that don't have branch predictors. That's why
> an
> > (ignorable) attribute is what should be, if at ever standarized.
>
> When you say "there are other archs that don't" (besides x86), you mean
> "most
> archs do, but there are a couple of processor SKUs that don't". There are
> modern x86 that don't have pipelining or branch prediction (Quark MCUs) and
> most modern architectures do have that (ARM, MIPS, Sparc, POWER).
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjmaciei-mobl1.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnXXogNpwku95yi7Xpdi4xobR-Deb8T0%3D%2BAeS6xb1Gd2jFdbg%40mail.gmail.com.

--001a113acda03c6910053d5a9925
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif">This thread is conflating HW branch history with other =
issues.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif">likely / unlikely hints would not help a machi=
ne endowed with branch history HW predict a given branch once such a machin=
e had executed that branch a few times.=C2=A0 Rather such a machine would r=
ely on the contents of its branch history table.</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">That =
said, nearly every machine - no matter how tiny or massive - implements the=
 simplistic heuristic that, in the absence of better information (either fo=
r lack of a branch history HW or because the branch being looked-up is not =
present in the history table), a backward branch is predicted taken and a f=
orward branch not taken.=C2=A0 Implementing that heuristic rarely requires =
nothing more than inspecting the sign of the PC-relative branch displacemen=
t.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif">likely / unlikely=C2=A0keywords are more useful dur=
ing compilation (as opposed to execution) since they enable more thoughtful=
 basic block layout, hopefully leading to better i-cache utilization.</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif">There is a vague analogy between a HW branch history table =
and profile-based optimization.=C2=A0 Profile collection is effectively a m=
eans of conveying execution history to the compilation toolchain.=C2=A0 Onc=
e that happens likely / unlikely hints in the source code become less valua=
ble.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif">/john</div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif"><br></div></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Sun, Sep 25, 2016 at 2:34 PM, Thi=
ago Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" t=
arget=3D"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson .=
 wrote:<br>
&gt; Everything involving a branch: if, while, for, switch, ?. Please when<=
br>
&gt; proposing these sort of things, keep in mind that the world is not onl=
y<br>
&gt; x86. There are other archs that don&#39;t have branch predictors. That=
&#39;s why an<br>
&gt; (ignorable) attribute is what should be, if at ever standarized.<br>
<br>
When you say &quot;there are other archs that don&#39;t&quot; (besides x86)=
, you mean &quot;most<br>
archs do, but there are a couple of processor SKUs that don&#39;t&quot;. Th=
ere are<br>
modern x86 that don&#39;t have pipelining or branch prediction (Quark MCUs)=
 and<br>
most modern architectures do have that (ARM, MIPS, Sparc, POWER).<br>
<span class=3D""><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<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">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/1755889.DcAR2TnsQj%<wbr>40tjmaciei-=
mobl1</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnXXogNpwku95yi7Xpdi4xobR-Deb8T0%3D=
%2BAeS6xb1Gd2jFdbg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnXXogNpwku=
95yi7Xpdi4xobR-Deb8T0%3D%2BAeS6xb1Gd2jFdbg%40mail.gmail.com</a>.<br />

--001a113acda03c6910053d5a9925--

.

--001a1146f3c80a3a7d053d5abd54
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
>
>>    - What about when the likely branch is not the one that you want to
>>    optimize for?
>>
>> I understand you mean if the programmer make a mistake qualifying the
> branch, as a result of a mistake the program would not be optimized well.
>

No, I mean that there are situations where the likely case is dominant, but
it's the unlikely branch that you care about (in terms of performance). So,
the assumption that likely =3D=3D important doesn't necessarily hold.

At every decision point the processor has only two choices either load
> branch1 instructions or branch2 into the pipeline
>

Not necessarily true. Predicated instructions, for example. And out of
order execution, as another example (think of two branches that can largely
be executed in parallel).


> branches labeled at 'origin' can be tracked by the compiler and on every
> decision point load the right branch based on how well this tracking is
> performed.
>

How? By PGO? In that case, why not just let PGO do all the work, instead of
manually annotating?

One final comment (and this echos John's statement I think) - I recommend
making it very clear that you are only referring to static branch
prediction (if that's the case). This cuts down the complexity of the
problem you are trying to solve.


>
>>> On Sunday, 25 September 2016 15:28:36 UTC+1, dgutson wrote:
>>>>
>>>> El 25/9/2016 11:14, "Andrey Semashev" <andrey....@gmail.com> escribi=
=C3=B3:
>>>> >
>>>> > On 09/25/16 16:33, dgutson . wrote:
>>>> >>
>>>> >> El 25/9/2016 10:16, <mayorg...@gmail.com
>>>> >> <mailto:mayorg...@gmail.com>> escribi=C3=B3:
>>>> >>
>>>> >>>
>>>> >>> The compiler does not know the application domain, and AFAIK some =
of
>>>> >>
>>>> >> them has set this prediction random. In general I think this
>>>> applicable
>>>> >> to any computer language, the programmer should have a mean to hint
>>>> the
>>>> >> compiler when sometimes is obvious you=C5=95e programming a corner =
case
>>>> >> branch, if the compiler ignores these hints it will just generate
>>>> less
>>>> >> optimized code for a real case execution.
>>>> >>
>>>> >> But why a standard attribute? Go to your compiler vendor and ask to
>>>> >> provide an attribute. Think in portability.
>>>> >> So my question remains: why an architecture-specific feature should
>>>> be
>>>> >> standard, when the language provides the syntax? Please answer.
>>>> >
>>>> >
>>>> > If I may, my answer is the same reason we have the standard in the
>>>> first place - to have a portable tool for that. Yes, we have
>>>> compiler-specific intrinsics now, but the point of standardizing is to
>>>> relieve the developers from having to define macros on top of them ove=
r and
>>>> over again.
>>>> >
>>>> > Also, I disagree with you calling it an architecture-specific
>>>> feature. Even if an architecture lacks hardware branch prediction hint=
s,
>>>> like x86 or IA-64, or even the branch predictor itself (which, I think=
, is
>>>> rare these days), the hint can still be used to organize and optimize =
code.
>>>> For instance, besides code locality, the hint may instruct the compile=
r to
>>>> optimize less frequently executed sections for size rather than speed =
or
>>>> move them to a different section altogether. Such behavior is not
>>>> architecture specific.
>>>>
>>>> Please show me exactly how would this arch-nonspecific optimization
>>>> work either for speed or size and I will believe you :)
>>>> I don't see any.
>>>>
>>>> >
>>>> >
>>>> > --
>>>> > 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-proposal...@isocpp.org.
>>>> > To post to this group, send email to std-pr...@isocpp.org.
>>>> > To view this discussion on the web visit
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals
>>>> /abeb6c76-63dd-5814-bf3f-d5564c8fdfe7%40gmail.com.
>>>>
>>> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/129f364a-072b-4281-
> 8e11-a6870e21f69f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/129f364a-07=
2b-4281-8e11-a6870e21f69f%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAGa0LWuK_LG_7yGD5e%3D9zDabnn9M4Ect4%2BJBsOhbsna=
hMz7srw%40mail.gmail.com.

--001a1146f3c80a3a7d053d5abd54
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:arial,=
helvetica,sans-serif"><ul style=3D"font-family:arial,sans-serif;font-size:s=
mall"><li>What about when the likely branch is not the one that you want to=
 optimize for?</li></ul></div></div></blockquote></span><div>I understand y=
ou mean if the programmer make a mistake qualifying the branch, as a result=
 of a mistake the program would not be optimized well. </div></div></blockq=
uote><div><br></div><div>No, I mean that there are situations where the lik=
ely case is dominant, but it&#39;s the unlikely branch that you care about =
(in terms of performance). So, the assumption that likely =3D=3D important =
doesn&#39;t necessarily hold.</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div>At every decision point the processor has only =
two choices either load branch1 instructions or branch2 into the pipeline</=
div></div></blockquote><div><br></div><div>Not necessarily true. Predicated=
 instructions, for example. And out of order execution, as another example =
(think of two branches that can largely be executed in parallel).</div><div=
>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>branc=
hes labeled at &#39;origin&#39; can be tracked by the compiler and on every=
 decision point load the right branch based on how well this tracking is pe=
rformed.=C2=A0</div></div></blockquote><div><br></div><div>How? By PGO? In =
that case, why not just let PGO do all the work, instead of manually annota=
ting?</div><div><br></div><div>One final comment (and this echos John&#39;s=
 statement I think) - I recommend making it very clear that you are only re=
ferring to static branch prediction (if that&#39;s the case). This cuts dow=
n the complexity of the problem you are trying to solve.=C2=A0</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"h5"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div></div><div><br>On =
Sunday, 25 September 2016 15:28:36 UTC+1, dgutson  wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 11:14, &quot;Andrey Semashev&quot; &lt;<a rel=
=3D"nofollow">andrey....@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; On 09/25/16 16:33, dgutson . wrote:<br>
&gt;&gt;<br>
&gt;&gt; El 25/9/2016 10:16, &lt;<a rel=3D"nofollow">mayorg...@gmail.com</a=
><br>
&gt;&gt; &lt;mailto:<a rel=3D"nofollow">mayorg...@gmail.com</a>&gt;&gt; esc=
ribi=C3=B3:<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The compiler does not know the application domain, and AFAIK s=
ome of<br>
&gt;&gt;<br>
&gt;&gt; them has set this prediction random. In general I think this appli=
cable<br>
&gt;&gt; to any computer language, the programmer should have a mean to hin=
t the<br>
&gt;&gt; compiler when sometimes is obvious you=C5=95e programming a corner=
 case<br>
&gt;&gt; branch, if the compiler ignores these hints it will just generate =
less<br>
&gt;&gt; optimized code for a real case execution.<br>
&gt;&gt;<br>
&gt;&gt; But why a standard attribute? Go to your compiler vendor and ask t=
o<br>
&gt;&gt; provide an attribute. Think in portability.<br>
&gt;&gt; So my question remains: why an architecture-specific feature shoul=
d be<br>
&gt;&gt; standard, when the language provides the syntax? Please answer.<br=
>
&gt;<br>
&gt;<br>
&gt; If I may, my answer is the same reason we have the standard in the fir=
st place - to have a portable tool for that. Yes, we have compiler-specific=
 intrinsics now, but the point of standardizing is to relieve the developer=
s from having to define macros on top of them over and over again.<br>
&gt;<br>
&gt; Also, I disagree with you calling it an architecture-specific feature.=
 Even if an architecture lacks hardware branch prediction hints, like x86 o=
r IA-64, or even the branch predictor itself (which, I think, is rare these=
 days), the hint can still be used to organize and optimize code. For insta=
nce, besides code locality, the hint may instruct the compiler to optimize =
less frequently executed sections for size rather than speed or move them t=
o a different section altogether. Such behavior is not architecture specifi=
c.</p>
<p dir=3D"ltr">Please show me exactly how would this arch-nonspecific optim=
ization work either for speed or size and I will believe you :)<br>
I don&#39;t see any.</p>
<p dir=3D"ltr">&gt;<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...@iso=
cpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/abeb6c76-63dd-5814-bf3f-d5564c8f=
dfe7%40gmail.com" rel=3D"nofollow" target=3D"_blank">https://groups.google.=
com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/abeb6c76-63dd-5814-bf3f-<w=
br>d5564c8fdfe7%40gmail.com</a>.<br></p>
</blockquote></div></div></div></blockquote></div></blockquote></div></div>=
</div><div><div class=3D"h5">

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/129f364a-072b-4281-8e11-a6870e21f69f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/129f=
364a-072b-4281-<wbr>8e11-a6870e21f69f%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGa0LWuK_LG_7yGD5e%3D9zDabnn9M4Ect4%=
2BJBsOhbsnahMz7srw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGa0LWuK_LG_=
7yGD5e%3D9zDabnn9M4Ect4%2BJBsOhbsnahMz7srw%40mail.gmail.com</a>.<br />

--001a1146f3c80a3a7d053d5abd54--

.

------=_Part_3960_601160669.1474834955999
Content-Type: multipart/alternative;
 boundary="----=_Part_3961_568266026.1474834956000"

------=_Part_3961_568266026.1474834956000
Content-Type: text/plain; charset=UTF-8



On Sunday, 25 September 2016 21:10:30 UTC+1, John Yates wrote:
>
> This thread is conflating HW branch history with other issues.
>
> likely / unlikely hints would not help a machine endowed with branch
> history HW predict a given branch once such a machine had executed that
> branch a few times.  Rather such a machine would rely on the contents of
> its branch history table.
>
> That said, nearly every machine - no matter how tiny or massive -
> implements the simplistic heuristic that, in the absence of better
> information (either for lack of a branch history HW or because the branch
> being looked-up is not present in the history table), a backward branch is
> predicted taken and a forward branch not taken.  Implementing that
> heuristic rarely requires nothing more than inspecting the sign of the
> PC-relative branch displacement.
>
> likely / unlikely keywords are more useful during compilation (as opposed
> to execution) since they enable more thoughtful basic block layout,
> hopefully leading to better i-cache utilization.
>
> There is a vague analogy between a HW branch history table and
> profile-based optimization.  Profile collection is effectively a means of
> conveying execution history to the compilation toolchain.  Once that
> happens likely / unlikely hints in the source code become less valuable.
>
> I completely agree with this, once a profile is done and returned back
somehow to the compile can serve if done to emit warnings when the code
annotations in the code differs from execution statistic. But how many
programmers care of doing such analysis? I've seen none doing this. And I
manifest I don't even know if the compiler would take output from PBO for
regenerating new optimized assembly from the same sources which would be
nice if it could.


> /john
>
>
> On Sun, Sep 25, 2016 at 2:34 PM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>
>> On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:
>> > Everything involving a branch: if, while, for, switch, ?. Please when
>> > proposing these sort of things, keep in mind that the world is not only
>> > x86. There are other archs that don't have branch predictors. That's
>> why an
>> > (ignorable) attribute is what should be, if at ever standarized.
>>
>> When you say "there are other archs that don't" (besides x86), you mean
>> "most
>> archs do, but there are a couple of processor SKUs that don't". There are
>> modern x86 that don't have pipelining or branch prediction (Quark MCUs)
>> and
>> most modern architectures do have that (ARM, MIPS, Sparc, POWER).
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjmaciei-mobl1
>> .
>>
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-60510f63bad0%40isocpp.org.

------=_Part_3961_568266026.1474834956000
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, 25 September 2016 21:10:30 UTC+1, John =
Yates  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div style=3D"font-family:arial,helvetica,sans-serif">This thread is confla=
ting HW branch history with other issues.</div><div style=3D"font-family:ar=
ial,helvetica,sans-serif"><br></div><div style=3D"font-family:arial,helveti=
ca,sans-serif">likely / unlikely hints would not help a machine endowed wit=
h branch history HW predict a given branch once such a machine had executed=
 that branch a few times.=C2=A0 Rather such a machine would rely on the con=
tents of its branch history table.</div><div style=3D"font-family:arial,hel=
vetica,sans-serif"><br></div><div style=3D"font-family:arial,helvetica,sans=
-serif">That said, nearly every machine - no matter how tiny or massive - i=
mplements the simplistic heuristic that, in the absence of better informati=
on (either for lack of a branch history HW or because the branch being look=
ed-up is not present in the history table), a backward branch is predicted =
taken and a forward branch not taken.=C2=A0 Implementing that heuristic rar=
ely requires nothing more than inspecting the sign of the PC-relative branc=
h displacement.</div><div style=3D"font-family:arial,helvetica,sans-serif">=
<br></div><div style=3D"font-family:arial,helvetica,sans-serif">likely / un=
likely=C2=A0keywords are more useful during compilation (as opposed to exec=
ution) since they enable more thoughtful basic block layout, hopefully lead=
ing to better i-cache utilization.</div><div style=3D"font-family:arial,hel=
vetica,sans-serif"><br></div><div style=3D"font-family:arial,helvetica,sans=
-serif">There is a vague analogy between a HW branch history table and prof=
ile-based optimization.=C2=A0 Profile collection is effectively a means of =
conveying execution history to the compilation toolchain.=C2=A0 Once that h=
appens likely / unlikely hints in the source code become less valuable.</di=
v><div style=3D"font-family:arial,helvetica,sans-serif"><br></div></div></b=
lockquote><div>I completely agree with this, once a profile is done and ret=
urned back somehow to the compile can serve if done to emit warnings when t=
he code annotations in the code differs from execution statistic. But how m=
any programmers care of doing such analysis? I&#39;ve seen none doing this.=
 And I manifest I don&#39;t even know if the compiler would take output fro=
m PBO for regenerating new optimized assembly from the same sources which w=
ould be nice if it could.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div style=3D"font-family:arial,he=
lvetica,sans-serif"></div><div style=3D"font-family:arial,helvetica,sans-se=
rif">/john</div><div style=3D"font-family:arial,helvetica,sans-serif"><br><=
/div></div><div><br><div class=3D"gmail_quote">On Sun, Sep 25, 2016 at 2:34=
 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"pKVZeXd6BAAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">thi...@macieira.org</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">On domingo, 25 de setembro de 2016=
 09:46:56 PDT dgutson . wrote:<br>
&gt; Everything involving a branch: if, while, for, switch, ?. Please when<=
br>
&gt; proposing these sort of things, keep in mind that the world is not onl=
y<br>
&gt; x86. There are other archs that don&#39;t have branch predictors. That=
&#39;s why an<br>
&gt; (ignorable) attribute is what should be, if at ever standarized.<br>
<br>
When you say &quot;there are other archs that don&#39;t&quot; (besides x86)=
, you mean &quot;most<br>
archs do, but there are a couple of processor SKUs that don&#39;t&quot;. Th=
ere are<br>
modern x86 that don&#39;t have pipelining or branch prediction (Quark MCUs)=
 and<br>
most modern architectures do have that (ARM, MIPS, Sparc, POWER).<br>
<span><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.href=3D&=
#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;">=
macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" rel=3D"nofollow"=
 target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.com/ur=
l?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5=
_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
pKVZeXd6BAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"pKVZeXd6BAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjmaciei-=
mobl1" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2Tn=
sQj%40tjmaciei-mobl1&#39;;return true;" onclick=3D"this.href=3D&#39;https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40=
tjmaciei-mobl1&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.o=
rg/d/msgid/std-<wbr>proposals/1755889.DcAR2TnsQj%<wbr>40tjmaciei-mobl1</a>.=
<br>
</blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-60510f63bad0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-60510f63bad0=
%40isocpp.org</a>.<br />

------=_Part_3961_568266026.1474834956000--

------=_Part_3960_601160669.1474834955999--

.

--089e014934acc594fd053d6b1182
Content-Type: text/plain; charset=UTF-8

This whole discussion also intersects with the general idea of using
asserts to guide optimizations.


ie in both cases, you are trying to give the compiler more information than
it could reasonably figure out on its own.

On Sun, Sep 25, 2016 at 4:22 PM, <mayorga.geek@gmail.com> wrote:

>
>
> On Sunday, 25 September 2016 21:10:30 UTC+1, John Yates wrote:
>>
>> This thread is conflating HW branch history with other issues.
>>
>> likely / unlikely hints would not help a machine endowed with branch
>> history HW predict a given branch once such a machine had executed that
>> branch a few times.  Rather such a machine would rely on the contents of
>> its branch history table.
>>
>> That said, nearly every machine - no matter how tiny or massive -
>> implements the simplistic heuristic that, in the absence of better
>> information (either for lack of a branch history HW or because the branch
>> being looked-up is not present in the history table), a backward branch is
>> predicted taken and a forward branch not taken.  Implementing that
>> heuristic rarely requires nothing more than inspecting the sign of the
>> PC-relative branch displacement.
>>
>> likely / unlikely keywords are more useful during compilation (as opposed
>> to execution) since they enable more thoughtful basic block layout,
>> hopefully leading to better i-cache utilization.
>>
>> There is a vague analogy between a HW branch history table and
>> profile-based optimization.  Profile collection is effectively a means of
>> conveying execution history to the compilation toolchain.  Once that
>> happens likely / unlikely hints in the source code become less valuable.
>>
>> I completely agree with this, once a profile is done and returned back
> somehow to the compile can serve if done to emit warnings when the code
> annotations in the code differs from execution statistic. But how many
> programmers care of doing such analysis? I've seen none doing this. And I
> manifest I don't even know if the compiler would take output from PBO for
> regenerating new optimized assembly from the same sources which would be
> nice if it could.
>
>
>> /john
>>
>>
>> On Sun, Sep 25, 2016 at 2:34 PM, Thiago Macieira <thi...@macieira.org>
>> wrote:
>>
>>> On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:
>>> > Everything involving a branch: if, while, for, switch, ?. Please when
>>> > proposing these sort of things, keep in mind that the world is not only
>>> > x86. There are other archs that don't have branch predictors. That's
>>> why an
>>> > (ignorable) attribute is what should be, if at ever standarized.
>>>
>>> When you say "there are other archs that don't" (besides x86), you mean
>>> "most
>>> archs do, but there are a couple of processor SKUs that don't". There are
>>> modern x86 that don't have pipelining or branch prediction (Quark MCUs)
>>> and
>>> most modern architectures do have that (ARM, MIPS, Sparc, POWER).
>>>
>>> --
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>>    Software Architect - Intel Open Source Technology Center
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjmaciei-mobl1.
>>>
>>
>> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-
> 85c3-60510f63bad0%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-60510f63bad0%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>



--
Be seeing you,
Tony

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu39NoLt-KHQxBDNPJTvT%2BXah6Z8veQHYSK7UFcTnP-tw%40mail.gmail.com.

--089e014934acc594fd053d6b1182
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>This whole discussion also intersects with =
the general idea of using asserts to guide optimizations.<br></div></div><b=
r><br></div><div>ie in both cases, you are trying to give the compiler more=
 information than it could reasonably figure out on its own.<br></div></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Sep 25, =
2016 at 4:22 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:mayorga.geek@gmai=
l.com" target=3D"_blank">mayorga.geek@gmail.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><br><br>On S=
unday, 25 September 2016 21:10:30 UTC+1, John Yates  wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:arial,he=
lvetica,sans-serif">This thread is conflating HW branch history with other =
issues.</div><div style=3D"font-family:arial,helvetica,sans-serif"><br></di=
v><div style=3D"font-family:arial,helvetica,sans-serif">likely / unlikely h=
ints would not help a machine endowed with branch history HW predict a give=
n branch once such a machine had executed that branch a few times.=C2=A0 Ra=
ther such a machine would rely on the contents of its branch history table.=
</div><div style=3D"font-family:arial,helvetica,sans-serif"><br></div><div =
style=3D"font-family:arial,helvetica,sans-serif">That said, nearly every ma=
chine - no matter how tiny or massive - implements the simplistic heuristic=
 that, in the absence of better information (either for lack of a branch hi=
story HW or because the branch being looked-up is not present in the histor=
y table), a backward branch is predicted taken and a forward branch not tak=
en.=C2=A0 Implementing that heuristic rarely requires nothing more than ins=
pecting the sign of the PC-relative branch displacement.</div><div style=3D=
"font-family:arial,helvetica,sans-serif"><br></div><div style=3D"font-famil=
y:arial,helvetica,sans-serif">likely / unlikely=C2=A0keywords are more usef=
ul during compilation (as opposed to execution) since they enable more thou=
ghtful basic block layout, hopefully leading to better i-cache utilization.=
</div><div style=3D"font-family:arial,helvetica,sans-serif"><br></div><div =
style=3D"font-family:arial,helvetica,sans-serif">There is a vague analogy b=
etween a HW branch history table and profile-based optimization.=C2=A0 Prof=
ile collection is effectively a means of conveying execution history to the=
 compilation toolchain.=C2=A0 Once that happens likely / unlikely hints in =
the source code become less valuable.</div><div style=3D"font-family:arial,=
helvetica,sans-serif"><br></div></div></blockquote></span><div>I completely=
 agree with this, once a profile is done and returned back somehow to the c=
ompile can serve if done to emit warnings when the code annotations in the =
code differs from execution statistic. But how many programmers care of doi=
ng such analysis? I&#39;ve seen none doing this. And I manifest I don&#39;t=
 even know if the compiler would take output from PBO for regenerating new =
optimized assembly from the same sources which would be nice if it could.=
=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif"></div><div=
 style=3D"font-family:arial,helvetica,sans-serif">/john</div><div style=3D"=
font-family:arial,helvetica,sans-serif"><br></div></div><div><br><div class=
=3D"gmail_quote"><span class=3D"">On Sun, Sep 25, 2016 at 2:34 PM, Thiago M=
acieira <span dir=3D"ltr">&lt;<a rel=3D"nofollow">thi...@macieira.org</a>&g=
t;</span> wrote:<br></span><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">=
On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:<br>
&gt; Everything involving a branch: if, while, for, switch, ?. Please when<=
br>
&gt; proposing these sort of things, keep in mind that the world is not onl=
y<br>
&gt; x86. There are other archs that don&#39;t have branch predictors. That=
&#39;s why an<br>
&gt; (ignorable) attribute is what should be, if at ever standarized.<br>
<br>
When you say &quot;there are other archs that don&#39;t&quot; (besides x86)=
, you mean &quot;most<br>
archs do, but there are a couple of processor SKUs that don&#39;t&quot;. Th=
ere are<br>
modern x86 that don&#39;t have pipelining or branch prediction (Quark MCUs)=
 and<br>
most modern architectures do have that (ARM, MIPS, Sparc, POWER).<br>
</span><span><span class=3D""><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"nofol=
low" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kd=
e.org" rel=3D"nofollow" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
</span><span class=3D"">To view this discussion on the web visit <a href=3D=
"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2=
TnsQj%40tjmaciei-mobl1" rel=3D"nofollow" target=3D"_blank">https://groups.g=
oogle.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1755889.DcAR2TnsQj%4=
0tjmaciei<wbr>-mobl1</a>.<br>
</span></blockquote></div><br></div>
</blockquote></div><span class=3D"">

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-60510f63bad0%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/1de3=
6ac6-2a6b-4a26-<wbr>85c3-60510f63bad0%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu39NoLt-KHQxBDNPJTvT%2BXah6Z8v=
eQHYSK7UFcTnP-tw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu39NoLt-=
KHQxBDNPJTvT%2BXah6Z8veQHYSK7UFcTnP-tw%40mail.gmail.com</a>.<br />

--089e014934acc594fd053d6b1182--

.

--001a1140fd9ec16913053d6bfcb9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

One of the key points from the perspective of SG14 is that sometimes,
optimizing for the common case conflicts with the needs of a program, as
there are some (that have been presented on that mailing list) where it is
preferable that the uncommon path, when it is taken, is the one the
binaries have been optimized for. It's one of the reasons why just letting
the compiler do what it does best is not necessarily appropriate sometimes.

Naming those attributes properly is something we're still working on (I
wrote =C2=ABwe=C2=BB but I'm mostly an observer on this one), but the group=
 that met
last Wednesday seemed of the opinion that since there are per-compiler
[un]likely equivalents already, this would be a good way to start (better
than inventing something before the design space has been fully explored).
I expect those working on these proposals to come back eventually with
other additions to the proposed set.

2016-09-26 11:49 GMT-04:00 Tony V E <tvaneerd@gmail.com>:

> This whole discussion also intersects with the general idea of using
> asserts to guide optimizations.
>
>
> ie in both cases, you are trying to give the compiler more information
> than it could reasonably figure out on its own.
>
> On Sun, Sep 25, 2016 at 4:22 PM, <mayorga.geek@gmail.com> wrote:
>
>>
>>
>> On Sunday, 25 September 2016 21:10:30 UTC+1, John Yates wrote:
>>>
>>> This thread is conflating HW branch history with other issues.
>>>
>>> likely / unlikely hints would not help a machine endowed with branch
>>> history HW predict a given branch once such a machine had executed that
>>> branch a few times.  Rather such a machine would rely on the contents o=
f
>>> its branch history table.
>>>
>>> That said, nearly every machine - no matter how tiny or massive -
>>> implements the simplistic heuristic that, in the absence of better
>>> information (either for lack of a branch history HW or because the bran=
ch
>>> being looked-up is not present in the history table), a backward branch=
 is
>>> predicted taken and a forward branch not taken.  Implementing that
>>> heuristic rarely requires nothing more than inspecting the sign of the
>>> PC-relative branch displacement.
>>>
>>> likely / unlikely keywords are more useful during compilation (as
>>> opposed to execution) since they enable more thoughtful basic block lay=
out,
>>> hopefully leading to better i-cache utilization.
>>>
>>> There is a vague analogy between a HW branch history table and
>>> profile-based optimization.  Profile collection is effectively a means =
of
>>> conveying execution history to the compilation toolchain.  Once that
>>> happens likely / unlikely hints in the source code become less valuable=
..
>>>
>>> I completely agree with this, once a profile is done and returned back
>> somehow to the compile can serve if done to emit warnings when the code
>> annotations in the code differs from execution statistic. But how many
>> programmers care of doing such analysis? I've seen none doing this. And =
I
>> manifest I don't even know if the compiler would take output from PBO fo=
r
>> regenerating new optimized assembly from the same sources which would be
>> nice if it could.
>>
>>
>>> /john
>>>
>>>
>>> On Sun, Sep 25, 2016 at 2:34 PM, Thiago Macieira <thi...@macieira.org>
>>> wrote:
>>>
>>>> On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:
>>>> > Everything involving a branch: if, while, for, switch, ?. Please whe=
n
>>>> > proposing these sort of things, keep in mind that the world is not
>>>> only
>>>> > x86. There are other archs that don't have branch predictors. That's
>>>> why an
>>>> > (ignorable) attribute is what should be, if at ever standarized.
>>>>
>>>> When you say "there are other archs that don't" (besides x86), you mea=
n
>>>> "most
>>>> archs do, but there are a couple of processor SKUs that don't". There
>>>> are
>>>> modern x86 that don't have pipelining or branch prediction (Quark MCUs=
)
>>>> and
>>>> most modern architectures do have that (ARM, MIPS, Sparc, POWER).
>>>>
>>>> --
>>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>>>    Software Architect - Intel Open Source Technology Center
>>>>
>>>> --
>>>> 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-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> To view this discussion on the web visit https://groups.google.com/a/i=
s
>>>> ocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjmaciei-mobl1.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-
>> 60510f63bad0%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1de36ac6-2=
a6b-4a26-85c3-60510f63bad0%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
>
> --
> Be seeing you,
> Tony
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAOHCbiu39NoLt-KHQxBDNPJTvT%
> 2BXah6Z8veQHYSK7UFcTnP-tw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu39N=
oLt-KHQxBDNPJTvT%2BXah6Z8veQHYSK7UFcTnP-tw%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp1fbTchoD17RuAVntG5NEC%3DJPcroiTWDmFJRhmxL=
WwyAg%40mail.gmail.com.

--001a1140fd9ec16913053d6bfcb9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>One of the key points from the perspective of SG14 is=
 that sometimes, optimizing for the common case conflicts with the needs of=
 a program, as there are some (that have been presented on that mailing lis=
t) where it is preferable that the uncommon path, when it is taken, is the =
one the binaries have been optimized for. It&#39;s one of the reasons why j=
ust letting the compiler do what it does best is not necessarily appropriat=
e sometimes.<br><br></div>Naming those attributes properly is something we&=
#39;re still working on (I wrote =C2=ABwe=C2=BB but I&#39;m mostly an obser=
ver on this one), but the group that met last Wednesday seemed of the opini=
on that since there are per-compiler [un]likely equivalents already, this w=
ould be a good way to start (better than inventing something before the des=
ign space has been fully explored). I expect those working on these proposa=
ls to come back eventually with other additions to the proposed set.<br></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-09-26 11:=
49 GMT-04:00 Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmai=
l.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span>:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div><div><div>This whole discussion al=
so intersects with the general idea of using asserts to guide optimizations=
..<br></div></div><br><br></div><div>ie in both cases, you are trying to giv=
e the compiler more information than it could reasonably figure out on its =
own.<br></div></div><div class=3D"gmail_extra"><div><div class=3D"h5"><br><=
div class=3D"gmail_quote">On Sun, Sep 25, 2016 at 4:22 PM,  <span dir=3D"lt=
r">&lt;<a href=3D"mailto:mayorga.geek@gmail.com" target=3D"_blank">mayorga.=
geek@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><span><br><br>On Sunday, 25 September 2016 21:10:30 UTC+1, Joh=
n Yates  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v style=3D"font-family:arial,helvetica,sans-serif">This thread is conflatin=
g HW branch history with other issues.</div><div style=3D"font-family:arial=
,helvetica,sans-serif"><br></div><div style=3D"font-family:arial,helvetica,=
sans-serif">likely / unlikely hints would not help a machine endowed with b=
ranch history HW predict a given branch once such a machine had executed th=
at branch a few times.=C2=A0 Rather such a machine would rely on the conten=
ts of its branch history table.</div><div style=3D"font-family:arial,helvet=
ica,sans-serif"><br></div><div style=3D"font-family:arial,helvetica,sans-se=
rif">That said, nearly every machine - no matter how tiny or massive - impl=
ements the simplistic heuristic that, in the absence of better information =
(either for lack of a branch history HW or because the branch being looked-=
up is not present in the history table), a backward branch is predicted tak=
en and a forward branch not taken.=C2=A0 Implementing that heuristic rarely=
 requires nothing more than inspecting the sign of the PC-relative branch d=
isplacement.</div><div style=3D"font-family:arial,helvetica,sans-serif"><br=
></div><div style=3D"font-family:arial,helvetica,sans-serif">likely / unlik=
ely=C2=A0keywords are more useful during compilation (as opposed to executi=
on) since they enable more thoughtful basic block layout, hopefully leading=
 to better i-cache utilization.</div><div style=3D"font-family:arial,helvet=
ica,sans-serif"><br></div><div style=3D"font-family:arial,helvetica,sans-se=
rif">There is a vague analogy between a HW branch history table and profile=
-based optimization.=C2=A0 Profile collection is effectively a means of con=
veying execution history to the compilation toolchain.=C2=A0 Once that happ=
ens likely / unlikely hints in the source code become less valuable.</div><=
div style=3D"font-family:arial,helvetica,sans-serif"><br></div></div></bloc=
kquote></span><div>I completely agree with this, once a profile is done and=
 returned back somehow to the compile can serve if done to emit warnings wh=
en the code annotations in the code differs from execution statistic. But h=
ow many programmers care of doing such analysis? I&#39;ve seen none doing t=
his. And I manifest I don&#39;t even know if the compiler would take output=
 from PBO for regenerating new optimized assembly from the same sources whi=
ch would be nice if it could.=C2=A0</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:arial,hel=
vetica,sans-serif"></div><div style=3D"font-family:arial,helvetica,sans-ser=
if">/john</div><div style=3D"font-family:arial,helvetica,sans-serif"><br></=
div></div><div><br><div class=3D"gmail_quote"><span>On Sun, Sep 25, 2016 at=
 2:34 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a rel=3D"nofollow">thi...@=
macieira.org</a>&gt;</span> wrote:<br></span><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><span>On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:<br>
&gt; Everything involving a branch: if, while, for, switch, ?. Please when<=
br>
&gt; proposing these sort of things, keep in mind that the world is not onl=
y<br>
&gt; x86. There are other archs that don&#39;t have branch predictors. That=
&#39;s why an<br>
&gt; (ignorable) attribute is what should be, if at ever standarized.<br>
<br>
When you say &quot;there are other archs that don&#39;t&quot; (besides x86)=
, you mean &quot;most<br>
archs do, but there are a couple of processor SKUs that don&#39;t&quot;. Th=
ere are<br>
modern x86 that don&#39;t have pipelining or branch prediction (Quark MCUs)=
 and<br>
most modern architectures do have that (ARM, MIPS, Sparc, POWER).<br>
</span><span><span><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"nofol=
low" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kd=
e.org" rel=3D"nofollow" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
</span><span>To view this discussion on the web visit <a href=3D"https://gr=
oups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjm=
aciei-mobl1" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a=
/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1755889.DcAR2TnsQj%40tjmaciei<w=
br>-mobl1</a>.<br>
</span></blockquote></div><br></div>
</blockquote></div><span>

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-60510f63bad0%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1de3=
6ac6-2a6b-4a26-85c3-<wbr>60510f63bad0%40isocpp.org</a>.<br>
</blockquote></div><br><br clear=3D"all"><br></div></div>-- <br><div data-s=
martmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>=
Tony<br></div></div>
</div><span class=3D"">

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu39NoLt-KHQxBDNPJTvT%2BXah6Z8v=
eQHYSK7UFcTnP-tw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAOHCbiu39NoLt-<wbr>KHQxBDNPJTvT%<wbr>2BXah6Z8veQHYSK7UFcT=
nP-tw%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1fbTchoD17RuAVntG5NEC%3DJPcroi=
TWDmFJRhmxLWwyAg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1fbTchoD=
17RuAVntG5NEC%3DJPcroiTWDmFJRhmxLWwyAg%40mail.gmail.com</a>.<br />

--001a1140fd9ec16913053d6bfcb9--

.

--94eb2c056fbabd7d4c053d6d9bea
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Tony,
I can understand how the compiler work based on its knowledge of arch
facts, but the compiler is not able to know what's in the programmer's
head, particularly when the knowledge comes from the side not the arch but
the application domain.
That is why I expect as a programmer the language suits me with a mean to
express this knowledge, then the compiler should combine all its inputs to
generate the best assembly.

Marcos


On 26 September 2016 at 16:49, Tony V E <tvaneerd@gmail.com> wrote:

> This whole discussion also intersects with the general idea of using
> asserts to guide optimizations.
>
>
> ie in both cases, you are trying to give the compiler more information
> than it could reasonably figure out on its own.
>
> On Sun, Sep 25, 2016 at 4:22 PM, <mayorga.geek@gmail.com> wrote:
>
>>
>>
>> On Sunday, 25 September 2016 21:10:30 UTC+1, John Yates wrote:
>>>
>>> This thread is conflating HW branch history with other issues.
>>>
>>> likely / unlikely hints would not help a machine endowed with branch
>>> history HW predict a given branch once such a machine had executed that
>>> branch a few times.  Rather such a machine would rely on the contents o=
f
>>> its branch history table.
>>>
>>> That said, nearly every machine - no matter how tiny or massive -
>>> implements the simplistic heuristic that, in the absence of better
>>> information (either for lack of a branch history HW or because the bran=
ch
>>> being looked-up is not present in the history table), a backward branch=
 is
>>> predicted taken and a forward branch not taken.  Implementing that
>>> heuristic rarely requires nothing more than inspecting the sign of the
>>> PC-relative branch displacement.
>>>
>>> likely / unlikely keywords are more useful during compilation (as
>>> opposed to execution) since they enable more thoughtful basic block lay=
out,
>>> hopefully leading to better i-cache utilization.
>>>
>>> There is a vague analogy between a HW branch history table and
>>> profile-based optimization.  Profile collection is effectively a means =
of
>>> conveying execution history to the compilation toolchain.  Once that
>>> happens likely / unlikely hints in the source code become less valuable=
..
>>>
>>> I completely agree with this, once a profile is done and returned back
>> somehow to the compile can serve if done to emit warnings when the code
>> annotations in the code differs from execution statistic. But how many
>> programmers care of doing such analysis? I've seen none doing this. And =
I
>> manifest I don't even know if the compiler would take output from PBO fo=
r
>> regenerating new optimized assembly from the same sources which would be
>> nice if it could.
>>
>>
>>> /john
>>>
>>>
>>> On Sun, Sep 25, 2016 at 2:34 PM, Thiago Macieira <thi...@macieira.org>
>>> wrote:
>>>
>>>> On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:
>>>> > Everything involving a branch: if, while, for, switch, ?. Please whe=
n
>>>> > proposing these sort of things, keep in mind that the world is not
>>>> only
>>>> > x86. There are other archs that don't have branch predictors. That's
>>>> why an
>>>> > (ignorable) attribute is what should be, if at ever standarized.
>>>>
>>>> When you say "there are other archs that don't" (besides x86), you mea=
n
>>>> "most
>>>> archs do, but there are a couple of processor SKUs that don't". There
>>>> are
>>>> modern x86 that don't have pipelining or branch prediction (Quark MCUs=
)
>>>> and
>>>> most modern architectures do have that (ARM, MIPS, Sparc, POWER).
>>>>
>>>> --
>>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>>>    Software Architect - Intel Open Source Technology Center
>>>>
>>>> --
>>>> 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-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> To view this discussion on the web visit https://groups.google.com/a/i=
s
>>>> ocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjmaciei-mobl1.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-
>> 60510f63bad0%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1de36ac6-2=
a6b-4a26-85c3-60510f63bad0%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
>
> --
> Be seeing you,
> Tony
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/LknWBhW0-RM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAOHCbiu39NoLt-KHQxBDNPJTvT%
> 2BXah6Z8veQHYSK7UFcTnP-tw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu39N=
oLt-KHQxBDNPJTvT%2BXah6Z8veQHYSK7UFcTnP-tw%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>



--=20
mm-studios.com
"un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo puedo
abonarlos."
follow my tweets at http://twitter.com/mayorga;
Marcos Mayorga. 9CEA 212C C9BC A7C1 D417  4B9A 859D FCA1 A159 49E2

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAEQMsGtfBoWq0DNHu7TVQVB2pkNC-WZT_m1DqnvD8MU502k=
ikQ%40mail.gmail.com.

--94eb2c056fbabd7d4c053d6d9bea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Tony,<div>I can understand how the compiler work based =
on its knowledge of arch facts, but the compiler is not able to know what&#=
39;s in the programmer&#39;s head, particularly when the knowledge comes fr=
om the side not the arch but the application domain.<div>That is why I expe=
ct as a programmer the language suits me with a mean to express this knowle=
dge, then the compiler should combine all its inputs to generate the best a=
ssembly.</div><div><br></div><div>Marcos</div><div><br></div></div></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 26 September 201=
6 at 16:49, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail=
..com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>This whole discussi=
on also intersects with the general idea of using asserts to guide optimiza=
tions.<br></div></div><br><br></div><div>ie in both cases, you are trying t=
o give the compiler more information than it could reasonably figure out on=
 its own.<br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote"><div><div class=3D"h5">On Sun, Sep 25, 2016 at 4:22 PM,  <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mayorga.geek@gmail.com" target=3D"_blank">ma=
yorga.geek@gmail.com</a>&gt;</span> wrote:<br></div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><span><br><br>On Sund=
ay, 25 September 2016 21:10:30 UTC+1, John Yates  wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:arial,hel=
vetica,sans-serif">This thread is conflating HW branch history with other i=
ssues.</div><div style=3D"font-family:arial,helvetica,sans-serif"><br></div=
><div style=3D"font-family:arial,helvetica,sans-serif">likely / unlikely hi=
nts would not help a machine endowed with branch history HW predict a given=
 branch once such a machine had executed that branch a few times.=C2=A0 Rat=
her such a machine would rely on the contents of its branch history table.<=
/div><div style=3D"font-family:arial,helvetica,sans-serif"><br></div><div s=
tyle=3D"font-family:arial,helvetica,sans-serif">That said, nearly every mac=
hine - no matter how tiny or massive - implements the simplistic heuristic =
that, in the absence of better information (either for lack of a branch his=
tory HW or because the branch being looked-up is not present in the history=
 table), a backward branch is predicted taken and a forward branch not take=
n.=C2=A0 Implementing that heuristic rarely requires nothing more than insp=
ecting the sign of the PC-relative branch displacement.</div><div style=3D"=
font-family:arial,helvetica,sans-serif"><br></div><div style=3D"font-family=
:arial,helvetica,sans-serif">likely / unlikely=C2=A0keywords are more usefu=
l during compilation (as opposed to execution) since they enable more thoug=
htful basic block layout, hopefully leading to better i-cache utilization.<=
/div><div style=3D"font-family:arial,helvetica,sans-serif"><br></div><div s=
tyle=3D"font-family:arial,helvetica,sans-serif">There is a vague analogy be=
tween a HW branch history table and profile-based optimization.=C2=A0 Profi=
le collection is effectively a means of conveying execution history to the =
compilation toolchain.=C2=A0 Once that happens likely / unlikely hints in t=
he source code become less valuable.</div><div style=3D"font-family:arial,h=
elvetica,sans-serif"><br></div></div></blockquote></span><div>I completely =
agree with this, once a profile is done and returned back somehow to the co=
mpile can serve if done to emit warnings when the code annotations in the c=
ode differs from execution statistic. But how many programmers care of doin=
g such analysis? I&#39;ve seen none doing this. And I manifest I don&#39;t =
even know if the compiler would take output from PBO for regenerating new o=
ptimized assembly from the same sources which would be nice if it could.=C2=
=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif"></div><div s=
tyle=3D"font-family:arial,helvetica,sans-serif">/john</div><div style=3D"fo=
nt-family:arial,helvetica,sans-serif"><br></div></div><div><br><div class=
=3D"gmail_quote"><span>On Sun, Sep 25, 2016 at 2:34 PM, Thiago Macieira <sp=
an dir=3D"ltr">&lt;<a rel=3D"nofollow">thi...@macieira.org</a>&gt;</span> w=
rote:<br></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><span>On domingo, 25 de sete=
mbro de 2016 09:46:56 PDT dgutson . wrote:<br>
&gt; Everything involving a branch: if, while, for, switch, ?. Please when<=
br>
&gt; proposing these sort of things, keep in mind that the world is not onl=
y<br>
&gt; x86. There are other archs that don&#39;t have branch predictors. That=
&#39;s why an<br>
&gt; (ignorable) attribute is what should be, if at ever standarized.<br>
<br>
When you say &quot;there are other archs that don&#39;t&quot; (besides x86)=
, you mean &quot;most<br>
archs do, but there are a couple of processor SKUs that don&#39;t&quot;. Th=
ere are<br>
modern x86 that don&#39;t have pipelining or branch prediction (Quark MCUs)=
 and<br>
most modern architectures do have that (ARM, MIPS, Sparc, POWER).<br>
</span><span><span><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"nofol=
low" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kd=
e.org" rel=3D"nofollow" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
</span><span>To view this discussion on the web visit <a href=3D"https://gr=
oups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjm=
aciei-mobl1" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a=
/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1755889.DcAR2TnsQj%40tjmaciei<w=
br>-mobl1</a>.<br>
</span></blockquote></div><br></div>
</blockquote></div></div></div><span><div><div class=3D"h5">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<span class=3D""><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></span></span><spa=
n class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-60510f63bad0%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1de3=
6ac6-2a6b-4a26-85c3-<wbr>60510f63bad0%40isocpp.org</a>.<br>
</span></blockquote></div><br><br clear=3D"all"><br>-- <br><div data-smartm=
ail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<=
br></div></div>
</div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/LknWBhW0-RM/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/L=
knWBhW0-RM/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu39NoLt-KHQxBDNPJTvT%2BXah6Z8v=
eQHYSK7UFcTnP-tw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAOHCbiu39NoLt-<wbr>KHQxBDNPJTvT%<wbr>2BXah6Z8veQHYSK7UFcT=
nP-tw%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><s=
pan style=3D"font-family:trebuchet ms,sans-serif"><font size=3D"4"><span st=
yle=3D"font-family:courier new,monospace"><a href=3D"http://mm-studios.com"=
 target=3D"_blank">mm-studios.com</a></span></font></span><br><div><span st=
yle=3D"font-family:trebuchet ms,sans-serif">&quot;un dia podr=C3=A9 pagarte=
 los servicios, hoy de momento tan solo puedo abonarlos.&quot;<br>follow my=
 tweets at <a href=3D"http://twitter.com/mayorga" target=3D"_blank">http://=
twitter.com/mayorga</a>;</span><span style=3D"font-family:trebuchet ms,sans=
-serif"><br>Marcos Mayorga. 9CEA 212C C9BC A7C1 D417=C2=A0 4B9A 859D FCA1 A=
159 49E2</span><br><span style=3D"font-family:trebuchet ms,sans-serif"></sp=
an><br></div></div></div>
</div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEQMsGtfBoWq0DNHu7TVQVB2pkNC-WZT_m1D=
qnvD8MU502kikQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEQMsGtfBoWq0DNH=
u7TVQVB2pkNC-WZT_m1DqnvD8MU502kikQ%40mail.gmail.com</a>.<br />

--94eb2c056fbabd7d4c053d6d9bea--

.

--089e014934ac73255b053d6f049d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes, exactly.

assert(start <=3D end);
assert(end <=3D 10000;

for (size_t i =3D start; i !=3D end; i++) // compiler need not worry about
wrapping
   etc();

The above might not be the best/correct example, but there are cases where
the compiler can optimize "for (int..." better than "for(size_t..." because
it needs to handle wrapping in one case (with int it can assume wrapping
doesn't happen, as it would be UB).

So asserts, and [[likely]] can both tell a compiler something it might
otherwise not know.



On Mon, Sep 26, 2016 at 2:50 PM, Marcos Mayorga <mayorga.geek@gmail.com>
wrote:

> Hi Tony,
> I can understand how the compiler work based on its knowledge of arch
> facts, but the compiler is not able to know what's in the programmer's
> head, particularly when the knowledge comes from the side not the arch bu=
t
> the application domain.
> That is why I expect as a programmer the language suits me with a mean to
> express this knowledge, then the compiler should combine all its inputs t=
o
> generate the best assembly.
>
> Marcos
>
>
> On 26 September 2016 at 16:49, Tony V E <tvaneerd@gmail.com> wrote:
>
>> This whole discussion also intersects with the general idea of using
>> asserts to guide optimizations.
>>
>>
>> ie in both cases, you are trying to give the compiler more information
>> than it could reasonably figure out on its own.
>>
>> On Sun, Sep 25, 2016 at 4:22 PM, <mayorga.geek@gmail.com> wrote:
>>
>>>
>>>
>>> On Sunday, 25 September 2016 21:10:30 UTC+1, John Yates wrote:
>>>>
>>>> This thread is conflating HW branch history with other issues.
>>>>
>>>> likely / unlikely hints would not help a machine endowed with branch
>>>> history HW predict a given branch once such a machine had executed tha=
t
>>>> branch a few times.  Rather such a machine would rely on the contents =
of
>>>> its branch history table.
>>>>
>>>> That said, nearly every machine - no matter how tiny or massive -
>>>> implements the simplistic heuristic that, in the absence of better
>>>> information (either for lack of a branch history HW or because the bra=
nch
>>>> being looked-up is not present in the history table), a backward branc=
h is
>>>> predicted taken and a forward branch not taken.  Implementing that
>>>> heuristic rarely requires nothing more than inspecting the sign of the
>>>> PC-relative branch displacement.
>>>>
>>>> likely / unlikely keywords are more useful during compilation (as
>>>> opposed to execution) since they enable more thoughtful basic block la=
yout,
>>>> hopefully leading to better i-cache utilization.
>>>>
>>>> There is a vague analogy between a HW branch history table and
>>>> profile-based optimization.  Profile collection is effectively a means=
 of
>>>> conveying execution history to the compilation toolchain.  Once that
>>>> happens likely / unlikely hints in the source code become less valuabl=
e.
>>>>
>>>> I completely agree with this, once a profile is done and returned back
>>> somehow to the compile can serve if done to emit warnings when the code
>>> annotations in the code differs from execution statistic. But how many
>>> programmers care of doing such analysis? I've seen none doing this. And=
 I
>>> manifest I don't even know if the compiler would take output from PBO f=
or
>>> regenerating new optimized assembly from the same sources which would b=
e
>>> nice if it could.
>>>
>>>
>>>> /john
>>>>
>>>>
>>>> On Sun, Sep 25, 2016 at 2:34 PM, Thiago Macieira <thi...@macieira.org>
>>>> wrote:
>>>>
>>>>> On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:
>>>>> > Everything involving a branch: if, while, for, switch, ?. Please wh=
en
>>>>> > proposing these sort of things, keep in mind that the world is not
>>>>> only
>>>>> > x86. There are other archs that don't have branch predictors. That'=
s
>>>>> why an
>>>>> > (ignorable) attribute is what should be, if at ever standarized.
>>>>>
>>>>> When you say "there are other archs that don't" (besides x86), you
>>>>> mean "most
>>>>> archs do, but there are a couple of processor SKUs that don't". There
>>>>> are
>>>>> modern x86 that don't have pipelining or branch prediction (Quark
>>>>> MCUs) and
>>>>> most modern architectures do have that (ARM, MIPS, Sparc, POWER).
>>>>>
>>>>> --
>>>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>>>>    Software Architect - Intel Open Source Technology Center
>>>>>
>>>>> --
>>>>> 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, sen=
d
>>>>> an email to std-proposal...@isocpp.org.
>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals
>>>>> /1755889.DcAR2TnsQj%40tjmaciei-mobl1.
>>>>>
>>>>
>>>> --
>>> 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.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-60510
>>> f63bad0%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1de36ac6-=
2a6b-4a26-85c3-60510f63bad0%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>
>>
>>
>> --
>> Be seeing you,
>> Tony
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>> ocpp.org/d/topic/std-proposals/LknWBhW0-RM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/CAOHCbiu39NoLt-KHQxBDNPJTvT%2
>> BXah6Z8veQHYSK7UFcTnP-tw%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu39=
NoLt-KHQxBDNPJTvT%2BXah6Z8veQHYSK7UFcTnP-tw%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
>
>
>
> --
> mm-studios.com
> "un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo puedo
> abonarlos."
> follow my tweets at http://twitter.com/mayorga;
> Marcos Mayorga. 9CEA 212C C9BC A7C1 D417  4B9A 859D FCA1 A159 49E2
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAEQMsGtfBoWq0DNHu7TVQVB2pkNC-
> WZT_m1DqnvD8MU502kikQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEQMsGtfBo=
Wq0DNHu7TVQVB2pkNC-WZT_m1DqnvD8MU502kikQ%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>
> .
>



--=20
Be seeing you,
Tony

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOHCbiuqZUE92Zr9OSBYt1jtHDO58TNWO4LFpEWYreF30U_=
8Dw%40mail.gmail.com.

--089e014934ac73255b053d6f049d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>Yes, exactly.<br><br></div><div>a=
ssert(start &lt;=3D end);<br></div>assert(end &lt;=3D 10000;<br><br></div>f=
or (size_t i =3D start; i !=3D end; i++) // compiler need not worry about w=
rapping<br></div>=C2=A0=C2=A0 etc();<br><br></div>The above might not be th=
e best/correct example, but there are cases where the compiler can optimize=
 &quot;for (int...&quot; better than &quot;for(size_t...&quot; because it n=
eeds to handle wrapping in one case (with int it can assume wrapping doesn&=
#39;t happen, as it would be UB).<br><br></div>So asserts, and [[likely]] c=
an both tell a compiler something it might otherwise not know.<br><br><br><=
div><div><div><div><div><div><div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Mon, Sep 26, 2016 at 2:50 PM, Marcos Mayorga <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mayorga.geek@gmail.com" target=3D"_blank">ma=
yorga.geek@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">Hi Tony,<div>I can understand how the compiler work base=
d on its knowledge of arch facts, but the compiler is not able to know what=
&#39;s in the programmer&#39;s head, particularly when the knowledge comes =
from the side not the arch but the application domain.<div>That is why I ex=
pect as a programmer the language suits me with a mean to express this know=
ledge, then the compiler should combine all its inputs to generate the best=
 assembly.</div><div><br></div><div>Marcos</div><div><br></div></div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div class=
=3D"h5">On 26 September 2016 at 16:49, Tony V E <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&g=
t;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div cl=
ass=3D"h5"><div dir=3D"ltr"><div><div><div>This whole discussion also inter=
sects with the general idea of using asserts to guide optimizations.<br></d=
iv></div><br><br></div><div>ie in both cases, you are trying to give the co=
mpiler more information than it could reasonably figure out on its own.<br>=
</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div>=
<div>On Sun, Sep 25, 2016 at 4:22 PM,  <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:mayorga.geek@gmail.com" target=3D"_blank">mayorga.geek@gmail.com</a>&gt=
;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><di=
v dir=3D"ltr"><span><br><br>On Sunday, 25 September 2016 21:10:30 UTC+1, Jo=
hn Yates  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv style=3D"font-family:arial,helvetica,sans-serif">This thread is conflati=
ng HW branch history with other issues.</div><div style=3D"font-family:aria=
l,helvetica,sans-serif"><br></div><div style=3D"font-family:arial,helvetica=
,sans-serif">likely / unlikely hints would not help a machine endowed with =
branch history HW predict a given branch once such a machine had executed t=
hat branch a few times.=C2=A0 Rather such a machine would rely on the conte=
nts of its branch history table.</div><div style=3D"font-family:arial,helve=
tica,sans-serif"><br></div><div style=3D"font-family:arial,helvetica,sans-s=
erif">That said, nearly every machine - no matter how tiny or massive - imp=
lements the simplistic heuristic that, in the absence of better information=
 (either for lack of a branch history HW or because the branch being looked=
-up is not present in the history table), a backward branch is predicted ta=
ken and a forward branch not taken.=C2=A0 Implementing that heuristic rarel=
y requires nothing more than inspecting the sign of the PC-relative branch =
displacement.</div><div style=3D"font-family:arial,helvetica,sans-serif"><b=
r></div><div style=3D"font-family:arial,helvetica,sans-serif">likely / unli=
kely=C2=A0keywords are more useful during compilation (as opposed to execut=
ion) since they enable more thoughtful basic block layout, hopefully leadin=
g to better i-cache utilization.</div><div style=3D"font-family:arial,helve=
tica,sans-serif"><br></div><div style=3D"font-family:arial,helvetica,sans-s=
erif">There is a vague analogy between a HW branch history table and profil=
e-based optimization.=C2=A0 Profile collection is effectively a means of co=
nveying execution history to the compilation toolchain.=C2=A0 Once that hap=
pens likely / unlikely hints in the source code become less valuable.</div>=
<div style=3D"font-family:arial,helvetica,sans-serif"><br></div></div></blo=
ckquote></span><div>I completely agree with this, once a profile is done an=
d returned back somehow to the compile can serve if done to emit warnings w=
hen the code annotations in the code differs from execution statistic. But =
how many programmers care of doing such analysis? I&#39;ve seen none doing =
this. And I manifest I don&#39;t even know if the compiler would take outpu=
t from PBO for regenerating new optimized assembly from the same sources wh=
ich would be nice if it could.=C2=A0</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:arial,he=
lvetica,sans-serif"></div><div style=3D"font-family:arial,helvetica,sans-se=
rif">/john</div><div style=3D"font-family:arial,helvetica,sans-serif"><br><=
/div></div><div><br><div class=3D"gmail_quote"><span>On Sun, Sep 25, 2016 a=
t 2:34 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a rel=3D"nofollow">thi...=
@macieira.org</a>&gt;</span> wrote:<br></span><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span>On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:<br=
>
&gt; Everything involving a branch: if, while, for, switch, ?. Please when<=
br>
&gt; proposing these sort of things, keep in mind that the world is not onl=
y<br>
&gt; x86. There are other archs that don&#39;t have branch predictors. That=
&#39;s why an<br>
&gt; (ignorable) attribute is what should be, if at ever standarized.<br>
<br>
When you say &quot;there are other archs that don&#39;t&quot; (besides x86)=
, you mean &quot;most<br>
archs do, but there are a couple of processor SKUs that don&#39;t&quot;. Th=
ere are<br>
modern x86 that don&#39;t have pipelining or branch prediction (Quark MCUs)=
 and<br>
most modern architectures do have that (ARM, MIPS, Sparc, POWER).<br>
</span><span><span><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"nofol=
low" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kd=
e.org" rel=3D"nofollow" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
</span><span>To view this discussion on the web visit <a href=3D"https://gr=
oups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjm=
aciei-mobl1" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a=
/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1755889.DcAR2TnsQj%40tjmaciei<w=
br>-mobl1</a>.<br>
</span></blockquote></div><br></div>
</blockquote></div></div></div><span><div><div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<span><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></span></span><spa=
n>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-60510f63bad0%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1de3=
6ac6-2a6b-4a26-85c3-60510<wbr>f63bad0%40isocpp.org</a>.<br>
</span></blockquote></div><br><br clear=3D"all"><br>-- <br><div data-smartm=
ail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<=
br></div></div>
</div></div></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/LknWBhW0-RM/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/L=
knWBhW0-RM/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span class=3D""><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></span></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu39NoLt-KHQxBDNPJTvT%2BXah6Z8v=
eQHYSK7UFcTnP-tw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAOHCbiu39NoLt-KHQxBDNPJTvT%2<wbr>BXah6Z8veQHYSK7UFcTnP-tw=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div data-sm=
artmail=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"font-family:tre=
buchet ms,sans-serif"><font size=3D"4"><span style=3D"font-family:courier n=
ew,monospace"><a href=3D"http://mm-studios.com" target=3D"_blank">mm-studio=
s.com</a></span></font></span><br><div><span style=3D"font-family:trebuchet=
 ms,sans-serif">&quot;un dia podr=C3=A9 pagarte los servicios, hoy de momen=
to tan solo puedo abonarlos.&quot;<br>follow my tweets at <a href=3D"http:/=
/twitter.com/mayorga" target=3D"_blank">http://twitter.com/mayorga</a>;</sp=
an><span style=3D"font-family:trebuchet ms,sans-serif"><br>Marcos Mayorga. =
9CEA 212C C9BC A7C1 D417=C2=A0 4B9A 859D FCA1 A159 49E2</span><br><span sty=
le=3D"font-family:trebuchet ms,sans-serif"></span><br></div></div></div>
</div><span class=3D"">

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEQMsGtfBoWq0DNHu7TVQVB2pkNC-WZT_m1D=
qnvD8MU502kikQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CAEQMsGtfBoWq0DNHu7TVQVB2pkNC-<wbr>WZT_m1DqnvD8MU502kik=
Q%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div></div></div></div></div></div></div></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuqZUE92Zr9OSBYt1jtHDO58TNWO4LF=
pEWYreF30U_8Dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuqZUE92Zr9=
OSBYt1jtHDO58TNWO4LFpEWYreF30U_8Dw%40mail.gmail.com</a>.<br />

--089e014934ac73255b053d6f049d--

.

--001a1137c0f21514f3053d7096d7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We shouldn't need to worry about adding assertions. That should be covered
quite thoroughly by the contracts proposal.

On Mon, Sep 26, 2016 at 3:31 PM, Tony V E <tvaneerd@gmail.com> wrote:

> Yes, exactly.
>
> assert(start <=3D end);
> assert(end <=3D 10000;
>
> for (size_t i =3D start; i !=3D end; i++) // compiler need not worry abou=
t
> wrapping
>    etc();
>
> The above might not be the best/correct example, but there are cases wher=
e
> the compiler can optimize "for (int..." better than "for(size_t..." becau=
se
> it needs to handle wrapping in one case (with int it can assume wrapping
> doesn't happen, as it would be UB).
>
> So asserts, and [[likely]] can both tell a compiler something it might
> otherwise not know.
>
>
>
>
> On Mon, Sep 26, 2016 at 2:50 PM, Marcos Mayorga <mayorga.geek@gmail.com>
> wrote:
>
>> Hi Tony,
>> I can understand how the compiler work based on its knowledge of arch
>> facts, but the compiler is not able to know what's in the programmer's
>> head, particularly when the knowledge comes from the side not the arch b=
ut
>> the application domain.
>> That is why I expect as a programmer the language suits me with a mean t=
o
>> express this knowledge, then the compiler should combine all its inputs =
to
>> generate the best assembly.
>>
>> Marcos
>>
>>
>> On 26 September 2016 at 16:49, Tony V E <tvaneerd@gmail.com> wrote:
>>
>>> This whole discussion also intersects with the general idea of using
>>> asserts to guide optimizations.
>>>
>>>
>>> ie in both cases, you are trying to give the compiler more information
>>> than it could reasonably figure out on its own.
>>>
>>> On Sun, Sep 25, 2016 at 4:22 PM, <mayorga.geek@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Sunday, 25 September 2016 21:10:30 UTC+1, John Yates wrote:
>>>>>
>>>>> This thread is conflating HW branch history with other issues.
>>>>>
>>>>> likely / unlikely hints would not help a machine endowed with branch
>>>>> history HW predict a given branch once such a machine had executed th=
at
>>>>> branch a few times.  Rather such a machine would rely on the contents=
 of
>>>>> its branch history table.
>>>>>
>>>>> That said, nearly every machine - no matter how tiny or massive -
>>>>> implements the simplistic heuristic that, in the absence of better
>>>>> information (either for lack of a branch history HW or because the br=
anch
>>>>> being looked-up is not present in the history table), a backward bran=
ch is
>>>>> predicted taken and a forward branch not taken.  Implementing that
>>>>> heuristic rarely requires nothing more than inspecting the sign of th=
e
>>>>> PC-relative branch displacement.
>>>>>
>>>>> likely / unlikely keywords are more useful during compilation (as
>>>>> opposed to execution) since they enable more thoughtful basic block l=
ayout,
>>>>> hopefully leading to better i-cache utilization.
>>>>>
>>>>> There is a vague analogy between a HW branch history table and
>>>>> profile-based optimization.  Profile collection is effectively a mean=
s of
>>>>> conveying execution history to the compilation toolchain.  Once that
>>>>> happens likely / unlikely hints in the source code become less valuab=
le.
>>>>>
>>>>> I completely agree with this, once a profile is done and returned bac=
k
>>>> somehow to the compile can serve if done to emit warnings when the cod=
e
>>>> annotations in the code differs from execution statistic. But how many
>>>> programmers care of doing such analysis? I've seen none doing this. An=
d I
>>>> manifest I don't even know if the compiler would take output from PBO =
for
>>>> regenerating new optimized assembly from the same sources which would =
be
>>>> nice if it could.
>>>>
>>>>
>>>>> /john
>>>>>
>>>>>
>>>>> On Sun, Sep 25, 2016 at 2:34 PM, Thiago Macieira <thi...@macieira.org=
>
>>>>> wrote:
>>>>>
>>>>>> On domingo, 25 de setembro de 2016 09:46:56 PDT dgutson . wrote:
>>>>>> > Everything involving a branch: if, while, for, switch, ?. Please
>>>>>> when
>>>>>> > proposing these sort of things, keep in mind that the world is not
>>>>>> only
>>>>>> > x86. There are other archs that don't have branch predictors.
>>>>>> That's why an
>>>>>> > (ignorable) attribute is what should be, if at ever standarized.
>>>>>>
>>>>>> When you say "there are other archs that don't" (besides x86), you
>>>>>> mean "most
>>>>>> archs do, but there are a couple of processor SKUs that don't". Ther=
e
>>>>>> are
>>>>>> modern x86 that don't have pipelining or branch prediction (Quark
>>>>>> MCUs) and
>>>>>> most modern architectures do have that (ARM, MIPS, Sparc, POWER).
>>>>>>
>>>>>> --
>>>>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>>>>>    Software Architect - Intel Open Source Technology Center
>>>>>>
>>>>>> --
>>>>>> 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-proposal...@isocpp.org.
>>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals
>>>>>> /1755889.DcAR2TnsQj%40tjmaciei-mobl1.
>>>>>>
>>>>>
>>>>> --
>>>> 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.
>>>> To view this discussion on the web visit https://groups.google.com/a/i=
s
>>>> ocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-60510
>>>> f63bad0%40isocpp.org
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1de36ac6=
-2a6b-4a26-85c3-60510f63bad0%40isocpp.org?utm_medium=3Demail&utm_source=3Df=
ooter>
>>>> .
>>>>
>>>
>>>
>>>
>>> --
>>> Be seeing you,
>>> Tony
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/a/is
>>> ocpp.org/d/topic/std-proposals/LknWBhW0-RM/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/CAOHCbiu39NoLt-KHQxBDNPJTvT%2
>>> BXah6Z8veQHYSK7UFcTnP-tw%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu3=
9NoLt-KHQxBDNPJTvT%2BXah6Z8veQHYSK7UFcTnP-tw%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
>>> .
>>>
>>
>>
>>
>> --
>> mm-studios.com
>> "un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo puedo
>> abonarlos."
>> follow my tweets at http://twitter.com/mayorga;
>> Marcos Mayorga. 9CEA 212C C9BC A7C1 D417  4B9A 859D FCA1 A159 49E2
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/CAEQMsGtfBoWq0DNHu7TVQVB2pkNC
>> -WZT_m1DqnvD8MU502kikQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEQMsGtfB=
oWq0DNHu7TVQVB2pkNC-WZT_m1DqnvD8MU502kikQ%40mail.gmail.com?utm_medium=3Dema=
il&utm_source=3Dfooter>
>> .
>>
>
>
>
> --
> Be seeing you,
> Tony
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAOHCbiuqZUE92Zr9OSBYt1jtHDO58
> TNWO4LFpEWYreF30U_8Dw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuqZU=
E92Zr9OSBYt1jtHDO58TNWO4LFpEWYreF30U_8Dw%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>
> .
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADbh%2BeROhaf-pij5Y_amWevYUVPc20haS%3Dza-ZQ1V%3=
DChTLcN0w%40mail.gmail.com.

--001a1137c0f21514f3053d7096d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">We shouldn&#39;t need to worry about adding assertions. Th=
at should be covered quite thoroughly by the contracts proposal.</div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Sep 26, 2016 a=
t 3:31 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.=
com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div><div>Yes, exact=
ly.<br><br></div><div>assert(start &lt;=3D end);<br></div>assert(end &lt;=
=3D 10000;<br><br></div>for (size_t i =3D start; i !=3D end; i++) // compil=
er need not worry about wrapping<br></div>=C2=A0=C2=A0 etc();<br><br></div>=
The above might not be the best/correct example, but there are cases where =
the compiler can optimize &quot;for (int...&quot; better than &quot;for(siz=
e_t...&quot; because it needs to handle wrapping in one case (with int it c=
an assume wrapping doesn&#39;t happen, as it would be UB).<br><br></div>So =
asserts, and [[likely]] can both tell a compiler something it might otherwi=
se not know.<div><div class=3D"h5"><br><br><br><div><div><div><div><div><di=
v><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Se=
p 26, 2016 at 2:50 PM, Marcos Mayorga <span dir=3D"ltr">&lt;<a href=3D"mail=
to:mayorga.geek@gmail.com" target=3D"_blank">mayorga.geek@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:1ex"><div dir=3D"ltr">Hi Tony,<=
div>I can understand how the compiler work based on its knowledge of arch f=
acts, but the compiler is not able to know what&#39;s in the programmer&#39=
;s head, particularly when the knowledge comes from the side not the arch b=
ut the application domain.<div>That is why I expect as a programmer the lan=
guage suits me with a mean to express this knowledge, then the compiler sho=
uld combine all its inputs to generate the best assembly.</div><div><br></d=
iv><div>Marcos</div><div><br></div></div></div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote"><div><div>On 26 September 2016 at 16:49, Tony=
 V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"=
_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br></div></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div><div><div dir=3D"ltr"><div><div><div>This whole di=
scussion also intersects with the general idea of using asserts to guide op=
timizations.<br></div></div><br><br></div><div>ie in both cases, you are tr=
ying to give the compiler more information than it could reasonably figure =
out on its own.<br></div></div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote"><div><div>On Sun, Sep 25, 2016 at 4:22 PM,  <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:mayorga.geek@gmail.com" target=3D"_blank">mayorga.ge=
ek@gmail.com</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div><div><div dir=3D"ltr"><span><br><br>On Sunday, 25 September 2016=
 21:10:30 UTC+1, John Yates  wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif">Thi=
s thread is conflating HW branch history with other issues.</div><div style=
=3D"font-family:arial,helvetica,sans-serif"><br></div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif">likely / unlikely hints would not help a m=
achine endowed with branch history HW predict a given branch once such a ma=
chine had executed that branch a few times.=C2=A0 Rather such a machine wou=
ld rely on the contents of its branch history table.</div><div style=3D"fon=
t-family:arial,helvetica,sans-serif"><br></div><div style=3D"font-family:ar=
ial,helvetica,sans-serif">That said, nearly every machine - no matter how t=
iny or massive - implements the simplistic heuristic that, in the absence o=
f better information (either for lack of a branch history HW or because the=
 branch being looked-up is not present in the history table), a backward br=
anch is predicted taken and a forward branch not taken.=C2=A0 Implementing =
that heuristic rarely requires nothing more than inspecting the sign of the=
 PC-relative branch displacement.</div><div style=3D"font-family:arial,helv=
etica,sans-serif"><br></div><div style=3D"font-family:arial,helvetica,sans-=
serif">likely / unlikely=C2=A0keywords are more useful during compilation (=
as opposed to execution) since they enable more thoughtful basic block layo=
ut, hopefully leading to better i-cache utilization.</div><div style=3D"fon=
t-family:arial,helvetica,sans-serif"><br></div><div style=3D"font-family:ar=
ial,helvetica,sans-serif">There is a vague analogy between a HW branch hist=
ory table and profile-based optimization.=C2=A0 Profile collection is effec=
tively a means of conveying execution history to the compilation toolchain.=
=C2=A0 Once that happens likely / unlikely hints in the source code become =
less valuable.</div><div style=3D"font-family:arial,helvetica,sans-serif"><=
br></div></div></blockquote></span><div>I completely agree with this, once =
a profile is done and returned back somehow to the compile can serve if don=
e to emit warnings when the code annotations in the code differs from execu=
tion statistic. But how many programmers care of doing such analysis? I&#39=
;ve seen none doing this. And I manifest I don&#39;t even know if the compi=
ler would take output from PBO for regenerating new optimized assembly from=
 the same sources which would be nice if it could.=C2=A0</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"=
font-family:arial,helvetica,sans-serif"></div><div style=3D"font-family:ari=
al,helvetica,sans-serif">/john</div><div style=3D"font-family:arial,helveti=
ca,sans-serif"><br></div></div><div><br><div class=3D"gmail_quote"><span>On=
 Sun, Sep 25, 2016 at 2:34 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a rel=
=3D"nofollow">thi...@macieira.org</a>&gt;</span> wrote:<br></span><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><span>On domingo, 25 de setembro de 2016 09:46:56 PDT=
 dgutson . wrote:<br>
&gt; Everything involving a branch: if, while, for, switch, ?. Please when<=
br>
&gt; proposing these sort of things, keep in mind that the world is not onl=
y<br>
&gt; x86. There are other archs that don&#39;t have branch predictors. That=
&#39;s why an<br>
&gt; (ignorable) attribute is what should be, if at ever standarized.<br>
<br>
When you say &quot;there are other archs that don&#39;t&quot; (besides x86)=
, you mean &quot;most<br>
archs do, but there are a couple of processor SKUs that don&#39;t&quot;. Th=
ere are<br>
modern x86 that don&#39;t have pipelining or branch prediction (Quark MCUs)=
 and<br>
most modern architectures do have that (ARM, MIPS, Sparc, POWER).<br>
</span><span><span><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"nofol=
low" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kd=
e.org" rel=3D"nofollow" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
</span><span>To view this discussion on the web visit <a href=3D"https://gr=
oups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjm=
aciei-mobl1" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a=
/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1755889.DcAR2TnsQj%40tjmaciei<w=
br>-mobl1</a>.<br>
</span></blockquote></div><br></div>
</blockquote></div></div></div><span><div><div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<span><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></span></span><spa=
n>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-60510f63bad0%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1de3=
6ac6-2a6b-4a26-85c3-60510<wbr>f63bad0%40isocpp.org</a>.<br>
</span></blockquote></div><br><br clear=3D"all"><br>-- <br><div data-smartm=
ail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<=
br></div></div>
</div></div></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/LknWBhW0-RM/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/L=
knWBhW0-RM/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span><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></span></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu39NoLt-KHQxBDNPJTvT%2BXah6Z8v=
eQHYSK7UFcTnP-tw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAOHCbiu39NoLt-KHQxBDNPJTvT%2<wbr>BXah6Z8veQHYSK7UFcTnP-tw=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div data-sm=
artmail=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"font-family:tre=
buchet ms,sans-serif"><font size=3D"4"><span style=3D"font-family:courier n=
ew,monospace"><a href=3D"http://mm-studios.com" target=3D"_blank">mm-studio=
s.com</a></span></font></span><br><div><span style=3D"font-family:trebuchet=
 ms,sans-serif">&quot;un dia podr=C3=A9 pagarte los servicios, hoy de momen=
to tan solo puedo abonarlos.&quot;<br>follow my tweets at <a href=3D"http:/=
/twitter.com/mayorga" target=3D"_blank">http://twitter.com/mayorga</a>;</sp=
an><span style=3D"font-family:trebuchet ms,sans-serif"><br>Marcos Mayorga. =
9CEA 212C C9BC A7C1 D417=C2=A0 4B9A 859D FCA1 A159 49E2</span><br><span sty=
le=3D"font-family:trebuchet ms,sans-serif"></span><br></div></div></div>
</div><span>

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEQMsGtfBoWq0DNHu7TVQVB2pkNC-WZT_m1D=
qnvD8MU502kikQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-=
proposals<wbr>/CAEQMsGtfBoWq0DNHu7TVQVB2pkNC<wbr>-WZT_m1DqnvD8MU502kikQ%40m=
ail.<wbr>gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div data-smartmail=3D"=
gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></di=
v></div>
</div></div></div></div></div></div></div></div></div></div></div><div><div=
 class=3D"h5">

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuqZUE92Zr9OSBYt1jtHDO58TNWO4LF=
pEWYreF30U_8Dw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CAOHCbiuqZUE92Zr9OSBYt1jtHDO58<wbr>TNWO4LFpEWYreF30U_8D=
w%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeROhaf-pij5Y_amWevYUVPc20haS%=
3Dza-ZQ1V%3DChTLcN0w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeRO=
haf-pij5Y_amWevYUVPc20haS%3Dza-ZQ1V%3DChTLcN0w%40mail.gmail.com</a>.<br />

--001a1137c0f21514f3053d7096d7--

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">A proposal author should just explore possible interactions bet=
ween the proposals, and at least mention how they relate. Even if the resul=
t is just "they are vaguely similar, but essentially separate, and thus not=
 explored further".</div><div style=3D"width: 100%; font-size: initial; fon=
t-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, =
125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div=
>                                                                          =
                                                           <div style=3D"wi=
dth: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-seri=
f, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-col=
or: rgb(255, 255, 255);"><br style=3D"display:initial"></div>              =
                                                                           =
                                                                           =
                               <div style=3D"font-size: initial; font-famil=
y: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); t=
ext-align: initial; background-color: rgb(255, 255, 255);">Sent&nbsp;from&n=
bsp;my&nbsp;BlackBerry&nbsp;portable&nbsp;Babbage&nbsp;Device</div>        =
                                                                           =
                                                                           =
                    <table width=3D"100%" style=3D"background-color:white;b=
order-spacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-size: initi=
al; text-align: initial; background-color: rgb(255, 255, 255);">           =
                <div style=3D"border-style: solid none none; border-top-col=
or: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-f=
amily: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>Fr=
om: </b>Brittany Friedman</div><div><b>Sent: </b>Monday, September 26, 2016=
 6:24 PM</div><div><b>To: </b>std-proposals@isocpp.org</div><div><b>Reply T=
o: </b>std-proposals@isocpp.org</div><div><b>Subject: </b>Re: [std-proposal=
s] branch predictor</div></div></td></tr></tbody></table><div style=3D"bord=
er-style: solid none none; border-top-color: rgb(186, 188, 209); border-top=
-width: 1pt; font-size: initial; text-align: initial; background-color: rgb=
(255, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""><div di=
r=3D"ltr">We shouldn't need to worry about adding assertions. That should b=
e covered quite thoroughly by the contracts proposal.</div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Mon, Sep 26, 2016 at 3:31 PM, =
Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=
=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><div><div><div><div>Yes, exactly.<br><b=
r></div><div>assert(start &lt;=3D end);<br></div>assert(end &lt;=3D 10000;<=
br><br></div>for (size_t i =3D start; i !=3D end; i++) // compiler need not=
 worry about wrapping<br></div>&nbsp;&nbsp; etc();<br><br></div>The above m=
ight not be the best/correct example, but there are cases where the compile=
r can optimize "for (int..." better than "for(size_t..." because it needs t=
o handle wrapping in one case (with int it can assume wrapping doesn't happ=
en, as it would be UB).<br><br></div>So asserts, and [[likely]] can both te=
ll a compiler something it might otherwise not know.<div><div class=3D"h5">=
<br><br><br><div><div><div><div><div><div><div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Mon, Sep 26, 2016 at 2:50 PM, Marcos Mayor=
ga <span dir=3D"ltr">&lt;<a href=3D"mailto:mayorga.geek@gmail.com" target=
=3D"_blank">mayorga.geek@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">Hi Tony,<div>I can understand how the comp=
iler work based on its knowledge of arch facts, but the compiler is not abl=
e to know what's in the programmer's head, particularly when the knowledge =
comes from the side not the arch but the application domain.<div>That is wh=
y I expect as a programmer the language suits me with a mean to express thi=
s knowledge, then the compiler should combine all its inputs to generate th=
e best assembly.</div><div><br></div><div>Marcos</div><div><br></div></div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div>O=
n 26 September 2016 at 16:49, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span>=
 wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D=
"ltr"><div><div><div>This whole discussion also intersects with the general=
 idea of using asserts to guide optimizations.<br></div></div><br><br></div=
><div>ie in both cases, you are trying to give the compiler more informatio=
n than it could reasonably figure out on its own.<br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div>On Sun, Sep 25, 2=
016 at 4:22 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:mayorga.geek@gmail=
..com" target=3D"_blank">mayorga.geek@gmail.com</a>&gt;</span> wrote:<br></d=
iv></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr"><span><b=
r><br>On Sunday, 25 September 2016 21:10:30 UTC+1, John Yates  wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-famil=
y:arial,helvetica,sans-serif">This thread is conflating HW branch history w=
ith other issues.</div><div style=3D"font-family:arial,helvetica,sans-serif=
"><br></div><div style=3D"font-family:arial,helvetica,sans-serif">likely / =
unlikely hints would not help a machine endowed with branch history HW pred=
ict a given branch once such a machine had executed that branch a few times=
..&nbsp; Rather such a machine would rely on the contents of its branch hist=
ory table.</div><div style=3D"font-family:arial,helvetica,sans-serif"><br><=
/div><div style=3D"font-family:arial,helvetica,sans-serif">That said, nearl=
y every machine - no matter how tiny or massive - implements the simplistic=
 heuristic that, in the absence of better information (either for lack of a=
 branch history HW or because the branch being looked-up is not present in =
the history table), a backward branch is predicted taken and a forward bran=
ch not taken.&nbsp; Implementing that heuristic rarely requires nothing mor=
e than inspecting the sign of the PC-relative branch displacement.</div><di=
v style=3D"font-family:arial,helvetica,sans-serif"><br></div><div style=3D"=
font-family:arial,helvetica,sans-serif">likely / unlikely&nbsp;keywords are=
 more useful during compilation (as opposed to execution) since they enable=
 more thoughtful basic block layout, hopefully leading to better i-cache ut=
ilization.</div><div style=3D"font-family:arial,helvetica,sans-serif"><br><=
/div><div style=3D"font-family:arial,helvetica,sans-serif">There is a vague=
 analogy between a HW branch history table and profile-based optimization.&=
nbsp; Profile collection is effectively a means of conveying execution hist=
ory to the compilation toolchain.&nbsp; Once that happens likely / unlikely=
 hints in the source code become less valuable.</div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif"><br></div></div></blockquote></span><div>I =
completely agree with this, once a profile is done and returned back someho=
w to the compile can serve if done to emit warnings when the code annotatio=
ns in the code differs from execution statistic. But how many programmers c=
are of doing such analysis? I've seen none doing this. And I manifest I don=
't even know if the compiler would take output from PBO for regenerating ne=
w optimized assembly from the same sources which would be nice if it could.=
&nbsp;</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif"></div><div=
 style=3D"font-family:arial,helvetica,sans-serif">/john</div><div style=3D"=
font-family:arial,helvetica,sans-serif"><br></div></div><div><br><div class=
=3D"gmail_quote"><span>On Sun, Sep 25, 2016 at 2:34 PM, Thiago Macieira <sp=
an dir=3D"ltr">&lt;<a rel=3D"nofollow">thi...@macieira.org</a>&gt;</span> w=
rote:<br></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><span>On domingo, 25 de sete=
mbro de 2016 09:46:56 PDT dgutson . wrote:<br>
&gt; Everything involving a branch: if, while, for, switch, ?. Please when<=
br>
&gt; proposing these sort of things, keep in mind that the world is not onl=
y<br>
&gt; x86. There are other archs that don't have branch predictors. That's w=
hy an<br>
&gt; (ignorable) attribute is what should be, if at ever standarized.<br>
<br>
When you say "there are other archs that don't" (besides x86), you mean "mo=
st<br>
archs do, but there are a couple of processor SKUs that don't". There are<b=
r>
modern x86 that don't have pipelining or branch prediction (Quark MCUs) and=
<br>
most modern architectures do have that (ARM, MIPS, Sparc, POWER).<br>
</span><span><span><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"nofol=
low" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kd=
e.org" rel=3D"nofollow" target=3D"_blank">kde.org</a><br>
&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
</span><span>To view this discussion on the web visit <a href=3D"https://gr=
oups.google.com/a/isocpp.org/d/msgid/std-proposals/1755889.DcAR2TnsQj%40tjm=
aciei-mobl1" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a=
/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1755889.DcAR2TnsQj%40tjmaciei<w=
br>-mobl1</a>.<br>
</span></blockquote></div><br></div>
</blockquote></div></div></div><span><div><div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<span><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></span></span><spa=
n>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1de36ac6-2a6b-4a26-85c3-60510f63bad0%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1de3=
6ac6-2a6b-4a26-85c3-60510<wbr>f63bad0%40isocpp.org</a>.<br>
</span></blockquote></div><br><br clear=3D"all"><br>-- <br><div data-smartm=
ail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<=
br></div></div>
</div></div></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/LknWBhW0-RM/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/L=
knWBhW0-RM/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isoc<wbr>pp.org</a>.<span><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></span></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu39NoLt-KHQxBDNPJTvT%2BXah6Z8v=
eQHYSK7UFcTnP-tw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CAOHCbiu39NoLt-KHQxBDNPJTvT%2<wbr>BXah6Z8veQHYSK7UFcTnP-tw=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div data-sm=
artmail=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"font-family:tre=
buchet ms,sans-serif"><font size=3D"4"><span style=3D"font-family:courier n=
ew,monospace"><a href=3D"http://mm-studios.com" target=3D"_blank">mm-studio=
s.com</a></span></font></span><br><div><span style=3D"font-family:trebuchet=
 ms,sans-serif">"un dia podr=C3=A9 pagarte los servicios, hoy de momento ta=
n solo puedo abonarlos."<br>follow my tweets at <a href=3D"http://twitter.c=
om/mayorga" target=3D"_blank">http://twitter.com/mayorga</a>;</span><span s=
tyle=3D"font-family:trebuchet ms,sans-serif"><br>Marcos Mayorga. 9CEA 212C =
C9BC A7C1 D417&nbsp; 4B9A 859D FCA1 A159 49E2</span><br><span style=3D"font=
-family:trebuchet ms,sans-serif"></span><br></div></div></div>
</div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEQMsGtfBoWq0DNHu7TVQVB2pkNC-WZT_m1D=
qnvD8MU502kikQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-=
proposals<wbr>/CAEQMsGtfBoWq0DNHu7TVQVB2pkNC<wbr>-WZT_m1DqnvD8MU502kikQ%40m=
ail.<wbr>gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div data-smartmail=3D"=
gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></di=
v></div>
</div></div></div></div></div></div></div></div></div></div></div><div><div=
 class=3D"h5">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuqZUE92Zr9OSBYt1jtHDO58TNWO4LF=
pEWYreF30U_8Dw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CAOHCbiuqZUE92Zr9OSBYt1jtHDO58<wbr>TNWO4LFpEWYreF30U_8D=
w%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeROhaf-pij5Y_amWevYUVPc20haS%=
3Dza-ZQ1V%3DChTLcN0w%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2=
BeROhaf-pij5Y_amWevYUVPc20haS%3Dza-ZQ1V%3DChTLcN0w%40mail.gmail.com</a>.<br=
>
<br><!--end of _originalContent --></div></body></html>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20160926225544.4919374.96608.17492%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20160926225544.4919374.96608.17492%40gm=
ail.com</a>.<br />

.

------=_Part_1941_1247331124.1474976206186
Content-Type: multipart/alternative;
 boundary="----=_Part_1942_1264518425.1474976206186"

------=_Part_1942_1264518425.1474976206186
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2016=E5=B9=B49=E6=9C=8825=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 UTC=
+8=E4=B8=8B=E5=8D=888:47:03=EF=BC=8Cdgutson=E5=86=99=E9=81=93=EF=BC=9A
>
> El 25/9/2016 9:36, "Andrey Semashev" <andrey....@gmail.com <javascript:>>=
=20
> escribi=C3=B3:
> >
> > On 09/25/16 13:11, mayorg...@gmail.com <javascript:> wrote:
> >>
> >> Hello,
> >>
> >> I am spinning around the idea of the possibility of submitting a
> >> language change proposal to expose to the programmer with keywords to
> >> hint the compiler in its optimization.
> >>
> >> AFAIK the feature is not currently covered at language level and it is
> >> IMHO sufficiently generic.
> >>
> >> As an example it would be applicable to the singleton pattern, somethi=
ng
> >> like:
> >>
> >> T* singleton::get_instance() {
> >>    if (p=3D=3D0) unlikely {
> >>       p =3D new singleton();
> >>    }
> >>    return p;
> >> }
> >>
> >> notice the new keyword "unlikely" which can be used by e.g. g++ to use
> >> its __builtin_expect branch optimizer.
> >>
> >> I would like to check if this sounds like a feasible proposal.
> >
> >
> > I like the idea but I would suggest a different syntax:
> >
> >
> >   T* singleton::get_instance() {
> >      if (p=3D=3D0) {
> >         [[unlikely]]
> >         p =3D new singleton();
> >      }
> >      return p;
> >   }
> >
> > The attribute would apply to the branch associated with the statement=
=20
> following the attribute. This allows (a) to ignore the attribute if the=
=20
> compiler doesn't support it and (b) use the attribute in other contexts.=
=20
> For example:
>
> Everything involving a branch: if, while, for, switch, ?. Please when=20
> proposing these sort of things, keep in mind that the world is not only=
=20
> x86. There are other archs that don't have branch predictors. That's why =
an=20
> (ignorable) attribute is what should be, if at ever standarized.
>
Certain language constructs can, but not need to involve a branch. Note=20
branch is not yet defined in the language.

Branch predictors have nothing need to do with architectures. Hardware=20
implementations are usually microarchitecture-specific. Many=20
implementations other than x86 also have them.

I don't see it should be proposed in a hardware-aware way.

>
> >   switch (x) {
> >   case 1:
> >     // branch with no probability hints
> >     foo();
> >     break;
> >
> >   case 2:
> >     // the most probable branch
> >     [[likely]]
> >     bar();
> >     break;
> >
> >   default:
> >     // the least probable branch
> >     [[unlikely]]
> >     throw std::invalid_argument("unsupported x");
> >   }
> >
> > or:
> >
> >   for (int i =3D 0; i < n; ++i)
> >   {
> >     // Most often n <=3D 0, the loop is rarely executed
> >     [[unlikely]]
> >     baz();
> >   }
> >
> > or:
> >
> >   // The function is unlikely to be called ("cold" function)
> >   [[unlikely]] void handle_error();
> >
> >   // The function is expected to be called often ("hot" function)
> >   [[likely]] void process_data();
> >
> >
> >
> > --=20
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
> > To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2994274-139=
f-96b0-3ebd-36d19311709b%40gmail.com
> .
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d57e43eb-988f-4bcd-9d9c-aa212c803aeb%40isocpp.or=
g.

------=_Part_1942_1264518425.1474976206186
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=8825=E6=97=A5=E6=98=
=9F=E6=9C=9F=E6=97=A5 UTC+8=E4=B8=8B=E5=8D=888:47:03=EF=BC=8Cdgutson=E5=86=
=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D=
"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 9:36, &quot;Andrey Semashev&quot; &lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"UlKGa0RiBAAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">andrey....@g=
mail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; On 09/25/16 13:11, <a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"UlKGa0RiBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">mayorg...@gmail.com</a> wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hello,<br>
&gt;&gt;<br>
&gt;&gt; I am spinning around the idea of the possibility of submitting a<b=
r>
&gt;&gt; language change proposal to expose to the programmer with keywords=
 to<br>
&gt;&gt; hint the compiler in its optimization.<br>
&gt;&gt;<br>
&gt;&gt; AFAIK the feature is not currently covered at language level and i=
t is<br>
&gt;&gt; IMHO sufficiently generic.<br>
&gt;&gt;<br>
&gt;&gt; As an example it would be applicable to the singleton pattern, som=
ething<br>
&gt;&gt; like:<br>
&gt;&gt;<br>
&gt;&gt; T* singleton::get_instance() {<br>
&gt;&gt; =C2=A0 =C2=A0if (p=3D=3D0) unlikely {<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0 p =3D new singleton();<br>
&gt;&gt; =C2=A0 =C2=A0}<br>
&gt;&gt; =C2=A0 =C2=A0return p;<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt; notice the new keyword &quot;unlikely&quot; which can be used by e=
..g. g++ to use<br>
&gt;&gt; its __builtin_expect branch optimizer.<br>
&gt;&gt;<br>
&gt;&gt; I would like to check if this sounds like a feasible proposal.<br>
&gt;<br>
&gt;<br>
&gt; I like the idea but I would suggest a different syntax:<br>
&gt;<br>
&gt;<br>
&gt; =C2=A0 T* singleton::get_instance() {<br>
&gt; =C2=A0 =C2=A0 =C2=A0if (p=3D=3D0) {<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 [[unlikely]]<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 p =3D new singleton();<br>
&gt; =C2=A0 =C2=A0 =C2=A0}<br>
&gt; =C2=A0 =C2=A0 =C2=A0return p;<br>
&gt; =C2=A0 }<br>
&gt;<br>
&gt; The attribute would apply to the branch associated with the statement =
following the attribute. This allows (a) to ignore the attribute if the com=
piler doesn&#39;t support it and (b) use the attribute in other contexts. F=
or example:</p>
<p dir=3D"ltr">Everything involving a branch: if, while, for, switch, ?. Pl=
ease when proposing these sort of things, keep in mind that the world is no=
t only x86. There are other archs that don&#39;t have branch predictors. Th=
at&#39;s why an (ignorable) attribute is what should be, if at ever standar=
ized.<br></p></blockquote><div>Certain language constructs can, but not nee=
d to involve a branch. Note branch is not yet defined in the language.<br><=
br>Branch predictors have nothing need to do with architectures. Hardware i=
mplementations are usually microarchitecture-specific. Many implementations=
 other than x86 also have them.<br><br>I don&#39;t see it should be propose=
d in a hardware-aware way.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><p dir=3D"ltr"></p>
<p dir=3D"ltr">&gt;<br>
&gt; =C2=A0 switch (x) {<br>
&gt; =C2=A0 case 1:<br>
&gt; =C2=A0 =C2=A0 // branch with no probability hints<br>
&gt; =C2=A0 =C2=A0 foo();<br>
&gt; =C2=A0 =C2=A0 break;<br>
&gt;<br>
&gt; =C2=A0 case 2:<br>
&gt; =C2=A0 =C2=A0 // the most probable branch<br>
&gt; =C2=A0 =C2=A0 [[likely]]<br>
&gt; =C2=A0 =C2=A0 bar();<br>
&gt; =C2=A0 =C2=A0 break;<br>
&gt;<br>
&gt; =C2=A0 default:<br>
&gt; =C2=A0 =C2=A0 // the least probable branch<br>
&gt; =C2=A0 =C2=A0 [[unlikely]]<br>
&gt; =C2=A0 =C2=A0 throw std::invalid_argument(&quot;<wbr>unsupported x&quo=
t;);<br>
&gt; =C2=A0 }<br>
&gt;<br>
&gt; or:<br>
&gt;<br>
&gt; =C2=A0 for (int i =3D 0; i &lt; n; ++i)<br>
&gt; =C2=A0 {<br>
&gt; =C2=A0 =C2=A0 // Most often n &lt;=3D 0, the loop is rarely executed<b=
r>
&gt; =C2=A0 =C2=A0 [[unlikely]]<br>
&gt; =C2=A0 =C2=A0 baz();<br>
&gt; =C2=A0 }<br>
&gt;<br>
&gt; or:<br>
&gt;<br>
&gt; =C2=A0 // The function is unlikely to be called (&quot;cold&quot; func=
tion)<br>
&gt; =C2=A0 [[unlikely]] void handle_error();<br>
&gt;<br>
&gt; =C2=A0 // The function is expected to be called often (&quot;hot&quot;=
 function)<br>
&gt; =C2=A0 [[likely]] void process_data();<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"UlKGa0RiBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">std-proposal...@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"UlKGa0RiBAAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/b2994274-139f-96b0-3ebd-36d19311=
709b%40gmail.com" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b299=
4274-139f-96b0-3ebd-36d19311709b%40gmail.com&#39;;return true;" onclick=3D"=
this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/b2994274-139f-96b0-3ebd-36d19311709b%40gmail.com&#39;;return true;">http=
s://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/b2994274=
-139f-96b0-<wbr>3ebd-36d19311709b%40gmail.com</a>.<br></p>
</blockquote></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d57e43eb-988f-4bcd-9d9c-aa212c803aeb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d57e43eb-988f-4bcd-9d9c-aa212c803aeb=
%40isocpp.org</a>.<br />

------=_Part_1942_1264518425.1474976206186--

------=_Part_1941_1247331124.1474976206186--

.

------=_Part_16_10385498.1474977107553
Content-Type: multipart/alternative;
 boundary="----=_Part_17_422511554.1474977107554"

------=_Part_17_422511554.1474977107554
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2016=E5=B9=B49=E6=9C=8825=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 UTC=
+8=E4=B8=8B=E5=8D=889:50:10=EF=BC=8Cdgutson=E5=86=99=E9=81=93=EF=BC=9A
>
> El 25/9/2016 10:45, "'Bernd L=C3=B6rwald' via ISO C++ Standard - Future=
=20
> Proposals" <std-pr...@isocpp.org <javascript:>> escribi=C3=B3:
> >
> >
> > > But why a standard attribute? Go to your compiler vendor and ask to=
=20
> provide an attribute. Think in portability.
> > > So my question remains: why an architecture-specific feature should b=
e=20
> standard, when the language provides the syntax? Please answer.
> >
> > Why is this attribute architecture-specific? The compiler may as well=
=20
> use the attribute for optimization of code locality, having the common=20
> branch be closer. It is obviously implementation and platform specific as=
=20
> to what extend the hint can be used.
>
> Isn't code locality also applicable to architectures that have icache,=20
> again thinking in x86 and therefore yet another example of arch-specific?=
=20
> If so I can think of many architectures where this feature would be non=
=20
> applicable. I still don't see the point to make this standard.
>
I'm sure you've got something wrong. IA-32 even does not mandate icache to=
=20
be available architecturally; only some (optional) CPUID leaf=20
functions/non-architectural performance counter events/some vendor-specific=
=20
technology would expose its existence. So things concerned here are=20
definitely not arch-specific, but more detailed in implementations.

However, anyway, it is not the topic here. You are misguided by the title.=
=20
Something called "branch predictor" is not directly related to the HW impl,=
=20
even it usually is.

>
> > I would extend this to be more than [[likely]] and [[unlikely]] but=20
> [[branch_probability: (likely|unlikely|value that must add up to 1.0 acro=
ss=20
> all branches)]] which might be more than current generation of compilers=
=20
> and architecture can handle (the probability values case), but seems more=
=20
> flexible and only adds one attribute with argument rather than two=20
> attributes. The name may also include =E2=80=9Ehint=E2=80=9C to make it e=
xplicit this is=20
> only an optimization and may not have any effect.
>
> And I like your idea, but for an x86 compiler vendor :)
>
> >
> > --
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
> > To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/716602A1-555=
6-4D1C-93BF-A0B2F58001CB%40googlemail.com
> .
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3918638f-283d-4c38-a97a-951e54993f66%40isocpp.or=
g.

------=_Part_17_422511554.1474977107554
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=8825=E6=97=A5=E6=98=
=9F=E6=9C=9F=E6=97=A5 UTC+8=E4=B8=8B=E5=8D=889:50:10=EF=BC=8Cdgutson=E5=86=
=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D=
"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 10:45, &quot;&#39;Bernd L=C3=B6rwald&#39; via I=
SO C++ Standard - Future Proposals&quot; &lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"Sj-ASbZlBAAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>&gt; escrib=
i=C3=B3:<br>
&gt;<br>
&gt;<br>
&gt; &gt; But why a standard attribute? Go to your compiler vendor and ask =
to provide an attribute. Think in portability.<br>
&gt; &gt; So my question remains: why an architecture-specific feature shou=
ld be standard, when the language provides the syntax? Please answer.<br>
&gt;<br>
&gt; Why is this attribute architecture-specific? The compiler may as well =
use the attribute for optimization of code locality, having the common bran=
ch be closer. It is obviously implementation and platform specific as to wh=
at extend the hint can be used.</p>
<p dir=3D"ltr">Isn&#39;t code locality also applicable to architectures tha=
t have icache, again thinking in x86 and therefore yet another example of a=
rch-specific? If so I can think of many architectures where this feature wo=
uld be non applicable. I still don&#39;t see the point to make this standar=
d.</p></blockquote><div>I&#39;m sure you&#39;ve got something wrong. IA-32 =
even does not mandate icache to be available architecturally; only some (op=
tional) CPUID leaf functions/non-architectural performance counter events/s=
ome vendor-specific technology would expose its existence. So things concer=
ned here are definitely not arch-specific, but more detailed in implementat=
ions.<br><br>However, anyway, it is not the topic here. You are misguided b=
y the title. Something called &quot;branch predictor&quot; is not directly =
related to the HW impl, even it usually is.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
<p dir=3D"ltr">&gt;<br>
&gt; I would extend this to be more than [[likely]] and [[unlikely]] but [[=
branch_probability: (likely|unlikely|value that must add up to 1.0 across a=
ll branches)]] which might be more than current generation of compilers and=
 architecture can handle (the probability values case), but seems more flex=
ible and only adds one attribute with argument rather than two attributes. =
The name may also include =E2=80=9Ehint=E2=80=9C to make it explicit this i=
s only an optimization and may not have any effect.</p>
<p dir=3D"ltr">And I like your idea, but for an x86 compiler vendor :)</p>
<p dir=3D"ltr">&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"Sj-ASbZlBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">std-proposal...@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"Sj-ASbZlBAAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/716602A1-5556-4D1C-93BF-A0B2F580=
01CB%40googlemail.com" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals=
/716602A1-5556-4D1C-93BF-A0B2F58001CB%40googlemail.com&#39;;return true;" o=
nclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/s=
td-proposals/716602A1-5556-4D1C-93BF-A0B2F58001CB%40googlemail.com&#39;;ret=
urn true;">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>pro=
posals/716602A1-5556-4D1C-<wbr>93BF-A0B2F58001CB%<wbr>40googlemail.com</a>.=
<br></p>
</blockquote></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3918638f-283d-4c38-a97a-951e54993f66%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3918638f-283d-4c38-a97a-951e54993f66=
%40isocpp.org</a>.<br />

------=_Part_17_422511554.1474977107554--

------=_Part_16_10385498.1474977107553--

.

--001a113fdc4214d3e6053d83b02f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thank you all for expressing your views on the topic, all facts are going
to be taken into consideration. I am considering going further and see with
more detail what is the state of the art and what is already done in this
matter. I am one of a team of two developers working on debuggers for HPC
who are pro-actively thinking on writing this proposal to the Committee, so
as a broad final question with aim to gather courage how many of you would
give thumbs up to work out a first draft, (and how many would give thumbs
down as well) :D

Thank you!
Marcos "Macros" Mayorga


On 27 September 2016 at 12:51, FrankHB1989 <frankhb1989@gmail.com> wrote:

>
>
> =E5=9C=A8 2016=E5=B9=B49=E6=9C=8825=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 U=
TC+8=E4=B8=8B=E5=8D=889:50:10=EF=BC=8Cdgutson=E5=86=99=E9=81=93=EF=BC=9A
>>
>> El 25/9/2016 10:45, "'Bernd L=C3=B6rwald' via ISO C++ Standard - Future
>> Proposals" <std-pr...@isocpp.org> escribi=C3=B3:
>> >
>> >
>> > > But why a standard attribute? Go to your compiler vendor and ask to
>> provide an attribute. Think in portability.
>> > > So my question remains: why an architecture-specific feature should
>> be standard, when the language provides the syntax? Please answer.
>> >
>> > Why is this attribute architecture-specific? The compiler may as well
>> use the attribute for optimization of code locality, having the common
>> branch be closer. It is obviously implementation and platform specific a=
s
>> to what extend the hint can be used.
>>
>> Isn't code locality also applicable to architectures that have icache,
>> again thinking in x86 and therefore yet another example of arch-specific=
?
>> If so I can think of many architectures where this feature would be non
>> applicable. I still don't see the point to make this standard.
>>
> I'm sure you've got something wrong. IA-32 even does not mandate icache t=
o
> be available architecturally; only some (optional) CPUID leaf
> functions/non-architectural performance counter events/some vendor-specif=
ic
> technology would expose its existence. So things concerned here are
> definitely not arch-specific, but more detailed in implementations.
>
> However, anyway, it is not the topic here. You are misguided by the title=
..
> Something called "branch predictor" is not directly related to the HW imp=
l,
> even it usually is.
>
> >
>> > I would extend this to be more than [[likely]] and [[unlikely]] but
>> [[branch_probability: (likely|unlikely|value that must add up to 1.0 acr=
oss
>> all branches)]] which might be more than current generation of compilers
>> and architecture can handle (the probability values case), but seems mor=
e
>> flexible and only adds one attribute with argument rather than two
>> attributes. The name may also include =E2=80=9Ehint=E2=80=9C to make it =
explicit this is
>> only an optimization and may not have any effect.
>>
>> And I like your idea, but for an x86 compiler vendor :)
>>
>> >
>> > --
>> > 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-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@isocpp.org.
>> > To view this discussion on the web visit https://groups.google.com/a/i=
s
>> ocpp.org/d/msgid/std-proposals/716602A1-5556-4D1C-93BF-
>> A0B2F58001CB%40googlemail.com.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/LknWBhW0-RM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/3918638f-283d-4c38-
> a97a-951e54993f66%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3918638f-28=
3d-4c38-a97a-951e54993f66%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>



--=20
mm-studios.com
"un dia podr=C3=A9 pagarte los servicios, hoy de momento tan solo puedo
abonarlos."
follow my tweets at http://twitter.com/mayorga;
Marcos Mayorga. 9CEA 212C C9BC A7C1 D417  4B9A 859D FCA1 A159 49E2

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAEQMsGu9d53Okt2S-CzXwvcEOitoZ-EQCL2FJz2_1x-ZEkk=
Nag%40mail.gmail.com.

--001a113fdc4214d3e6053d83b02f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you all for expressing your views on the topic, all =
facts are going to be taken into consideration. I am considering going furt=
her and see with more detail what is the state of the art and what is alrea=
dy done in this matter. I am one of a team of two developers working on deb=
uggers for HPC who are pro-actively thinking on writing this proposal to th=
e Committee, so as a broad final question with aim to gather courage how ma=
ny of you would give thumbs up to work out a first draft, (and how many wou=
ld give thumbs down as well) :D<div><br></div><div>Thank you!</div><div>Mar=
cos &quot;Macros&quot; Mayorga</div><div><br></div></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On 27 September 2016 at 12:51, Fran=
kHB1989 <span dir=3D"ltr">&lt;<a href=3D"mailto:frankhb1989@gmail.com" targ=
et=3D"_blank">frankhb1989@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B49=E6=9C=88=
25=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 UTC+8=E4=B8=8B=E5=8D=889:50:10=EF=BC=
=8Cdgutson=E5=86=99=E9=81=93=EF=BC=9A<span class=3D""><blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><p dir=3D"ltr"></p>
<p dir=3D"ltr">El 25/9/2016 10:45, &quot;&#39;Bernd L=C3=B6rwald&#39; via I=
SO C++ Standard - Future Proposals&quot; &lt;<a rel=3D"nofollow">std-pr...@=
isocpp.org</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt;<br>
&gt; &gt; But why a standard attribute? Go to your compiler vendor and ask =
to provide an attribute. Think in portability.<br>
&gt; &gt; So my question remains: why an architecture-specific feature shou=
ld be standard, when the language provides the syntax? Please answer.<br>
&gt;<br>
&gt; Why is this attribute architecture-specific? The compiler may as well =
use the attribute for optimization of code locality, having the common bran=
ch be closer. It is obviously implementation and platform specific as to wh=
at extend the hint can be used.</p>
<p dir=3D"ltr">Isn&#39;t code locality also applicable to architectures tha=
t have icache, again thinking in x86 and therefore yet another example of a=
rch-specific? If so I can think of many architectures where this feature wo=
uld be non applicable. I still don&#39;t see the point to make this standar=
d.</p></blockquote></span><div>I&#39;m sure you&#39;ve got something wrong.=
 IA-32 even does not mandate icache to be available architecturally; only s=
ome (optional) CPUID leaf functions/non-architectural performance counter e=
vents/some vendor-specific technology would expose its existence. So things=
 concerned here are definitely not arch-specific, but more detailed in impl=
ementations.<br><br>However, anyway, it is not the topic here. You are misg=
uided by the title. Something called &quot;branch predictor&quot; is not di=
rectly related to the HW impl, even it usually is.<br><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><span class=3D"">
<p dir=3D"ltr">&gt;<br>
&gt; I would extend this to be more than [[likely]] and [[unlikely]] but [[=
branch_probability: (likely|unlikely|value that must add up to 1.0 across a=
ll branches)]] which might be more than current generation of compilers and=
 architecture can handle (the probability values case), but seems more flex=
ible and only adds one attribute with argument rather than two attributes. =
The name may also include =E2=80=9Ehint=E2=80=9C to make it explicit this i=
s only an optimization and may not have any effect.</p>
<p dir=3D"ltr">And I like your idea, but for an x86 compiler vendor :)</p>
</span><p dir=3D"ltr"><span class=3D"">&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...@iso=
cpp.org</a>.<span class=3D""><br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/716602A1-5556-4D1C-93BF-A0B2F580=
01CB%40googlemail.com" rel=3D"nofollow" target=3D"_blank">https://groups.go=
ogle.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/716602A1-5556-4D1C-93=
BF-<wbr>A0B2F58001CB%40googlemail.com</a>.<br></span></p>
</blockquote></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/LknWBhW0-RM/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/L=
knWBhW0-RM/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3918638f-283d-4c38-a97a-951e54993f66%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/3918=
638f-283d-4c38-<wbr>a97a-951e54993f66%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><s=
pan style=3D"font-family:trebuchet ms,sans-serif"><font size=3D"4"><span st=
yle=3D"font-family:courier new,monospace"><a href=3D"http://mm-studios.com"=
 target=3D"_blank">mm-studios.com</a></span></font></span><br><div><span st=
yle=3D"font-family:trebuchet ms,sans-serif">&quot;un dia podr=C3=A9 pagarte=
 los servicios, hoy de momento tan solo puedo abonarlos.&quot;<br>follow my=
 tweets at <a href=3D"http://twitter.com/mayorga" target=3D"_blank">http://=
twitter.com/mayorga</a>;</span><span style=3D"font-family:trebuchet ms,sans=
-serif"><br>Marcos Mayorga. 9CEA 212C C9BC A7C1 D417=C2=A0 4B9A 859D FCA1 A=
159 49E2</span><br><span style=3D"font-family:trebuchet ms,sans-serif"></sp=
an><br></div></div></div>
</div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEQMsGu9d53Okt2S-CzXwvcEOitoZ-EQCL2F=
Jz2_1x-ZEkkNag%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEQMsGu9d53Okt2S=
-CzXwvcEOitoZ-EQCL2FJz2_1x-ZEkkNag%40mail.gmail.com</a>.<br />

--001a113fdc4214d3e6053d83b02f--

.

On 2016-09-25 10:14, Andrey Semashev wrote:
> Also, I disagree with you calling it an architecture-specific feature.
> Even if an architecture lacks hardware branch prediction hints, like x86
> or IA-64, or even the branch predictor itself (which, I think, is rare
> these days), the hint can still be used to organize and optimize code.

On how many architectures is the cost of executing a conditional jump
the same as not executing the same jump?

On any architecture where the cost is unequal, the proposed feature is
potentially useful. That's *in addition* to any other ways the compiler
might leverage the knowledge. (Register allocation comes to mind; if the
compiler knows a branch is "unlikely", it could choose to spill
registers that would only be needed by that branch in order to better
optimize the "likely" path. Andrey gave some other examples, and there
are probably even more...)

--
Matthew

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nsbhrv%24asc%241%40blaine.gmane.org.

.

On 09/26/2016 05:20 PM, Matthew Woehlke wrote:
>
> On any architecture where the cost is unequal, the proposed feature is
> potentially useful. That's *in addition* to any other ways the compiler
> might leverage the knowledge. (Register allocation comes to mind; if the
> compiler knows a branch is "unlikely", it could choose to spill
> registers that would only be needed by that branch in order to better
> optimize the "likely" path. Andrey gave some other examples, and there
> are probably even more...)
>

Yes. For example, when compiling to FPGA, there is not even a processor
at all, only a pile of low-level hardware functions that can be combined
to achieve what is required. But the high-level synthesis compiler can
use this kind of information from the C++ code to put more resources
where it is required too boost the global performance.
--
Ronan KERYELL, Xilinx Research Labs / Ireland.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5da97db4-13b2-e351-414a-87494414748b%40xilinx.com.

.

--001a114aa3749bcd62053d959457
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 26, 2016 at 12:20 PM, Matthew Woehlke <mwoehlke.floss@gmail.com=
>
wrote:

> On how many architectures is the cost of executing a conditional jump
> the same as not executing the same jump?
>

=E2=80=8BThe _only_ implementations on which the costs would be identical a=
re those
with no pipelining and those which,
upon encountering a conditional branch
=E2=80=8B, =E2=80=8B
stall further instruction fetch
=E2=80=8Bing
 until that branch gets resolved.  The former are essentially definitional
interpreters for an instruction set.  The latter would be totally hobbled
relative to any implementation with even the most minimal pipelining. Even
the earliest RISC cores - implemented in what today we would deem severely
constrained gate budget
=E2=80=8Bs=E2=80=8B
- implemented shallow pipelines.  By making branch resolution and register
writeback occur at the same point in the pipeline
=E2=80=8B they kept=E2=80=8B

=E2=80=8Bgate =E2=80=8B
costs and
=E2=80=8B design=E2=80=8B
complexities minimal.

What is the implication of pipelining?  If you don't want to introduce a
bubble in which no useful work gets performed you have to predict an
instruction path to follow before you know a branch's the true outcome.  As
I mentioned earlier in this thread, even without a branch history mechanism
(a relatively large HW structure) simple instruction decoders typically
predict forward branches as not taken and backward branches as taken.
Whatever the prediction mechanism, if a prediction proves correct the
pipeline keeps flowing unabated.  When a prediction proves wrong all
"in-flight" instructions in the pipeline get discarded, the fetch PC gets
reset so as to follow the alternate path, and the pipeline gets restarted.

Hopefully that brief description makes clear that the deeper the pipeline
the more in-flight instructions it will contain and hence the greater the
cost of mis-prediction.  Machines with shallow pipelines (*e.g.* your
typical embedded processors) incur relatively little cost for a
mis-prediction and hence would see little benefit from adding a branch
history mechanism.  By contrast, larger, more aggressive cores with deeper
pipelines incur very significant costs on mis-prediction and hence can
justify the chip real estate and design expense for a branch history
mechanism.

Bottom line: _all_ real implementations incur cost on mis-prediction.  The
greater that pain the stronger the argument for investing in HW to mitigate
those costs.

=E2=80=8B/john=E2=80=8B

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAJnXXogqVoXhrFXYwsjJCZJjtAKUxpAU5Ynz2SPpZuTGRzC=
7hg%40mail.gmail.com.

--001a114aa3749bcd62053d959457
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Sep 26, 2016 at 12:20 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div id=3D"gmail-:19l" class=3D"gmail-a3s gmail-aXjCH gmail-m1577108c3=
32fda31">On how many architectures is the cost of executing a conditional j=
ump<br>
the same as not executing the same jump?<br></div></blockquote><div><br></d=
iv><div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;display:inline">=E2=80=8BThe _only_ implementations on which the =
costs would be identical are those with no pipelining and those which,=C2=
=A0</div><span style=3D"font-family:arial,helvetica,sans-serif">upon encoun=
tering a conditional branch<div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;display:inline">=E2=80=8B, =E2=80=8B</div></sp=
an><span style=3D"font-family:arial,helvetica,sans-serif">stall further ins=
truction fetch<div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;display:inline">=E2=80=8Bing</div>=C2=A0until that branch g=
ets resolved.=C2=A0 The former are essentially definitional interpreters fo=
r an instruction set.=C2=A0 The latter would be totally hobbled relative to=
 any implementation with even the most minimal pipelining. Even the earlies=
t RISC cores - implemented in what today we would deem severely constrained=
 gate budget<div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;display:inline">=E2=80=8Bs=E2=80=8B</div> - implemented shall=
ow pipelines.=C2=A0 By making branch resolution and register writeback occu=
r at the same point in the pipeline<div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;display:inline">=E2=80=8B they kept=E2=
=80=8B</div>=C2=A0<div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;display:inline">=E2=80=8Bgate =E2=80=8B</div>costs and<=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;display:inline">=E2=80=8B design=E2=80=8B</div> complexities minimal.</spa=
n></div><div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;display:inline"><br></div></div><div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;display:inline">What =
is the implication of pipelining?=C2=A0 If you don&#39;t want to introduce =
a bubble in which no useful work gets performed you have to predict an inst=
ruction path to follow before you know a branch&#39;s the true outcome.=C2=
=A0 As I mentioned earlier in this thread, even without a branch history me=
chanism (a relatively large HW structure) simple instruction decoders typic=
ally predict forward branches as not taken and backward branches as taken.=
=C2=A0 Whatever the prediction mechanism, if a prediction proves correct th=
e pipeline keeps flowing unabated.=C2=A0 When a prediction proves wrong all=
 &quot;in-flight&quot; instructions in the pipeline get discarded, the fetc=
h PC gets reset so as to follow the alternate path, and the pipeline gets r=
estarted.</div></div><div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;display:inline"><br></div></div><div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;display:=
inline">Hopefully that brief description makes clear that the deeper the pi=
peline the more in-flight instructions it will contain and hence the greate=
r the cost of mis-prediction.=C2=A0 Machines with shallow pipelines (<i>e.g=
..</i>=C2=A0your typical embedded processors) incur relatively little cost f=
or a mis-prediction and hence would see little benefit from adding a branch=
 history mechanism.=C2=A0 By contrast, larger, more aggressive cores with d=
eeper pipelines incur very significant costs on mis-prediction and hence ca=
n justify the chip real estate and design expense for a branch history mech=
anism.</div></div><div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;display:inline"><br></div></div><div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;display:inl=
ine">Bottom line: _all_ real implementations incur cost on mis-prediction.=
=C2=A0 The greater that pain the stronger the argument for investing in HW =
to mitigate those costs.</div></div></div></div><div class=3D"gmail_extra">=
<br></div><div class=3D"gmail_extra"><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif">=E2=80=8B/john=E2=80=8B</div><br></=
div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnXXogqVoXhrFXYwsjJCZJjtAKUxpAU5Ynz=
2SPpZuTGRzC7hg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnXXogqVoXhrFXY=
wsjJCZJjtAKUxpAU5Ynz2SPpZuTGRzC7hg%40mail.gmail.com</a>.<br />

--001a114aa3749bcd62053d959457--

.