Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-14 00:57:59

On 14/05/2017 01:41, Vinnie Falco via Boost wrote:
> On Sat, May 13, 2017 at 5:00 PM, Soul Studios via Boost
> <boost_at_[hidden]> wrote:
>> My apologies, when my brain saw "expected" it also saw "__builtin_expect"
>> and I immediately assumed an unlikely/likely proposal

Ah, okay thanks.

> If you are referring to a cross-platform implementation of
> __builtin_expect that uses regular C++ then you have my full support,
> you should propose such a library. As a Visual C++ user I would find
> that very helpful!

There was a very interesting talk at ACCU (unfortunately in the
non-videoed room) by a HFT guy explaining all the ways in which recent
GCC versions have bugged __builtin_expect, like inverting the code path
you specifically told the compiler was the hot path.

GCC devs apparently don't care enough to fix it despite multiple
persistent reports, and the feature is now useless on GCC >= 5. The
speaker recommended clang, especially very recent clang which is
apparently finally being competitive with GCC in generating very tight
code. I'd back that up, clang 5.0 is generating much tighter code with
Outcome than clang 3.x did, markedly so.

But I can see a feature like __builtin_expect that going the way of the
dodo as the compiler vendors really would prefer if you used profile
guided optimisation instead. Passing that sort of micro-info from the
parser to the backend is surely complex to get right.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/