Intrinsics for Math.min and max

Martin Grajcar maaartinus at gmail.com
Wed Apr 2 20:53:43 UTC 2014


On Wed, Apr 2, 2014 at 4:50 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> I don't think it's reasonably possible to model hardware branch prediction
> in software.  As you say, details are murky, the hardware changes and
> advances, etc.
>
Actually every time the compiler decides between cmov and branch, it does
use a branch prediction model. It's just that the currently employed model
is ignorant of everything but the branching probability. Capturing all the
details is something between too laborious and impossible, but improving a
bit should be doable.

> So clearly there will be cases where cmov will yield a speedup over
> branches.  The question is whether compiler can ascertain that with very
> good precision; otherwise code is penalized and doesn't take advantage of
> any advances in branch prediction in hardware.
>
That's true, but when improved HW comes, the JIT can be improved as well.
And improved HW may also mean bigger misprediction penalty (due to longer
pipelines or due to more operations wasted as more execution units are
provided).

> By removing branches in java I meant rewriting the code/algorithm to not
> branch (or branch more predictably); this is akin to what people do in
> other languages/domains (e.g. c or c++ on hardware with weak predictors).
> Granted level of control in java is limited to some degree, but certainly
> avoiding branches or making them more predictable is feasible?
>
Branches get actually avoided in real code, e.g. in
http://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/math/IntMath.java?r=90a75c93246f0a403fc20275cb80d60e79978933#375.
But in many cases the bit fiddling can't be as efficient as cmov.

I can't imagine how to make a branch more predictable. Usually you have no
control over the data processed, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140402/222f1871/attachment-0001.html>


More information about the hotspot-compiler-dev mailing list