Branch Prediction?

[Vitaly Davidovich]

Paul,

Compilers can use these macros to move cold/unlikely basic blocks further
away from the likely paths, leading to better icache utilization.  Was that
aspect considered at all? I'll agree that overuse of these macros would be
a maintenance problem, but seems like judicious use of these in targeted
places may yield small benefit.

Thanks

Sent from my phone
On Nov 18, 2014 9:36 PM, "Paul Hohensee" <paul.hohensee at gmail.com> wrote:

> History as I remember it. :)
>
> It's been considered, and decided against.  The platforms which openjdk
> currently targets all have decent to spectacular hardware branch
> prediction.  Those that didn't, such as Niagara 1, ignored prediction
> bits.  Conclusion is that it's not worth complicating the code with, as
> David says, 'magic macros'.
>
> Paul
>
> David Holmes wrote:
> On 19/11/2014 4:42 AM, Christian Thalinger wrote:
> > ?or I could just read the next email.  Doh.
>
> Not so obvious when the subject was changed to "Compiler branch hints".
> I had to go to the archives to find it.
>
> My 2c. The performance focus has been on generated code, not the runtime
> code. Personally I dislike these magic macros as they clutter the code.
>
> David
>
> >> On Nov 18, 2014, at 10:41 AM, Christian Thalinger <
> christian.thalinger at oracle.com> wrote:
> >>
> >> I?m not sure if the silence means nobody knows or nobody cares.
> Speaking for myself, I don?t know of any history on this.
> >>
> >>> On Nov 8, 2014, at 1:43 AM, Erik ?sterlund <erik.osterlund at lnu.se>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Just out of curiosity, is there some good reason why we don't have a
> branch prediction macro?
> >>> For every tight load a; cmpxchg(expect: a, addr: &x, new_val: b); loop,
> I feel a bit uneasy not telling the compiler that this is pretty likely to
> succeed, and relying on its guessing.
> >>>
> >>> Has it been excluded because it's considered not nice or perhaps it was
> simply never introduced because nobody found it useful?
> >>>
> >>> Could have some define like this for GCC, which for other compilers
> reduces to nothing:
> >>>
> >>> #define VM_EXPECT_TRUE(A) __builtin_expect((A), true)
> >>> #define VM_EXPECT_FALSE(A) __builtin_expect((A), false)
> >>>
> >>> It might not lead to drastic performance improvements, but it feels
> weird not to tell the compiler what we know and keep secrets from it. And I
> think it's also nice for documentation purposes that people reading it also
> understand that this expression is gonna be true most of the time, and deal
> with it accordingly.
> >>>
> >>> /Erik
>