Branch Prediction?

[Paul Hohensee]

No, we didn't think about likely-path optimization.

If it were me (and it's not :) ), I'd want to see some generated code
examples that would benefit.  Perhaps quantify the benefit by getting a
libjvm profile, look at the code for the top 10 or 20 methods, reorganize
it via a proof-of-concept implementation and measure the result.  I'd also
take into consideration that future hardware improvements (e.g., larger
icache line size) might negate any current improvement, so it'd have to be
a 'big' benefit.  Again if it were me (and it's not :) ), it would take
maybe a per-instance 10% improvement before I'd accept the intellectual
overhead cost of a permanent implementation. I worry a lot about long term
source code maintainability, hence I have a sort of automatic skepticism
about features than complicate it. :)

Hope this helps,

Paul


On Thu, Nov 20, 2014 at 8:40 AM, Vitaly Davidovich <vitalyd at gmail.com>
wrote:

> 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
>>
>