How does CPC handle numbers through BASIC?

[HAL6128]

Maybe there's someone here who can help me to understand how the CPC handles numbers within BASIC programs?

I always thought that faster to calculate something with the help of an assigned variable (constant) instead of using a direct number. To ensure I made two tests. One with real numbers and one with integer numbers:

Code Select Expand


10 MODE 2
20 DEFREAL a-z
25 PRINT "duration test with real numbers (defreal a-z)"
30 :
40 '*** test with a number
50 PRINT"x=x+1 (1000 times)";
60 x=1
70 t1=TIME
80 x=x+1
90 IF x=1000 THEN 100 ELSE 80
100 t2=TIME:duration=t2-t1:PRINT duration
110 :
120 '*** test with a variable
130 PRINT"x=x+y (1000 times) with y=1";
140 x=1:y=1
150 t1=TIME
160 x=x+y
170 IF x=1000 THEN 180 ELSE 160
180 t2=TIME:duration=t2-t1:PRINT duration
190 :
200 '*** test with a "dimensionized" variable
210 PRINT"x=x+y(0) (1000 times) with y(0)=1";
220 x=1:DIM y(1):y(0)=1
230 t1=TIME
240 x=x+y(0)
250 IF x=1000 THEN 260 ELSE 240
260 t2=TIME:duration=t2-t1:PRINT duration
270 :


Code Select Expand


10 MODE 2
20 DEFINT a-z
30 PRINT "duration test with integer numbers (defint a-z)"
40 :
50 '*** test with a number
60 PRINT"x=x+1 (1000 times)";
70 x=1
80 t1!=TIME
90 x=x+1
100 IF x=1000 THEN 110 ELSE 90
110 t2!=TIME:duration!=t2!-t1!:PRINT duration!
120 :
130 '*** test with a variable
140 PRINT"x=x+y (1000 times) with y=1";
150 x=1:y=1
160 t1!=TIME
170 x=x+y
180 IF x=1000 THEN 190 ELSE 170
190 t2!=TIME:duration!=t2!-t1!:PRINT duration!
200 :
210 '*** test with a "dimensionized" variable
220 PRINT"x=x+y(0) (1000 times) with y(0)=1";
230 x=1:DIM y(1):y(0)=1
240 t1!=TIME
250 x=x+y(0)
260 IF x=1000 THEN 270 ELSE 250
270 t2!=TIME:duration!=t2!-t1!:PRINT duration!
280 :

both codes are pretty the same but using variables (real/integer)

The results are in the Pictures. Ok, working with integer is faster, but how could it be that handling real numbers is different?

@TFM: thanks for seeing that! (copy and paste failure).

[TFM]

line 260 needs to be a copy of line 180 (first listing) 
EDIT: You did it!
Interesting result! 

[AMSDOS]

Not quite sure, are you using TIME to calculate the speed of the routine. The test with a variable (line 120-180) looks to me you're still using Real Numbers.


It probably won't help in your cause, I just think in BASIC depending on how your code is written depends on performance as in my case I think using GOTO instead of a WHILE..WEND Loop improves performance and FOR Loops to me seem fast as well. I don't think anything is faster than feeding the values through to an array, though the compromise with that is the use of memory.


I think what you've got there with your findings is x=x+1 is going to be faster than x=x+y because the machine knows straight away what to increment x with, but in the case of x=x+y, y needs to have it's value checked which might explain the delay.


What happens if that array was being incremented instead of having a value from an array incrementing x?

[TFM]

One is with real numbers, the other one is with integers.

[AMSDOS]

It wasn't there when first posted. 

[TFM]

Yes it was      .... ok, a bit late it popped up! 

[HAL6128]

...oh, I modified my first post, sorry.

The reason why I doing this is to know what the CPC is doing with numbers? What is the fastest way for calculation?
Is "1" really a 1 or will it somehow converted before calculating? Ok, an integer "1" needs less space in memory than a real "1" but both are still a "&x0000 0001", aren't they?
And how comes that that an real number calculation with "x=x+y" is faster than "x=x+1", whereas an integer calculation with "x=x+y" is slower than "x=x+1". Not talking about a very slow using of arrays (I've heard the same that working with arrays is the fastest way using numbers.)

[AMSDOS]

BASIC has always assumed numbers to be decimal based from startup, unless specifically being told that DEFINT a-z is an integer or variables have an "%" after it. The lag with x=x+1 I think is due to more memory being assigned to "x", since Real numbers use more memory than Integer based ones, even if "x" is being incremented by 1 because BASIC thinks at some point you might want increment a Decimal number. What happens when you increment a Decimal Number to an Integer based, it might only increment the Integer part of the number but disregard anything after the decimal point.

[ZbyniuR]

Theoretically jump GOTO and GOSUB is little bit faster to line with smaller number. But few line difference is no big difference.
Look at my experiment on picture.

Real +1 - t=995
Int. +1 - t=757
Real +y - t=980
Int. +y - t=805

So. With real numbers faster is using variable, but in integer faster is using number. Fascinating.

[AMSDOS]

...oh, I modified my first post, sorry.

The reason why I doing this is to know what the CPC is doing with numbers? What is the fastest way for calculation?
Is "1" really a 1 or will it somehow converted before calculating? Ok, an integer "1" needs less space in memory than a real "1" but both are still a "&x0000 0001", aren't they?
And how comes that that an real number calculation with "x=x+y" is faster than "x=x+1", whereas an integer calculation with "x=x+y" is slower than "x=x+1". Not talking about a very slow using of arrays (I've heard the same that working with arrays is the fastest way using numbers.)

Unsure why x=x+y is faster than x=x+1 in real number calculations, can only presume that if y has a value in it BASIC has processed this and knows y equals 1. A line like x=x+1 on the other hand probably has to process the 1 as it moves along and check if there's anything after that 1. What would happen if in your Real program "y" become "y%", would that improve performance over an "y" variable?

[AMSDOS]

Interesting, I'm using the same program, but my results are a little bit faster. I've Run the program the other way around though.


When I use the program with the y variable and specify the y% variable the result is 1021 compared to 961 if I use y variable. If I have x as integer and leave y as a real the result is 1022.

[ZbyniuR]

Different result, probably because I was use emulator set on 464. In 6128 mode I have the same result like you.
Anyway, it seems like use DEFINT without % working faster than opposite combination.


My explanation is:

Real number must be changed into 5 byte before do calculation, keeping this number in variable is faster because before calculation it is already in 5 byte form.

Integer number in variable must be reach from right place in memory during runing program, so using direct number don't have to do that.

Using with % character mean - one more byte to interpret for Basic, so DEFINT is fater. Similar problem is when you add unnecessary spaces. For example
: x = x + 1 :    instead    :x=x+1:     

[Prodatron]

Real number must be changed into 5 byte before do calculation, keeping this number in variable is faster because before calculation it is already in 5 byte form.

Yes, this is probably the explanation for all this mystery.
Replace X=X+1 with X=X+1.0 and you will see: It works faster with real numbers. So it seems, that the 1 is stored as integer inside the code and has to be converted into real first. The 1.0 is already stored as real and so there is no need to convert it (like if it is already stored in Y as real).

[ZbyniuR]

WOW!
1.0 it is even faster way for real number then use y.

1 - t973
y - t961
1.0 - t930

[HAL6128]

Thanks to all for the ideas and explanations. There might be a lot of converting stuff before doing the calculation.
At least I got a little more reliable understanding for my BASIC programs in terms of high repetitive calculating and using numbers.