Which is faster? :P

Performance Tuning
#21

Just doing it is no fun :smiley: Better discuss it first :D:D

#22

You aren’t asking for discussion. People are discussing it and you are all “can you guys just tell me which is faster?”…

#23

I made this little test.

Loop through 10000 if statements. It took 0.09milis.
Picking a action from action array which has 10000 members, it took about 0.0025

Ofcourse you will say that “this is not correct benchmark”. But :: :
If there are only a few if statements, than using IF statements is a lot faster.
If you have a lot of stuff to check, better make a hashmap or a list or an array.

#24

see, actual Measurement is better than just theorising :wink:

#25

I knew that already.

#26

Use an array (or a switch if sufficiently small number)

But only if the measurement is done correctly.

To expand on delt0r’s comments. It’s true that the action is going to cost more than the dispatch in OPs question, but the reasoning is more generally interesting.

Don’t use java.util.Random. It’s core generator requires a CAS, which with no contention is still very expensive (let’s call it 50 cycles on average). And that’s dumb anyway because you don’t want more than one thread using the same generator anyway (you become non-deterministic. note this doesn’t mean better quality…that’s the same…you’ve made your life hell if you need to debug. There’s no upside.) Instead use a custom PRNG or if you’re unwilling then java.util.concurrent.ThreadLocalRandom. If you take Damocles code and replace Random with ThreadLocalRandom, then the gap between the two will drastically drop (but is result is still meaningless). Change to using an XORSHIFT then the generated version will be faster (on average across current-ish CPUs).

#27

First of all, the list version gets noticeably slower if you run the test multiple times in a loop: 410ms first run to 458ms for subsequent runs. Secondly, microbenchmarks overstate the performance of lookup tables since nothing else is competing for cache space so the whole or a large part of the lookup table can be cached and reused. Hence, this benchmark is pretty useless in the first place. Sorry. Only a real-world performance test would make sense here.

Also, there’s not a very big point in optimizing this specific part in the first place. Calculating 10 000 random values takes around 0.1ms for me. Would you ever need that many random values in a single frame? If you do, you have more problems with your algorithm than with the performance of your random number generator.

I’d say the answer to “Which is faster?” is “Does it matter?”. Random is cleaner, shorter and has more predictable performance than a lookup table, so I’d go with it.

EDIT: Using ThreadLocalRandom as Roquen just suggested is around 10% faster than a lookup table:
List: 457.359 ms
ThreadLocalRandom: 410.875 ms

#28

Now just for fun try an embedded XorShift and then an LCG.

   
 static int data = 1|(int)System.nanoTime();
   
 /** Returns a uniform 32-bit integer. */
 public static final int nextInt()
 {
   if (false)
     data = 0xac549d55*data + 12345;  // LCG
   else {
     data ^= (data <<  13);           // XorShift
     data ^= (data >>> 17);
     data ^= (data <<   5);
   }
   return data;
 }

static void randomFromRandom()
{
   if (nextInt() < 0) inc(); else dec();
}

(EDIT: Opps…I forgot to disallow a seed of zero…bad me)

#29

I use something very similar to Roquen’s rng, its somewhere in the code section. It can generate 2^31 random numbers in seconds on modern machines. Not minutes. It is also “more random” than that stupid mersenne twister.