[mcguire]

Branch predictions are an interesting use, although I'm wondering how expensive a misprediction really is.

But this:

"Another example is the use of regression techniques from machine learning to build models of program behavior. If I replace 64-bit arithmetic with 32-bit arithmetic in a program, how much does it change the output of the program and how much does it reduce energy consumption? For many programs, it is not feasible to build analytical models to answer these kinds of questions (among other things, the answers are usually dependent on the input values), but if you have a lot of training data, Xin Sui has shown that you can often use regression to build (non-linear) proxy functions to answer these kinds of questions fairly accurately."

I'm not sure whether I am fascinated or horrified.

[pm215]

Wikipedia reckons 10-20 cycle penalty for a branch mispredict (which sounds plausible given it fills the pipeline with useless junk). Given that branches are quite common, that's painful enough to want to avoid, but definitely not so painful that you'd want to devote as much silicon to solving it as you do to, say, L1 cache.

I do recall a bit of research (published by a Nokia R&D team I think) that reckoned you could get a mostly-ok performance estimate by tracking about half a dozen indicators including instructions executed, cache misses, tlb misses and brancb mispredicts and weighting them appropriately. The trouble there is nobody wants a performance model that's right 90% of the time but significantly wrong 10% of the time with no way to tell if the workload you want to test is in the 10%. But it's an indication of the importance of branch prediction still, I think.