Tweet
I was browsing through the forums looking for
discussions about code optimization and found
many remarks about register variables and
pointers, etc. First let me say that there were
a few heated discussions about these things and
I don't want to turn this thread into one. I
just prefer to find out the truth and the best,
most efficient way of doing things (which is why
I use PB on my serious code). Since I could
not find any results from tests, I tried my own.
Below is the code to pick apart followed by the
results which were quite interesting. Take into
mind that I am a novice concerning the internal
workings of the processor, so this next remark is
speculation based only on my results thus far.
Based on the numbers, it would appear that there is
a slight overhead in registering these vars in the L1.
That overhead shows up in the code below. There is
no doubt that registering the vars is faster (just
look at the results for 10,000,000,000 iterations),
but being registered, they never break the .4 barrier.
They don't start to even out on my machine until
about 50,000,000 iterations. Under that number of
iterations, the memory variables are consistently
faster. Can anyone else confirm this?
I do understand that there are so many variables to
consider such as Processor type, pipeline, etc, etc.
Thats why I hope that this will be tried across many
processors and the results will be written so that
we can all find out the most effecient coding methods
with the tools we use.
Thanks All,
Michael Ritter
This is the first time I am posting code. If is does
not come out right, please let me know the proper
formatting code. TIA
------------------
I knew something was strange. I just fixed a bug, I have to
retest the whole thing. Sorry about that.
Michael
[This message has been edited by Michael Ritter (edited July 27, 2000).]
discussions about code optimization and found
many remarks about register variables and
pointers, etc. First let me say that there were
a few heated discussions about these things and
I don't want to turn this thread into one. I
just prefer to find out the truth and the best,
most efficient way of doing things (which is why
I use PB on my serious code). Since I could
not find any results from tests, I tried my own.
Below is the code to pick apart followed by the
results which were quite interesting. Take into
mind that I am a novice concerning the internal
workings of the processor, so this next remark is
speculation based only on my results thus far.
Based on the numbers, it would appear that there is
a slight overhead in registering these vars in the L1.
That overhead shows up in the code below. There is
no doubt that registering the vars is faster (just
look at the results for 10,000,000,000 iterations),
but being registered, they never break the .4 barrier.
They don't start to even out on my machine until
about 50,000,000 iterations. Under that number of
iterations, the memory variables are consistently
faster. Can anyone else confirm this?
I do understand that there are so many variables to
consider such as Processor type, pipeline, etc, etc.
Thats why I hope that this will be tried across many
processors and the results will be written so that
we can all find out the most effecient coding methods
with the tools we use.
Thanks All,
Michael Ritter
This is the first time I am posting code. If is does
not come out right, please let me know the proper
formatting code. TIA
Code:
'This is a quick test of the register variables.
'Results are at the bottom.
'Utiltized a weighted average of 10 calls to
'related functions over various iterations.
#COMPILE EXE "Regstr.exe"
#REGISTER NONE
DECLARE FUNCTION NoRegVars(NumOfIter AS DWORD) AS SINGLE
DECLARE FUNCTION RegVars(NumOfIter AS DWORD) AS SINGLE
%Iterations = 10000000000
'-----------------------------------------------------
FUNCTION PBMAIN
DIM nNoReg(9) AS SINGLE, nReg(9) AS SINGLE
DIM NoRegResult AS SINGLE, RegResult AS SINGLE
DIM i%
'time no register variables
FOR i% = 0 TO 9 STEP 1
nNoReg(i%) = NoRegVars(%Iterations)
NEXT i%
'results of no register
FOR i% = 0 TO 9 STEP 1
NoRegResults! = NoRegResults! + nNoReg(i%)
NEXT i%
NoRegResults! = NoRegResults! / 10
MSGBOX "Variables not registered: " & STR$(NoRegResults!)
'time registered variables
FOR i% = 0 TO 9 STEP 1
nReg(i%) = RegVars(%Iterations)
NEXT i%
'result for registered vars
FOR i% = 0 TO 9 STEP 1
RegResults! = RegResults! + nReg(i%)
NEXT i%
RegResults! = RegResults! / 10
MSGBOX "Variables Registered: " & STR$(RegResults!)
END FUNCTION
'-----------------------------------------------------
FUNCTION NoRegVars(NumOfIter AS DWORD) AS SINGLE
DIM dwNoReg???, dwTmpNoReg???, ts!, te!
ts! = TIMER 'timer start
FOR dwNoReg??? = 0 TO NumOfIter??? STEP 1
dwTmpNoReg??? = dwTmpNoReg??? + 1
NEXT dwNoReg???
te! = TIMER 'timer end
FUNCTION = te! - ts!
END FUNCTION
'-----------------------------------------------------
FUNCTION RegVars(NumOfIter AS DWORD) AS SINGLE
DIM ts!, te!
REGISTER dwReg???, dwTmpReg???
ts! = TIMER
FOR dwReg??? = 0 TO NumOfIter??? STEP 1
dwTmpReg??? = dwTmpReg??? + 1
NEXT dwReg???
te! = TIMER
FUNCTION = te! - ts!
END FUNCTION
'Machine 1: Pentuim III @ 500mhz w/ 128meg
' Michael Ritter (Dell Inspiron)
'
' @ 10,000 iterations by 10 calls averaged
' No Register Variables: Can't read it, too fast
' Registered Variables: .428125
'
' @ 100,000 iterations by 10 calls averaged
' No Register Variables: .00625
' Registered Variables: .428125
'
' @ 1,000,000 iterations by 10 calls averaged
' No Register Variables: .01132813
' Registered Variables: .4171875
'
' @ 10,000,000 iterations by 10 calls averaged
' No Register Variables: 0.1257813
' Registered Variables: 0.4171875
'
' @ 100,000,000 iterations by 10 Calls averaged
' No Register Variables: 1.389844
' Registered Variables: 0.4121094
'
' @ 1,000,000,000 iterations by 10 calls averaged
' No Register Variables: 13.41172
' Registered Variables: .4171875
'
' @ 10,000,000,000 iterations by 10 calls averaged
' No Register Variables: 20.04805
' Registered Variables: .4167969
------------------
I knew something was strange. I just fixed a bug, I have to
retest the whole thing. Sorry about that.
Michael
[This message has been edited by Michael Ritter (edited July 27, 2000).]
Comment