Compiler branch hints (was: Branch Prediction?)

[Erik Österlund]

On 08 Nov 2014, at 15:09, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> Hi,
> 
> On 08.11.2014 12:43, Erik Österlund wrote:
>> Just out of curiosity, is there some good reason why we don't have a
>> branch prediction macro? For every tight load a; cmpxchg(ex 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?
> 
> I would not use term "branch prediction" here, since that erroneously
> relates the issue to CPU branch prediction. The macros you are proposing
> affect the code layout in compilers, not the CPU execution.
> 
> Therefore, I have hard time understanding how would introducing these
> macros affect the CAS loop example above? When you have a loop, you will
> generate (back) branch to loop header, and as far as I can see, there is
> only one sane layout for the loop anyway. More interesting layouts
> emerge when compilers can use the hint to selectively peel the loops,
> but I don't think GCC cares about that?

Well, there are loads of optimizations on loops, like loop unwinding too where you repeat the body of loops and trade space for faster loops if they are likely to repeat etc. And a bunch of others of course.

Does GCC do such loop optimizations? Maybe, maybe not. And if so, under which circumstances and in which configurations? Not quite sure. But I'd be surprised to say the least, if GCC didn't do any loop optimizations at all. And regardless which ones they do, hinting which code path is more likely is good practice, and that's why such compiler intrinsics exist in the first place.

If we know for sure the loop will almost always end, why not tell the compiler, so that it won't have to guess? And then we won't have to guess what kind of guessing it's doing if any at all either. By making it explicit, we won't even have to think about it and can sleep well at night knowing that we gave the information we could to the compiler and that if the generated code looks bad, then at least we can blame somebody else. ;)

As for my load phi cas loop example, other libraries like libatomic use such macros for those exact cases, so I'm guessing there's good reason for it.

> That being said, it might be worthwhile to try and optimize some
> performance-critical code, e.g. in classloaders or GC to see what effect
> you are after. I think we can find a hardware that lacks sophisticated
> HW branch prediction that will hide the cost.

I'm sure we can. And even if we can't and the performance difference is invisible, I still think it's a good practice, simply for code readability if nothing else. Anyone reading the code will know which code path (...not hardware...) is more likely (and performance critical), and take that into consideration when writing performance critical code.

>> 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), 
> 
>> 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.
> 
> I like Linux Kernel notation for these: likely/unlikely. As in;
> 
> if (likely(a == 42)) {
> ...
> }

Yeah I guess having a smaller name could be nicer. :)

Given your reply, I'm guessing the answer to my original question (why we don't have the macro), is that it simply has not been introduced yet, rather than there existing some good reason why we would like to ban such compiler hints, and that it has been considered in the past?

Thanks for the reply.

/Erik

> Thanks,
> -Aleksey.