Mispredicted branches can multiply your running times • Hacker News Board

Re: Mispredicted branches can multiply your running times

#111

Post by ncmncm » Thu, Oct 17, 2019, 9:02 AM UTC

sifar wrote: post #70

ncmncm wrote: post #2

> most loops are actually implemented as branches. No kidding! But the article does call attention to a very important technique. It merits serious thought over all the ways it can be applied, that may not look much like this one, on the surface.

Most DSPs have zero overhead loops (still branches) which don't incur a branch penalty. So something like below may take 1-2 cycles atmost, per iteration. for(i=0;i Ofcourse variable length loops would still have the branches.

Haswell and later can run loops with 4 instructions, including 2 ALU ops and two conditional branches -- provided only one is taken -- in one cycle.

Compilers prefer to order the instructions so they take two or more cycles.

Re: Mispredicted branches can multiply your running times

#112

Post by marcosdumay » Fri, Oct 18, 2019, 12:20 PM UTC

morelisp wrote: post #86

lippel82 wrote: post #84

Earlier quoted context omitted.

To be slightly pedantic here: Power is energy per second, so power consumption itself would go down. Total energy consumption, which is power*time could go up.

The correction is welcome - I am just a little sad we trained a cohort of developers to care about power, but not well enough to understand that race-to-sleep is usually the best way to achieve that.

Hum... Race to sleep is usually not the best way to save power. Undervoltage is. Race to sleep just gets the spotlight once you have an extremely optimized CPU that can not be undervolted anymore in a practical way.

The rule of thumb you learned is useful for optimizing PC software, but has no place in CPU architecture discussions.

Also, "usually" leaves a lot of important cases out.

Re: Mispredicted branches can multiply your running times

#113

Post by DrScientist » Fri, Oct 18, 2019, 12:29 PM UTC

ThrowawayR2 wrote: post #85

DrScientist wrote: post #35

Earlier quoted context omitted.

And if your platform is a virtual machine or interpreter running across a number of chip archs? Perhaps it would be better to simply have appropriate tests and benchmarks to see what's slow on what platform? Otherwise it's guess work based on incomplete understanding of the many layers below.

> " And if your platform is a virtual machine or interpreter running across a number of chip archs? " Outside of microcontrollers, I can't think of a processor in common use that doesn't have branch prediction or caches.

True though I suspect that that the length of the pipeline and the cost of a cache miss will be quite different between ARM versus Intel.

While, I'm a big fan not not writing poorly performing code, as you get death by a 1000 cuts. Is it not better to test rather than educated guess?

ie The reason there is alot of poor performing code, is not a lack of understanding at a low level about caches and branch prediction, but a lack of care about performance?