@acisternino: I ran another simple benchmark, and there seems to be no doubt that FastMath is heavily slowing down the system as a whole, even as it seems to speed up individual calculations. See for yourself in branch without_fastmath. If you want to make it more obvjous, try pumping up PerformanceTest to 10 Kticks and see for yourself. This test is the closest to a real system running (minus graphics), so I'd consider it reliable – and in fact, just running the same experiment with/without FastMath and timing it seems to confirm that this class is slowing down the system.

By now I'm tempted to just delete FastMath for good, but I'll wait until you give me an opinion. I have no reasonable explaination for this.

[Update: Cipster, ignore this comment. I realized that I couldn't compare two runs with/without FastMath, even with the same seed, because the rounding errors, although minimal, resulted in a completely different evolutionary path. This is the butterfly effect in action: if you have a different number of creatures in the two experiments, then you cannot reliably compare the speeds.

So I made a temporary change to the code to disable all stuff that has an effect on the number of items: I removed death, reproduction, food spawning and food consumption. I ran two experiments with the same seed (1234) and I got 1 million ticks in 330 seconds with FastMath, and 348 seconds with java.Math. It's not a large difference, and we might question whether it's worth it – I still don't understand what kind of impact the rounding has on evolution, so maybe it's still a good idea to use standard java math. On the other hand, the benchmark is in favour of FastMath, so I'll close this issue for now.]