<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 20, 2015 at 10:29 AM, Sven Panne <span dir="ltr"><<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   * On more powerful cores with heavy out-of-order execution, it's<br>
hard to beat a well-predicted branch.<br></blockquote><div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">​With regard to this, I was wondering if we have a way of arranging for good branch prediction in GHC.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">For instance (and I think I've discussed this with Carter before), we've had issues filed against vector (I think) saying that we do branches for certain things that could be branchless. Bounds checks are the first thing that comes to mind, for instance (I.E. we don't use orI# for the lower and upper bound checks). However, so long as branch prediction decides that the bounds checks should succeed, I'd expect them to not be much of a cost anyway---and ideally it will always decide that, because we're inclined not to care about the performance when the checks fail and the program is bombing.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">However, from what I've read, there's basically no easy hinting that can ensure this. The heuristics require moving generated code around if you want to try and influence the branch predictor one way. And we also have no way of indicating to GHC that branches of a case should be preferred anyway. Unless writing things in a certain order accomplishes this?<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">-- Dan<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">​</div> </div></div></div></div>