I have no knowledge of how the compiler works, but I would think that adding code which does nothing should slow down the speed. This is where I get strange results. The two pieces of code are the same except that the first piece of code has some extra line which are not used. When I run these codes 50.000.000 times the first piece of code uses 2.8 seconds while the second code uses 4.8 seconds.
Could anyone please come up with a sugestion of why the extra code speeds things up?
Function EnLøperHver(ByVal lbrett As bbBrettType, ByVal Farge As Byte) As Single
Dim xHL As Byte
Dim yHL As Byte
Dim xSL As Byte
Dim ySL As Byte
xHL = Rute2X(0)
yHL = Rute2Y(0)
xSL = Rute2X(0)
ySL = Rute2Y(0)
If RuteFarge(FinnRute(lbrett.Brikker(0, 3))) <> RuteFarge(FinnRute(lbrett.Brikker(1, 3))) Then EnLøperHver = 0.5 Else EnLøperHver = 1
End Function
Function EnLøperHver(ByVal lbrett As bbBrettType, ByVal Farge As Byte) As Single
If RuteFarge(FinnRute(lbrett.Brikker(0, 3))) <> RuteFarge(FinnRute(lbrett.Brikker(1, 3))) Then EnLøperHver = 0.5 Else EnLøperHver = 1
End Function
jacobbl wrote:I have no knowledge of how the compiler works, but I would think that adding code which does nothing should slow down the speed. This is where I get strange results. The two pieces of code are the same except that the first piece of code has some extra line which are not used. When I run these codes 50.000.000 times the first piece of code uses 2.8 seconds while the second code uses 4.8 seconds.
Could anyone please come up with a sugestion of why the extra code speeds things up?
Function EnLøperHver(ByVal lbrett As bbBrettType, ByVal Farge As Byte) As Single
Dim xHL As Byte
Dim yHL As Byte
Dim xSL As Byte
Dim ySL As Byte
xHL = Rute2X(0)
yHL = Rute2Y(0)
xSL = Rute2X(0)
ySL = Rute2Y(0)
If RuteFarge(FinnRute(lbrett.Brikker(0, 3))) <> RuteFarge(FinnRute(lbrett.Brikker(1, 3))) Then EnLøperHver = 0.5 Else EnLøperHver = 1
End Function
Function EnLøperHver(ByVal lbrett As bbBrettType, ByVal Farge As Byte) As Single
If RuteFarge(FinnRute(lbrett.Brikker(0, 3))) <> RuteFarge(FinnRute(lbrett.Brikker(1, 3))) Then EnLøperHver = 0.5 Else EnLøperHver = 1
End Function
Regards
Jacob
This is a pretty common occurrence. When you add code, you change the way things are laid out in memory, which can change the alignment of things. And then cache works its magic, and suddenly fetches more important data in one "gulp" when a cache miss happens, because of the shifted addressing.
By the same token, removing what appears to be useless code can slow you down or speed you up just as well...
Would this behaviour be computer dependent? Could the results be different on another machine, or is one code allways better than the other?
Regards
Jacob
yes it can be different assuming you are talking about two different processor types... For example, a pentium IV will behave differently than a core-2, because the caches are significantly different...
Which piece of code would you recomend to use? The logical one, or the one with the extra code doing nothing which runs quite a lot faster on my machine (a Intel Core 2 Duo)?
Which piece of code would you recomend to use? The logical one, or the one with the extra code doing nothing which runs quite a lot faster on my machine (a Intel Core 2 Duo)?
My approach has always been pretty simple.
Write the code as cleanly as possible. Then take a careful look at the memory referencing patterns to see if any re-ordering of the data will be beneficial (look for temporal locality and let that define spatial locality). I then use that code even if it is marginally slower. Certainly, speed is important, but in general, when you find one of these oddball cases, you can clean the code up and still get the gain. For example, if it is an alignment issue, you can fix that without adding extra code. Figure out what is changing when you add the superfluous code, and then fix that data / data structure so that you get the benefit without the extra code being needed.
The code re-alignment is one option as Bob mention it. If you're talking about intel compiler for windows however, note that the result could be just noisy (incorrect randomness in measurement) since ICL have the ability to automatically exclude unused code at O2 and O3 levels.