Hacker News Reader

Comment by alien_at_work | Hacker News Reader

I feel the opposite. I'd like nothing better than this to be the end of branch prediciton. I can think of no other technology that's been so deterimental to high level languages than branch prediction. How many elegant, beutiful algorithms are replaced by bizarre data structures, etc., because avoiding pipeline stalls will trump any other optimization you can make.

For most things the CPU is doing, we can ignore in high level languages because the compiler/optimizer can turn our high level code into the appropriate byte code to take advantage of deep hardwar magic. Not branch prediction, though, no matter how high level my language, I still must consider pipeline size, cache alignment and so on when designing a novel new container or algorithm or risk it being inexplicitly slow.

Branch prediction is, and always was a hack. Let it die.

View on HN

but removing branch prediction would be to restore those stalls and inefficiencies as the way things are when you don't use those strange data structures, right?

The effect of this seems to be "I wish everything was slower and then the naive implementation would be the best implementation".

>restore those stalls and inefficiencies as the way things are when you don't use those strange data structures, right

No, a stall is only a thing because branch prediction exists. Get rid of it and I can go back to not caring about the deep underlying architecture of the hardware I may potentially be running on. And not doing branch prediction isn't inefficient... that's a bizare statement. Branch prediction and speculative execution are themselves inefficiencies (i.e. spending power to do things that will turn out to not be needed fairly often).

>the naive implementation would be the best implementation

Not the naive implementation. A well thought out, developed implementation that is defeated by deep hardware details. The promise of high level languages was always to avoid having to know these sorts of details. In designing an algorithm I should be worried about things like how often I access data (e.g. can I cut down on how many accesses with some clever structure?) and the like. Now that's all trumped by deeply knowing the low level implementation.

Nothing changes for high level languages. If they are high level enough they can still fix Spectre and abstract away deep hardware details.

That's exactly my point: you cannot abstract away details of pipeline size. You must know this to get the best performance out of your structures and algorithms. There is no way for a compiler/optimizer to look at your container implementation and say "oh, this will potentially overflow the pipeline, let's split the data structure into multiple parts and change the code to handle this new access stategy"... that would be creating entirely new code (what would stepping through a debugger look like on such code?).

Reply on news.ycombinator.com