Strange problem in PB/CC 4

[John Gleason]

MCB, If you're using integer exponents, it's usually faster to multiply than to raise to a power as shown in this code:

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG
    LOCAL t, t2 AS QUAD, ii, x AS EXT
    '------------------- x^4 -----------------------
       TIX t
    FOR ii = 1 TO 10000000
       x = ii ^ 4
    NEXT
       TIX END t
    
       TIX t2
    FOR ii = 1 TO 10000000
       x = ii * ii
       x = x * x
    NEXT
       TIX END t2
    
    ? STR$(t / t2, 4) & " x faster"
    '===============================================

    '------------------- x^2 -----------------------
       TIX t
    FOR ii = 1 TO 10000000
       x = ii ^ 2
    NEXT
       TIX END t

       TIX t2
    FOR ii = 1 TO 10000000
       x = ii * ii
    NEXT
       TIX END t2

    ? STR$(t / t2, 4) & " x faster"
    '===============================================
    WAITKEY$
END FUNCTION

If possible, try to make calculations integer types. You may be able to pre-calculate values that you reuse, even transcendental ones. How you temporarily store your intermediate values can matter too. If you'd like to post example code from an "innermost loop", I'd bet someone here could recommend significant optimization possibilities.

[Michael Bell]

Thanks for that RC. I've just tried a benchmark with +, -, / and * operations, and also found EXT to be the fastest (by about 28% in my test). If the values are passed to a separate function, then the advantage goes the other way (in my test, passing an EXT was about 25% slower than passing a SINGLE if passed BYVAL, and about 37% slower if passed BYREF) - not too surprising perhaps.

Incidentally, I accidentally found that matching the variable types makes a big difference, e.g. x!/2! calculates much quicker than x!/2## - again, perhaps not too surprising.

MCB

[Paul Dixon]

Michael,
for large arrays of data SINGLE is fastest then DOUBLE then EXT because the limit is usually the rate at which you can read the data from memory and larger data types take longer to read.

For single values then EXT is fastest because the compiler will store up to 4 EXT variables in the FPU registers but it will always access SINGLE and DOUBLE from memory.

Try adding #REGISTER NONE to the start of your code to stop registers being used and the speed using EXT variables should fall.

Paul.

[John Gleason]

e.g. x!/2! calculates much quicker than x!/2## - again, perhaps not too surprising.

MCB

This brings up an optimization idea: Even tho division by 2 doesn't benefit as much as other divisors, It's almost always faster to multiply by the reciprocal than divide by a constant:

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG
    LOCAL t, t2 AS QUAD, ii, x, y, constDiv AS EXT
    
    '------------------- x / 2 -----------------------
       TIX t
    FOR ii = 1 TO 10000000
       x = ii / 21
    NEXT
       TIX END t
    
       TIX t2
       constDiv = 1 / 21
    FOR ii = 1 TO 10000000
       y = ii * constDiv
    NEXT
       TIX END t2
    
    ? STR$(t / t2, 4) & " x faster"
    WAITKEY$   
END FUNCTION

[Michael Bell]

if you're using integer exponents, it's usually faster to multiply than to raise to a power

Very interesting John. I am pretty random about coding this sort of thing. For example, I am as likely to type

distance=SQR(x^2##+y^2##)

as

distance=SQR(x*x+y*y)

From running your code it would seem that the latter might run about 8 times faster - definitely worth knowing for computer-intensive applications.

almost always faster to multiply by the reciprocal than divide by a constant

About 3.5 times faster in your example. Again, not something that would have occurred to me, and definitely worth knowing. I might also try noticing more when other chunks of expressions don't change between iterations of a loop, and so perform calculations once rather than many times.

Try adding #REGISTER NONE to the start of your code to stop registers being used and the speed using EXT variables should fall.

Tried that - code using EXT variables took almost three times as long to run with #REGISTER NONE. From this I conclude that I should think carefully about the precision of large arrays that get moved around.

Thanks for the useful suggestions guys!