Other than less typing throughout the program (where you might have lots ofrepeated random number generation in this example), are there any benefits to using CBM functions? Does it save bytes overall would be perhaps one that I could think of.
Many thanks,
Shaun.
repeated random number generation in this example), are there any benefits to using CBM functions? Does it save bytes overall would be perhaps one that I could think of.Other than less typing throughout the program (where you might have lots of
Many thanks,
Shaun.
Other than that, it's faster to inline code than to define a function.
For clarification, which is faster?
10 X=INT(64*RND(0)+1)
or
10 X%=64*RND(0)+1
For clarification, which is faster?
10 X=INT(64*RND(0)+1)
or
10 X%=64*RND(0)+1
Thanks for the hints all. I'll do some bench mark testing or whatever :-)
On 2018-04-18 05:38, Shaun Bebbington : All wrote:
Thanks for the hints all. I'll do some bench mark testing or whatever :-)
Please do. If benchmarking with a FOR loop over hundreds or thousands of repetitions is too hard to figure it out, then the answer isn't really important.
On Wednesday, 18 April 2018 16:41:28 UTC+1, Janne Johansson wrote:
On 2018-04-18 05:38, Shaun Bebbington : All wrote:
Thanks for the hints all. I'll do some bench mark testing orwhatever :-)
Please do. If benchmarking with a FOR loop over hundreds or thousands of
repetitions is too hard to figure it out, then the answer isn't really
important.
Hey! Good hint.
On 2018-04-18 09:37, Shaun Bebbington : Janne Johansson wrote:
On Wednesday, 18 April 2018 16:41:28 UTC+1, Janne Johansson wrote:
On 2018-04-18 05:38, Shaun Bebbington : All wrote:
Thanks for the hints all. I'll do some bench mark testing orwhatever :-)
Please do. If benchmarking with a FOR loop over hundreds or thousands of >> repetitions is too hard to figure it out, then the answer isn't really
important.
Hey! Good hint.
I noticed (after sending of course) that it may have been perceivable as
a harsh statement, hinting at lazyness or something, I meant more along
the lines of "if you try 100 loops and can't make out the difference,
then try 1000 loops then try 10k loops and so on, the difference might
be so small that its not worth coding your BASIC programs with %
sprinkled here and there for optimization reasons, but just go for
normal ordinary readability and simplicity since performance is then
bound by something else like algorithmic complexity and not the one-time conversions from ints to floats and back".
If you really need a basic program to run faster, there are a lot of compilers that pre-calculate and pre-parse and then make some kind of
machine language equivalent program out of it which you can run and
which will be lots faster. If that isn't fast enough still, code
important parts in ASM directly or at least code it up in CC65 using
C for some middle ground between compiled BASIC and doing it all in
ASM yourself.
SB> For clarification, which is faster?
SB> 10 X=INT(64*RND(0)+1)
SB> or
SB> 10 X%=64*RND(0)+1
Just guessing, I'd say the second one, or 10 X%=64*RND(0)+1
because in the first, your converting 64*RNND(0)+1 to an integer, then converting back to a single precision decimal point value.
Am 17.04.2018 um 04:46 schrieb John H. Guillory:
SB> For clarification, which is faster?
SB> 10 X=INT(64*RND(0)+1)
SB> or
SB> 10 X%=64*RND(0)+1
Just guessing, I'd say the second one, or 10 X%=64*RND(0)+1
because in the first, your converting 64*RNND(0)+1 to an integer, then converting back to a single precision decimal point value.
Effectively, calculations always happen in floating point, and INT()
returns a FP value in the floating point accu. Conversion will take
place on assignment to the destination variable. The INT() operation is similar to the truncation operation to fit the FP accu value into X%.
In fact, the major difference is that the first line has to copy 5 bytes
into a variable space and the second will copy 2 bytes.
There isn't even an advantage in space requirement for the variable;
both need 7 bytes, i.e. 2 bytes for the name (like A1 or B2% or C3$) and
5 for the value; an integer variable just wastes 3 bytes for the value.
It is different for integer vs. float arrays; in this case a % value is indeed packed into 2 bytes.
-hl
On 2018-04-18 09:37, Shaun Bebbington : Janne Johansson wrote:
On Wednesday, 18 April 2018 16:41:28 UTC+1, Janne Johansson wrote:
On 2018-04-18 05:38, Shaun Bebbington : All wrote:
Thanks for the hints all. I'll do some bench mark testing orwhatever :-)
Please do. If benchmarking with a FOR loop over hundreds or thousands of >>> repetitions is too hard to figure it out, then the answer isn't really
important.
Hey! Good hint.
I noticed (after sending of course) that it may have been perceivable as
a harsh statement, hinting at lazyness or something, I meant more along
the lines of "if you try 100 loops and can't make out the difference,
then try 1000 loops then try 10k loops and so on, the difference might
be so small that its not worth coding your BASIC programs with %
sprinkled here and there for optimization reasons, but just go for
normal ordinary readability and simplicity since performance is then
bound by something else like algorithmic complexity and not the one-time >conversions from ints to floats and back".
If you really need a basic program to run faster, there are a lot of >compilers that pre-calculate and pre-parse and then make some kind of
machine language equivalent program out of it which you can run and
which will be lots faster. If that isn't fast enough still, code
important parts in ASM directly or at least code it up in CC65 using
C for some middle ground between compiled BASIC and doing it all in
ASM yourself.
There seems to be two ways to do integers on the C64 (and yes I know floats are fastest), I was wondering about these two methods of generating a random positive number between 1 and 64 inclusive:
10 X=INT(64*RND(0)+1)
or
10 X%=64*RND(0)+1
The latter saves two whole bytes, but is it faster to convert to integer directly with the INT keyword, or is the implicit declaration below faster?
Second question, let's say you want to generate a random number in multiple places, you could use the above several times in a listing, but one could also define a function as I understand it, like:
0 DEF FN A(X)=X*RND(0)
So each time in your listing, you will have,
10 X%=FN A(39): Y%=FN A(24)
...
100 S%=FN A(10)+1: D%=FN A(10)+1
etc...
Other than less typing throughout the program (where you might have lots of repeated random number generation in this example), are there any benefits to using CBM functions? Does it save bytes overall would be perhaps one that I could think of.
Many thanks,
Shaun.
I've used all the compilers, and prefer Petspeed.
Am 17.04.2018 um 04:46 schrieb John H. Guillory:
SB> For clarification, which is faster?Effectively, calculations always happen in floating point, and INT()
SB> 10 X=INT(64*RND(0)+1)
SB> or
SB> 10 X%=64*RND(0)+1
Just guessing, I'd say the second one, or 10 X%=64*RND(0)+1
because in the first, your converting 64*RNND(0)+1 to an integer, then
converting back to a single precision decimal point value.
returns a FP value in the floating point accu. Conversion will take
place on assignment to the destination variable. The INT() operation is similar to the truncation operation to fit the FP accu value into X%.
In fact, the major difference is that the first line has to copy 5 bytes
into a variable space and the second will copy 2 bytes.
There isn't even an advantage in space requirement for the variable;
both need 7 bytes, i.e. 2 bytes for the name (like A1 or B2% or C3$) and
5 for the value; an integer variable just wastes 3 bytes for the value.
It is different for integer vs. float arrays; in this case a % value is indeed packed into 2 bytes.
For clarification, which is faster?
10 X=INT(64*RND(0)+1)
or
10 X%=64*RND(0)+1
Thanks for the hints all. I'll do some bench mark testing or whatever :-)
On Wednesday, 18 April 2018 16:41:28 UTC+1, Janne Johansson wrote:
On 2018-04-18 05:38, Shaun Bebbington : All wrote:
Thanks for the hints all. I'll do some bench mark testing orwhatever :-)
Please do. If benchmarking with a FOR loop over hundreds or thousands of
repetitions is too hard to figure it out, then the answer isn't really
important.
Hey! Good hint.
| Sysop: | Nelgin |
|---|---|
| Location: | Plano, TX |
| Users: | 512 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 190:38:09 |
| Calls: | 8,283 |
| Files: | 15,514 |
| Messages: | 927,754 |