i'm trying to speed up this section of code but i cant see how to remove all of the address interlocks. i managed to get the rest of the code to execute at an average of 8 cycles per iteration but this section where the math is much simpler takes 2 times that. any suggestions?

Run two (or more) iterations in parallel to fill in the gaps with other registers and memory accesses.

if unrolling the loop to multiple AND/OR parallel iterations isn't something you want to do you can always consider a different algorithm to try an accomplish the same goal as your code snippet above.

(EDIT: removed because some people can't take a joke )

rugxulo - the first 2 are just stupid and the third doesn't make sense. the 486 doesn't have dual pipes to allow for 2 instructions to run at one time. which means that the address interlocks aren't as pronounced.

r22 - nice suggestion but i examined the code and I'm not entirely sure that the i could change the algorithm to get the same output any faster but I'll look into seeing if it might be possible (which i doubt) to combine a couple of those shifts ands or xor's.

revolution - i tried that approach but by tests showed that i actually added 10 cycles by doing that. i might have been able to cut a few of those off if i were to change the conditional jump before it so that it isn't alternating every iteration allowing for better processor prediction.

currently the MS rand with I've been testing against (16 bit return but uses 32 bit registers. copied from visual C++ 6) counts at only 7 cycles. while my mt test counts at 22 cycles (average per iteration)

while most implementations of the Mersenne Twister algorithm claim to be as fast as the standard rand function i've found that most of these either don't include this section or cheat on it and only do one xor some funny addition. the version i'm using is a true Mersenne Twister which includes all of the standard math.


i plugged the shift into msvc++ compiler and found that my code is just as fast as msvc++ except it uses one less register and because i like to preserve registers i actually gained a cycle because of not needing the extra register.
for reference
yes i did notice the slight differences in the math and once i saw them i adjusted my code and still managed to keep the same speed and still used one less register.

update i managed to gain an average of about half a cycle per iteration by changing one register shift from ebx to eax
new code the output has been adjusted so that it is now identical to what the compiled code would be.

code now averages at 21 cycles but the decimal behind runs a little high. (this code is now effectively faster than what msvc++ outputs.) the 21 cycles is an average which includes the twist algrothim this segment runs in about 7 cycles.