Decision Speed Optimisation

Jump to navigation Jump to search
Revision as of 5 May 2013 at 16:17.
The highlighted comment was created in this revision.

Decision Speed Optimisation

I was playing around with a speed comparison with manual point-in-field checks to the Rectangle2D.Double.contains(x,y) method, and discovered that if I used && between the booleans I got pretty much exactly the same speed, but if I use & I get double the speed and exactly the same result. I'm guessing this is due to my CPU being able to evaluate multiple boolean expressions simultaneously, but if && is used only one is allowed to be executed at a time, or perhaps & just allows the pipelines to stay more full because there is less branching.

Of course, there are some reasons you might want && instead, like null checking before examining an object property, and && is smaller codesize for those bots that are codesize restricted, but particularly for high-load situations like the inside of precise prediction or play-it-forward loops, using & for your decisions might gain you some speed =)

    Skilgannon14:09, 5 May 2013

    Nice. This is a kind of optimization that you can't figure out by doing CPU profiling alone.

      MN15:10, 5 May 2013
       

      That's interesting and is something I didn't know. I don't think there would normally be parallel evaluation going on, so I do think it's the lack of branching and that bit-wise operations are just very simple/fast. I found a couple StackOverflow questions about it too, where people mostly mention branching. [1] [2]

      I'm probably in the "not worth the cost to readability" camp, but I know you're a little closer to the "anything for speed" end of the spectrum. :-)

        Voidious17:16, 5 May 2013