Calypso88

Since I had my benchmark code already warmed up from Friday and a photoshop doc open with my histograms, I figured I should make good on the updated speed tests that I promised a year ago.

Here is basic math, receiving a huge boost between debug and release modes. The shaded bar is the duration of the call, so shorter means faster execution.

From here down, everything is running 10m iterations. The scale of these graphs is 560ms. Here's the difference in calling a static public variable, versus a local copy of same.

Finally, replacing the Math helper methods with some logic and basic math:

These stack up pretty well with what I saw in the debug player a year ago (although there is an overall speed increase in all the tests).

If anyone is curious, there is a slowdown in calculating powers of a number (i * i * i * i) as you have to reference that variable over and over - for me the break-even between stringing on more 'i's and just calling Math.pow() was around 60.

I was messing around with some bitmap code this evening and I came across a performance bottleneck with some repeated calls to Math.random(). Since I haven't posted anything in a while, I decided to do some benchmarking and try out an alternate (psuedo) random number generator.

I chose the XOR algorithm, primarily because AS3 is lightning-quick with bit operations, and the algorithm is only 4 lines of code. Here are two versions I tried:

//  UINT
 
const MAX_RATIO:Number = 1 / uint.MAX_VALUE;
var r:uint = Math.random() * uint.MAX_VALUE;
 
//  returns a number from 0 - 1
function XORandom():Number{
	r ^= (r << 21);
	r ^= (r >>> 35);
	r ^= (r << 4);
	return (r * MAX_RATIO);
}

//  INT
 
const MAX_RATIO:Number = 1 / int.MAX_VALUE;
const NEGA_MAX_RATIO:Number = -MAX_RATIO;
var r:int = Math.random() * int.MAX_VALUE;
 
//  returns a number from 0 - 1
//  comment out line 13 for -1 - 1
function XORandom():Number{
	r ^= (r << 21);
	r ^= (r >>> 35);
	r ^= (r << 4);
	if(r < 0) return r * MAX_RATIO;
	return r * NEGA_MAX_RATIO;
}

It's worth noting that this algorithm works from a seed number. For my purposes, picking one random seed and iterating is fine, but this function is predictable enough that you wouldn't want to use this method for crypto or anything where you'd want "very random" data sets. This also could be useful in some situations where you'd want to replay a set of random numbers - such as generating enemies or levels in a game and then creating a replay by saving the seed number.

For my benchmark, I ran 25 sets of 10 million iterations on each function, using the 10.0 release player in Safari.

Interestingly, the logic to gate negative numbers in the signed-int version was enough to push it out quite a bit past the uint version. All told, the uint algorithm runs in just under one fourth the time it takes to call Math.random().

As always, Wikipedia will tell you as much as you want to know about the ins and outs of this algorithm and how it stacks up against other generators. And, just for fun, here's a frequency graph of the output.