Branch Prediction?

[Erik Österlund]

Okay, I suspected there would have been a conscious decision, thanks for the info. :)

/Erik

On 19 Nov 2014, at 02:36, 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