Why do you say it's faster? It's guaranteed to fail branch prediction one out of ten times. My guess is that'd be a lot slower than using the integer modulo operator, which is not an expensive operation.
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:
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.
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.
