Re: TIB: program speed
[Prev][Next][Index][Thread]
Re: TIB: program speed
This is in relation to my 85, but the 86 is analagous, and the 82/83 are close
Okay, when you edit a program on your calc, you are essentialy editing text, each
character gets a byte (I believe, however, if you use something like the SIN key,
it puts a token instead of S-I-N, but more on that later). Most of your program
is represented one byte per character. Your program is big. When you run it,
however, some of that text (like SIN) is converted into a smaller number of binary
characters, saving some space. You can see this for yourself. Get a program
(1000 bytes or so) and run it. Now it is tokenized. Goto the delvar screen and
record the size. Now edit the program, and check the size again. It grew! you
untokenized it! Now, run it. It will take longer to begin, because the calc
starts by tokenizing the program if it's not (come to think of it, I don't know if
this applies to the 82/83 or not, because I've never noticed these lag times after
editing on them before.....)
Anyway, that's tokenization.
As for the If Then stuff.....
The message I quoted said that if the IF condition is false, then it ignores the
next command, but it CAN'T. Without checking the next command, the calc does not
now if the If statement has a then. If a then exists, it has to check for an
else, and an end, which leads to recursions with misplaced Goto's. Anyway, If the
calc immediatly ignores the next line, then it will skip two lines down, which we
know it doesn't do if there is a THEN.
Now, the tokenization:
If the IF and THEN commands each have their own token, then they are placed on
seperate lines in the tokenized version of a program, hence the extra check for a
THEN when an IF is encountered, as explained above. However, if an IF/THEN
statement was combined as one token, then there would be no slowdown as compared
to just an IF statement, because each would have different ROM routines to handle
each token (a little off subject).
A subsequent message from TA Advark (spelling! sorry) said that If and Then
statments have their own tokens. Consequently,
If x==2
Then
1+c->C
End
is slower than
If x==2
1+c->C
Which is ultimately faster, the If/command or the boolean?
Here's my sample prog, with two timings, and my reasoning behind it.....
Disp "If" Let me know what I was doing
0->C:0->x inits variables
Pause got ready to time, hit enter on a
second-hand tick
For (x,1,1000 do it a thousand times (so I can cont in
seconds...)
If 1==mod(x,2 my test, true 1/2 time, false other half (no
time variation, see below)
1+C->C the operation
End end the loop
ClLCD let me know to stop counting
0->C:0->x reinit, so we start in the same fashion
Disp "Boolean" let me know again
Pause get ready
For(x,1,1000 see above
C+(1==mod(x,2->C C+test results
End stop and finish counting
I ran this twice, and both times the If block took 21 secs, and the boolean method
18
Another variation, which I tried, is to replace the interval with -499,500 in the
for staement. Then, the test becomes 0<x; whixh is false when x is -1 to -499 and
0, so 500 times, and true in the opposite direction. So, it's still 1/2 true, 1/2
false.
Results?
Well, they surprised me...
I tried it twice, and the If's took 39 seconds, and the booleans 13!!! 1/3 the
lag! I don't know why this is, though. The best way to speed up your routine is
to probably analyze what the test will return most of the time, and try several
runs like those above to determine which type of test ( <>= etc) gives the best
return rate.
Good luck! Hope this cleared some stuff up!
Jeremy Braun
Any other inconsistancies? let me know. Oh yeah, if you try these progs yourself,
remember, calc speed depends on your batteries. Plus, the 82 was released after
the 85, and may have a better basic interpreter...faster...!!!!!!OH YEAH! You
write 82 progs tokenized already: If's, Then's and sin's and such are treated as
one character while editing, right? Well, that's your token, which explains the
faster initial load times, because the calc doesn't have to tokenize! Anyway, Bye!
Jody wrote:
> Jeremy Braun wrote:
> >
> > > Yes, when a calculator encounters an If statement with a False boolean,
> > > it ignores the next command completely.
> >
> > Nope, it Can't (unless something else is true, noted below)! An if/then
> > statement on 85/86/82/83 the next line after the if is then, so it has to
> > check (92 is on same line, so its different)UNLESS-an if/then loop is
> > tokenized as a single token. ie-the token for an if check is different for
> > an if/then/else/end check.
> >
> > Just a thought,
> > Jeremy Braun
> >
> > PS-don't know much about the tokens on calcs, anyone know what exactly is
> > replaced, and if I'm right or wrong?
> >
> > Also, on of the reasons that Q/(C==2->R is slow is that the calc has to do a
> > test, then a division, and then a memory transfer. And division is
> > notoriously slow on computers...the if loop simply does a test and then the
> > memory transfer, minus the division. :)
>
> Wow! I'm sure if I had understood that, I would have learned a lot. :)
> Okay...It sounds like, from your first paragraph, that you're talking
> about If, THEN statements. I was thinking more along the lines of
> If <logic statement>
> <do a command>
> Next, what is a token? What is tokenization? What is happening? Why is
> it important?
> In my original example it was Q+(C=2->Q, not division. (Note the
> single =. I'm using an 83, so I don't need the ==) But I don't think
> that is important - it COULD have been a division. So, if I'm getting
> this right, you're saying that it is FASTER to do
> :If C=2
> :Q+1->Q (or Q/5->Q or whatever)
>
> and it is SLOWER to do
> :Q+(C=2->Q
>
> Do I got it right?
>
> Jody Snider
> jody1@alaska.net
References: