[hacking_again]

On their own, % and / are way slower than +, -, *, <<, >>. Cycle counts depend on your architecture, you can look them up. That mod is so slow and should be avoided is a kind of folklore based in truth - kind of like function calls being slow - but like everything time-sensitive the mistake lies in not profiling before (manual) optimization.

There's an example on SO, I got similar results just now when I replicated it:

https://stackoverflow.com/questions/15596318/is-it-better-to...

It doesn't matter on my machine whether the divisor is 10 or 42 (as in the example), the branching is way faster. Now, maybe if the branching were not in a loop and hence not so easily predicted, it wouldn't make a difference. But if this code is not being used in a loop, optimization may be premature anyway (as indicated in my original comment).

Probably f() has something to do inside the main game loop and gets called on a bunch of objects every frame. I haven't looked at the code enough to know if that's a bottleneck.

[35bge57dtjku]

> On their own, % and / are way slower than +, -, *, <<, >>.

And the branch instruction is free??

[hacking_again]

More or less, assuming you can predict it. But there's a penalty for misprediction. So it boils down to whether using % frequently (either as a native instruction or as a sequence of instructions) is more or less expensive than predicting a branch frequently, given a certain misprediction rate.

[35bge57dtjku]

> More or less, assuming you can predict it. But there's a penalty for misprediction.

Yeah, no, that's not free.

[hacking_again]

Ok, so what changes would you make to my explanations?