GP32 Mersenne Twister


MojoJojo

Member
Joined
Jun 19, 2003
Messages
165
Hi all, I haven't been around for a while since a hard drive crash killed all my source code. To get back into things, I thought I would try out the Mersenne Twister random number generator, which I came accross a couple of days ago and Rico mentioned today.

Anyway, using the code off http://www.math.keio.ac.jp/~matumoto/emt.html, it turns out the mersenne twister is a bit slower than rand. Bit disappointing, but no biggy. But then I reinserted the line from Rico's tutorial to up the clock speed to 133MHz. And both functions took twice as long as before.

Is this just a small mistake in the tutorial, or is it possible some things run slower at higher clock speeds due to different memory timings and clock multipliers?

Source Code heavily based on Rico's tutorials :)

Aster My Asteroids clone that I never quite managed to complete, and have now lost the sources. If anyone wants to host this properly I would be grateful.
 
That line doesn't just set the clockspeed. It also seems to set speed for other things like memory access. Perhaps since the MT code relies heavily on a large array, the read access is slower. Other than that, it's certainly odd behaviour and I really can't explain it.
 
It's not just the MT that is slower, it's the normal rand function as well. I have no idea how that works. Does anyone have any idea of what is going on? It could be a lot of programs could run faster at lower clock speeds, which would be nice.
 
I not sure how reliable the results of GpTickCountGet are at clock speeds other then 40Mhz. I think it may fail to compensate for the increase in processor speed and give the wrong timings.

Have you tried setting the TESTSIZE very high and then measuring the timings on a stopwatch to double check this?

Dave
 
I not sure how reliable the results of GpTickCountGet are at clock speeds other then 40Mhz. I think it may fail to compensate for the increase in processor speed and give the wrong timings.

Have you tried setting the TESTSIZE very high and then measuring the timings on a stopwatch to double check this?

Dave
Good point, I guess lots of stuff gets messed up by changing the clock speed. I'll check with a stopwatch when I can.
 
Last edited by a moderator:
I've had this problem before. When changing the clockspeed GpTickCount() does not (or not correct) compensate for this. For a more reliable test you have to use a stopwatch.

Maybe a table with clockspeeds and ticks per second would be nice, any volunteers?
 
I've also had problems with my programs when changeing clockspeed. Since i'm only a noob c coder, I just tried moving around my GpClockSpeedChange code around. After I moved it to gpstart.c my programs seem to work a lot better (no weird graphic glitches on the right side of the screen).

Can anyone explain why/how this works?
 
Back
Top