9 ms·

I really like this method: https://github.com/raxod502/TerrariaClone/blob/fd1ff8b8b0e78e6bcc6fc3aa0c1e204d5b84475e/src/Inventory.java#L1666 https://github.com/r

I really like this method: https://github.com/raxod502/TerrariaClone/blob/fd1ff8b8b0e78e6bcc6fc3aa0c1e204d5b84475e/src/Inventory.java#L1666 https://github.com/raxod502/TerrariaClone/blob/fd1ff8b8b0e78...

danbruc 9y ago
That is probably (x + 1) % 10 assuming x is non-negative. That kind of code is responsible for quite a bit of the verbosity, the author was obviously not aware of many of the little tricks usually used in this kind of code.
- baddox 9y ago
  Also assuming that x <= 9.
- raxod502 9y ago
  Original author here. It's actually a method to convert from the index of an inventory hotkey slot into the keystroke used to access it -- there were ten hotkey slots, which were numbered 1–9 and 0 at the end. But I like all the other interesting interpretations here :P (They all assume way more knowledge than I had at the time.)
hacking_again 9y ago
Well, it's faster than %, but I bet it's premature.
- CydeWeys 9y ago
  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.
  - hacking_again 9y ago
    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-avoid-using-the-mod-operator-when-possible 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 9y ago
      > On their own, % and / are way slower than +, -, *, <<, >>. And the branch instruction is free??
      - hacking_again 9y ago
        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 9y ago
        > More or less, assuming you can predict it. But there's a penalty for misprediction. Yeah, no, that's not free.
        9y ago

danbruc 9y ago

That is probably (x + 1) % 10 assuming x is non-negative. That kind of code is responsible for quite a bit of the verbosity, the author was obviously not aware of many of the little tricks usually used in this kind of code.

baddox 9y ago
Also assuming that x <= 9.
raxod502 9y ago
Original author here. It's actually a method to convert from the index of an inventory hotkey slot into the keystroke used to access it -- there were ten hotkey slots, which were numbered 1–9 and 0 at the end. But I like all the other interesting interpretations here :P (They all assume way more knowledge than I had at the time.)

hacking_again 9y ago

Well, it's faster than %, but I bet it's premature.

CydeWeys 9y ago
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.
- hacking_again 9y ago
  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-avoid-using-the-mod-operator-when-possible 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 9y ago
    > On their own, % and / are way slower than +, -, *, <<, >>. And the branch instruction is free??
    - hacking_again 9y ago
      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 9y ago
        > More or less, assuming you can predict it. But there's a penalty for misprediction. Yeah, no, that's not free.
        9y ago