"restrict" keyword need (aka: assume no aliasing) ??

[Mike Joseph]

Oops, topic should have read "restrict" keyword need_ED_....
----------
After reading the article at the link posted by
Peter Stephenson in the "What OOP in PB might look like" thread,
---------------------------------------------------
Steve--
Take a look at http://extreme.indiana.edu/~tveldhui...e97/index.html

Regards
Peter
---------------------------------------------------

I decided to see if I could determine if PB made optimizations
with pointers when no aliasing was used.

My test (which may be flawed) indicates that neither 0, 1 or 2
levels of indirection affect execution speed. It seems to me
that surely, there would be a difference in speed, with each
level of indirection but doesnt seem to be happening.

Below is the code I used to test this. For each of the 3 code
blocks, my Celeron 266 completes them in around 16.2 seconds.
Ive run each block multiple times and there is no measureable
difference; each one consistantly finishes at
around 16.2 +/- .2seconds

In conclusion (assuming my conclusions arent totally wrong
PB would probably benefit from the use of a "restrict" keyword
for pointer variables:

DIM p1 as LONG PTR RESTRICT

or via the use of a #OPTION NOALIAS metastatement so that the
compiler could optimize code which didnt alias pointers. Incidentally,
this is an option in the "advanced optimizations" options dialog
for Visual Basic 5/6, and enabling it makes a very
significant difference (for the better)in program execution speed.

Assuming my test code is invalid, maybe someone else can write
one that is more appropriate? Or assuming my entire assumption is
wrong, can someone explain to me why the various levels of
indirection dont affect execution speed? And if its my code,
can you produce code which shows that under some conditions,
increased levels of indirection does slow down execution?
Thanks
-Mike

' testing the affects of pointer aliasing on the compiler
#COMPILE EXE
#DIM ALL
#REGISTER NONE
#INCLUDE "win32api.inc"

%ITTERATIONS = 10000000

DECLARE SUB ChangeL (BYREF p AS DWORD,BYREF p1 AS DWORD)

FUNCTION PBMAIN()
    DIM pOriginal AS LONG PTR
    DIM plng AS LONG PTR
    DIM plng2 AS LONG PTR
    DIM plng3 AS LONG PTR
    DIM plng4 AS LONG PTR
    DIM plng5 AS LONG PTR
    DIM plng6 AS LONG PTR
    DIM pLng7 AS LONG PTR
    DIM pLng8 AS LONG PTR
    DIM lng AS LONG
    DIM lTest AS LONG
    DIM lngTest2 AS LONG
    DIM sng AS SINGLE
    DIM i AS LONG

    sng = TimeGetTime
    pOriginal = VARPTR (lTest)
    
    ' assign our test pointers
    pLng = VARPTR (lTest)
    pLng2 = VARPTR (pLng)
    pLng3 = VARPTR (pLng)
    pLng4 = VARPTR (lngTest2)
    plng5 = VARPTR (pLng4) 
    pLng6 = VARPTR (pLng5)
    pLng7 = VARPTR (pLng3)
    pLng8 = VARPTR (pLng3)
   
    FOR i = 1 TO %ITTERATIONS

        lng = CLNG(RND * 1000)

        ' TWO LEVELS BLOCK
        '@@@pLng8 = lng
        'IF i MOD 2 = 0 THEN
        '   changeL BYREF pLng8, BYREF pLng6
        'ELSE
        '   changeL BYREF pLng8, BYREF pLng7
        'END IF
        
        ' ONE LEVEL BLOCK
        '@@pLng2 = lng
        'IF i MOD 2 = 0 THEN
        '   changeL BYREF pLng2, BYREF pLng3    '  switch the pointers back and forth each itteration
        'ELSE
        '   changeL BYREF pLng2, BYREF pLng5
        'END IF
        
        ' ZERO LEVEL BLOCK
        @pLng = lng
        IF i MOD 2 = 0 THEN
            changeL BYREF pLng, BYREF pLng4
        ELSE
            changeL BYREF pLng, BYREF pOriginal
        END IF
    NEXT

    sng = TimeGetTime - sng
    MSGBOX "Time Elapsed: " & FORMAT$(sng/1000, "####.####") & " seconds"
END FUNCTION

' Call this sub to switch the pointer each loop in hopes
' of limiting the compilers ability to optimize the indirection
SUB changeL(BYREF p AS dword, BYREF p1 AS dword) 
    p = p1
    
END SUB

------------------

[NOTE: I corrected the ChangeL() to use BYREF DWORDS. Same results
except that now the avg time is 16.5 for all blocks +/- .2 seconds]




[This message has been edited by Mike Joseph (edited September 19, 2000).]