Hacker News Reader

Comment by IshKebab | Hacker News Reader

Do compilers even generate these hints?

Usually not by default, but GCC and other compilers have intrinsics like __builtin_expect [1] which may generate branch hints.

[1]: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index...

Quite popular in the Linux kernel code, as far as I've seen over the years. See [1] for some discussion over on SO.

[1]: https://stackoverflow.com/questions/109710

In practice this doesn't result with a special-kinded instruction to hint the CPU branch-predictor but only affects the compiler to generate a codegen that is optimized for better CPU instruction-cache utilization. E.g. it will try to move the less likely code out from the hot code path and as such the likely code is going to be more dense and co-located next to each other.

It can also change the instruction selection. For example, __builtin_unpredictable which is a close cousin of expect will indicate there's no prediction possible on a branch. This causes the compiler to select branchless instructions & is particularly useful in things like binary search where the CPU attempting to do prediction is worse than using a branchless version of the code.

I think in general we're overdue for more compiler directives, and not just branch hints. As heterogenous architectures become more standard, we really need a way to tag what functions are best to run with what types of instructions. For example, tag a function that will utilize SIMD so that if a thread is running this function, the operating system knows to try to have it run on the cores that support SIMD. As of now, with P and E Cores for Intel, Intel is straight up disabling instructions to ensure uniform instruction support.

IDK but I know C++ has [[likely]] and [[unlikely]] hints:

https://en.cppreference.com/w/cpp/language/attributes/likely

They were not necessary, as the CPU would run the both sides of the branch in parallel and scrap the irrelevant side when it was known to be false. Essentially making a hint pointless, as it was not utilized at all.

Now the execution of both sides of a branch is basis for the 'Specter' side-channel attack. Access restricted data in the false branch, data access still happen even though it was restricted.

That is essentially impossible to prevent and disabling it killed a lot of cpu performance, branch hints might be the next best thing.

If you’re not speculatively executing, you don’t need a branch hint because you don’t need to speculate which way it goes.

Also, I don’t think executing both sides of a branch ever took off on any mainstream CPUs (unless Itanium counts). It wastes power to spend half your execution units on things that won’t be committed, why not use them on the other hyperthread instead?

> Also, I don’t think executing both sides of a branch ever took off on any mainstream CPUs

That part I am sure off. I will double check with a friend of mine of of curiosity, but one thing to note is that the execution units are processing branches up to the point when branch is evaluated, then the false path is dropped.

Back then the speed was trumping the power draw. I am not sure what are the priorities today.

In terms of hyperthread, i don't think you can safely execute instructions of both siblings due to possible shared cache mem clashes. But I am guessing now. Its been a while since I have been working that low level to remember the details.

I don't know of any CPU that speculates both sides of a branch. I work on a CPU design team.

Modern CPUs speculate hundreds of instructions ahead, and with just a dozen branches you can have a few thousand different paths. It makes more sense to speculate down one path with very high accuracy.

This is the right answer. :)

I think a lot of folks get mixed up with GPU and/or SIMD architecture, where you execute both sides of the branch out of necessity: Some of the lanes need to go one way and some the other, so you have to do both.

I’ve always thought this would be an interesting use for a hyperthread (send it to execute both sides of an if, when the programmers knows the branch predictor is likely to not be able to know which side is right). But, never got around to coding anything like that up…

the problem is that when you care (unpredictable but hot branches), there are probably too many of them to execute in parallel (use up all your speculation depth). 2^n, you know!

not to mention that you burn a lot more power.

> Now the execution of both sides of a branch is basis for the 'Specter' side-channel attack. Access restricted data in the false branch, data access still happen even though it was restricted.

By all accounts of Spectre I've seen, the processor never tries to speculate both sides of the branch. Instead, it always predicts one side of the branch, and speculatively executes that side only: when it later turns out to have been a misprediction, it rolls back the speculative execution, and proceeds to execute the other side from scratch. Both sides are executed at some point, but not simultaneously.

Yeah I'm pretty sure most CPUs don't actually execute both branches. They pick the most likely one and execute that.

See https://people.computing.clemson.edu/~mark/eager.html

That is right.

The only purpose of the branch predictor, which has become one of the biggest and most important parts of any modern CPU core, is to execute only one of the two branches, hoping that you have guessed the right one.

On a CPU that executes both branches, there is no reason for a branch predictor to exist.

The equivalent of executing both branches is obtained by replacing the conditional branches with conditional move or conditional select instructions, which are used after both values corresponding to the two alternatives have been computed. The use of conditional move/select instructions is justified only when the direction of the conditional branch would have been quasi-random, so the branch predictor would have failed to predict it.

Executing both branches has an exponential cost in the number of conditional branches that are speculated ahead, so it is neither feasible nor desirable, as it would greatly increase both the power consumption and the die area for a given performance.

Reply on news.ycombinator.com