Code-Cache may be one reason, but some of you may remember we found out some time ago that there is a significant diffrence depending on the odd- or evenness of a jumping label in the binary code. A FOR loop is made of a jump-label, a counter variable and a conditional jump to the label.
Try adding some nonsense commands before you start the 2nd loop, eg. "dummy=0", with a bit of luck you'll be able to get both labels on an even address, and therefor the same speed.
Edit: due to system background tasks with a high priority you will never get the exact same results (on something like Win98 you may be able to stop all processes that are not neccessray, like Antivirus etc., on XP and Vista there's much more going on, things like frequent harddrive access).
I was however able to get a max diffrence of about 20ms (eg. 400 vs 420) with both labels on even adresses, but with an additional "dummy=1" the labels seemed to be no longer both on even addresses and it gave me about 100 ms diffrence and more.
This happens however only on some CPU labels, as far as I remember it's on AMD but not on Intel.
Try adding some nonsense commands before you start the 2nd loop, eg. "dummy=0", with a bit of luck you'll be able to get both labels on an even address, and therefor the same speed.
Edit: due to system background tasks with a high priority you will never get the exact same results (on something like Win98 you may be able to stop all processes that are not neccessray, like Antivirus etc., on XP and Vista there's much more going on, things like frequent harddrive access).
I was however able to get a max diffrence of about 20ms (eg. 400 vs 420) with both labels on even adresses, but with an additional "dummy=1" the labels seemed to be no longer both on even addresses and it gave me about 100 ms diffrence and more.
This happens however only on some CPU labels, as far as I remember it's on AMD but not on Intel.