Something wired

[kanonet]

Ok i just found something really wired regarding to speed of GLB:

Code: [Select]

LOCAL start=0
LOCAL stop=200000
LOCAL stepping=0.005

time0=GETTIMERALL()
FOR i=start TO stop STEP stepping
value=1
NEXT
time0=GETTIMERALL()-time0
PRINT time0+" ms", 0,0Displayed time after execution: about 89 ms

Code: [Select]

LOCAL start=0
LOCAL stop=200000
LOCAL stepping=0.005

time0=GETTIMERALL()
FOR i=start TO stop STEP stepping
value=1
NEXT
time0=GETTIMERALL()-time0
LOCAL s$=value
PRINT time0+" ms", 0,0Displayed time after execution: about 112 ms

Im checking time for exactly the same code in both cases, but its significant slower if i convert the result to a string in an other part of the program (displaying the result with PRINT has the same effect). Does anyone has an idea why this happens?

[theprotocol]

My guess:

You're not strictly specifying the type of "value." Assigning it to a string later tells the compiler that "value" is a string instead of an integer. This would occur before runtime (it happens at compilation). So it's as if you wrote value$ vs. value%. The compiler is just guessing ahead of time what the variable is (your later code with s$=value changes its guess).

The performance could vary in that case between - assigning 1 to a string (probably internal parsing or casting here)- and assigning 1 to an integer (native).

[kanonet]

No, wrong guess, if i do not specify a type its always a float. But even if i declare it as float or integer directly i get the same result (you can try it yourself if you want).

[theprotocol]

No, wrong guess, if i do not specify a type its always a float. But even if i declare it as float or integer directly i get the same result (you can try it yourself if you want).

I see. Interesting...

[Qedo]

Hi kanonet,
on my computer in both cases the times are the same: 80ms
ciao
qedo

[erico]

just out of a noob curiosity...

If you leave declarations up to the "no strict declarations" on the options of the project/IDE.
Same results?

Not that this would answer the question at all, but it may be a help on understanding?
I will see to run those here to see what I get, but such is, beyond my understandings as a programmer. 

[kanonet]

@Qedo:
Interesting i tested it on two machines with two different CPUs (Intel i5-540M and AMD C-50), both had a difference in the times. Can you use a more complicated math instead of "value=1"? E.g. when i use "value=qSIN(i)" the difference is bigger, 90ms vs. 330ms. Is there a difference for you?

@erico:
If i do not declare "value" i get:
"value=1": 150ms vs. 150-160ms
"value=qSIN(i)": 340ms vs. 340-350ms
Same results if i declare value as GLOBAL.

[Moebius]

This is confusing.

I tried this code:

Code: [Select]

LOCAL start=0
LOCAL stop=200000
LOCAL stepping=0.005

LOCAL time0#, value#, s$

FOR trials = 0 TO 2

value = 0
time0=GETTIMERALL()
FOR i=start TO stop STEP stepping
value=value+1
NEXT
time0=GETTIMERALL()-time0
STDOUT time0+" ms\n"


NEXT

STDOUT "\n\n"


FOR trials = 0 TO 2

value = 0
time0=GETTIMERALL()
FOR i=start TO stop STEP stepping
value=value+1
NEXT
time0=GETTIMERALL()-time0
s$ = value
STDOUT time0+" ms\n"

NEXT

KEYWAIT
END
This gives me around 100ms for the pure loop, and 140ms for the loop which has "s$ = value" afterwards...


However, running this code:

Code: [Select]

LOCAL start=0
LOCAL stop=200000
LOCAL stepping=0.005

LOCAL time0#, value#, s$


value = 0
time0=GETTIMERALL()
FOR i=start TO stop STEP stepping
value=value+1
NEXT
time0=GETTIMERALL()-time0
STDOUT time0+" ms\n"


STDOUT "\n\n"

value = 0
time0=GETTIMERALL()
FOR i=start TO stop STEP stepping
value=value+1
NEXT
time0=GETTIMERALL()-time0
s$ = value
STDOUT time0+" ms\n"


KEYWAIT
END(The same code just w/o the for loops), I get 115ms and 140ms....

Using kakonet's original code (i.e. using 'value=1' instead of 'value=value+1'), with both snippets left in as above, I get the same times (115ms, 140ms).
Running either snippet on their own I get these times...

Using 'value = SIN(1)' instead, I get something like 4495ms for the one without the string, and 4505ms for the one with the string assignment afterwards.

I have tried things like adding a DELAY at the start and rearranging things, but get the same results.
Go figure 
This seems like it has to do with optimisation, although I don't understand why things would turn out differently within for loops, or with a conversion to a string afterwards....

[Qedo]

Hi kanonet,
on my computer CPUs Intel i7-2630QM GPU 540M in both cases with qSIN(i) the times are the same: 440ms +/-10.
There is no true difference.
ciao
qedo