RXB - Rich Extended Basic

[jstimson]

Lots of tempers. Time to chill and step back, take a look at what's being tested.

 

First of all, the reason we care about TI BASIC is that it is the baseline against which we are comparing the efficiency of the RND statement. We know for a fact that it is handled badly in XB, so the goal is to find out not only how much faster than XB a new routine can be, but also to see how that compares against the baseline.

 

Without a baseline that everyone can agree to, measurements are meaningless.

Without standardized tests where only the specific item under test is being changed, measurements are meaningless.

 

I am currently in the process (for an entirely different reason than this post), compiling a large variety of performance tests on the various ways things can be done in XB. For example, using SGN vs a straight logic comparison against 0 (SGN is about 1ms slower per call). My test harness for comparisons is always static, with as little as possible being changed in order to accomodate the actual item under test.

 

I found, in my tests, that the XB call takes about 49 ms longer than the native TI call. Heck, even using the PEEK -31880 call (with randomize called everytime!) is only 11 ms longer than the native TI call. So anybody using XB should be PEEKing everytime and ditch the RND call entirely.

 

BTW, I love the effort being put forward in extending the life and functionality of the TI. Projects such as RXB, XB 2.7 cartridge, XB compiler, display enhancements, etc. are very much things that I am following.

[senior_falcon]

It is easy enough to find out how long RND takes in TI BASIC, in XB and in RXB, and those tests have been done. (Set up a loop with RND and time it, then remove the RND and time that. The difference is the amount of time needed to generate a RND.) The only other issue that matters is how much of a speed improvement can you expect from the new RND when running a "typicall" program, whatever that is. The only meaningful test for this is to compare the same program running in XB (or an older RXB) and in RXB with the new RND. What useful information about the speed of the random number generator would come from testing RXB against TI BASIC using a large program? That is like comparing kiwi fruit with pomegranites. Kaleidoscope comes to mind, as that was what Rich chose for one of his videos. Although written in TI BASIC, it runs fine in RXB. Obviously the performance gain will depend on the proportion of RNDs to other program statements. You could pick a program that maximizes the speed gain or a different one that minimizes it. I don't want to do either. I just want to know what could be expected in a typical program.

[jstimson]

It is easy enough to find out how long RND takes in TI BASIC, in XB and in RXB, and those tests have been done. (Set up a loop with RND and time it, then remove the RND and time that. The difference is the amount of time needed to generate a RND.) The only other issue that matters is how much of a speed improvement can you expect from the new RND when running a "typicall" program, whatever that is. The only meaningful test for this is to compare the same program running in XB (or an older RXB) and in RXB with the new RND. What useful information about the speed of the random number generator would come from testing RXB against TI BASIC using a large program? That is like comparing kiwi fruit with pomegranites. Kaleidoscope comes to mind, as that was what Rich chose for one of his videos. Although written in TI BASIC, it runs fine in RXB. Obviously the performance gain will depend on the proportion of RNDs to other program statements. You could pick a program that maximizes the speed gain or a different one that minimizes it. I don't want to do either. I just want to know what could be expected in a typical program.

 

That's fine if all you care about is that this program runs faster under one implementation of Basic vs another. If you want to dig deeper and find out where the actual speed gains are, you have to start isolating statements and measure each one. Otherwise you may attribute all the speed gain to one specific call when in fact there are other optimizations and improvements that added to it. I would love to add RXB into my benchmark suite but I don't have the required hardware (I believe) to run it. Here's another finding from my benchmarks.... multi-statement lines do not give a noticable speed improvement vs statements spread over multiple lines. I was sort of surprised at that.

[Willsy]

No lost tempers here! Rich is a cool guy and his GPL knowledge is second to none. He's definitely a good guy to have around and we can all learn a lot from him. I just get the feeling that he sometimes fails to properly read folks responses and digest what they're saying before responding. But RXB is a seriously cool bit of work. No doubt about that. :-)

[Willsy]

Double post

Edited September 17, 2014 by Willsy

[RXB]

Since we've been comparing apples to oranges regarding what you can and cannot do in the various Basics, fbForth 2.0 can run the program in post #416 8 times faster than RXB or TIXB using floating point RND (same as all of the Basics must do with 4 calls to integer RND) and 22 times faster with integer RND. I think these may well be close to ALC speeds.

 

...lee

But this is a RXB thread and I put the TI Basic RND into RXB so what you are talking about as far from the point of this thread as you can get.

Just as pointless as how fast RND is in anything except TI Basic and XB or RXB.

[RXB]

You are the one who initially made the comparison with TI BASIC:

Post #352: "Now to test against TI BASIC."

Post #357: A video comparing TI BASIC with RXB and TI XB

Post #387: A video comparing TI BASIC with RXB.

In both videos you maintain that RXB "smokes" TI BASIC because the random number generator is faster. How can this be? If I understand you correctly, your new random number generator is the same as the TI BASIC random number generator. In post #388 I outlined a way to test how long each statement takes to execute and showed that it is the HCHARs that make BASIC so slow. I also showed that the TI BASIC random number generator is almost 6 times faster than the XB random number generator. Since you are using the same code an RND in the new RXB should be almost as fast and at least 5x faster than the former XB RND.

 

OK fine, so the new RND is at least 5x faster. How much of a speed increase does that translate to in the real world. As you point out, one does not normally write a program that just loops and generates RNDs. I wrote the program in post #416 to get an idea and was intrigued to find that the new RXB ran it almost 80% faster compared to standard XB. But that is still not a real program. Kaleidoscope in your original video is a real program. I have it on a floppy somewhere, but you have it available more easily. I was just wondering how much difference the new RND would make running in RXB compared to running exactly the same program in standard XB, and speculated that it might be around 30% faster. That is a substantial increase in speed and if you run that test as described, then, and only then, can you say that the speed increase is due to the new RND and nothing else.

Very true the issue is that in one of the videos I may have not loaded the TI Basic RND code into RXB 2014 yet so it appears the same speed as RXB or XB. (My fault for not checking.)

 

This last video I made sure to check and the comparison was run almost 3 hours doing nothing but counting and the result was RXB smoked XB or RXB 2102.

 

And like I said as it is only doing a RND check and nothing else TI Basic is faster then RXB 2014 by about 10%, but is 3 times faster then RXB 2012 or XB.

[RXB]

Lots of tempers. Time to chill and step back, take a look at what's being tested.

 

First of all, the reason we care about TI BASIC is that it is the baseline against which we are comparing the efficiency of the RND statement. We know for a fact that it is handled badly in XB, so the goal is to find out not only how much faster than XB a new routine can be, but also to see how that compares against the baseline.

 

Without a baseline that everyone can agree to, measurements are meaningless.

Without standardized tests where only the specific item under test is being changed, measurements are meaningless.

 

I am currently in the process (for an entirely different reason than this post), compiling a large variety of performance tests on the various ways things can be done in XB. For example, using SGN vs a straight logic comparison against 0 (SGN is about 1ms slower per call). My test harness for comparisons is always static, with as little as possible being changed in order to accomodate the actual item under test.

 

I found, in my tests, that the XB call takes about 49 ms longer than the native TI call. Heck, even using the PEEK -31880 call (with randomize called everytime!) is only 11 ms longer than the native TI call. So anybody using XB should be PEEKing everytime and ditch the RND call entirely.

 

BTW, I love the effort being put forward in extending the life and functionality of the TI. Projects such as RXB, XB 2.7 cartridge, XB compiler, display enhancements, etc. are very much things that I am following.

The new RND in RXB 2014 will be faster then a CALL PEEK as the CALL PEEK has to be manipulated first before use. Example:

100 CALL HCHAR(INT(RND*24)+1,INT(RND*32)+1,INT(RND*128)+32)

Is faster than doing a CALL PEEK 3 times for random numbers to do that same one line as above.

 

In current XB yes the CALL PEEK would be faster.

 

By the way I also did a test and posted the result of this program in all of them:

100 N=RND

110 C=C+1

120 GOTO 100

 

I ran this in TI Basic, XB, RXB 2012 and RXB 2014 and posted the results. TI Basic was the fastest with RXB 2014 10% slower. Go back and read my posts.

Edited September 17, 2014 by RXB

[RXB]

It is easy enough to find out how long RND takes in TI BASIC, in XB and in RXB, and those tests have been done. (Set up a loop with RND and time it, then remove the RND and time that. The difference is the amount of time needed to generate a RND.) The only other issue that matters is how much of a speed improvement can you expect from the new RND when running a "typicall" program, whatever that is. The only meaningful test for this is to compare the same program running in XB (or an older RXB) and in RXB with the new RND. What useful information about the speed of the random number generator would come from testing RXB against TI BASIC using a large program? That is like comparing kiwi fruit with pomegranites. Kaleidoscope comes to mind, as that was what Rich chose for one of his videos. Although written in TI BASIC, it runs fine in RXB. Obviously the performance gain will depend on the proportion of RNDs to other program statements. You could pick a program that maximizes the speed gain or a different one that minimizes it. I don't want to do either. I just want to know what could be expected in a typical program.

 

Again I ran a test program:

100 N=RND
110 C=C+1
120 GOTO 100

This test was run in TI Basic, RXB 2014, RXB 2012 and XB and I posted the results.

That is your baseline and TI Basic was about 10% faster then RXB 2014 but also 3 times the speed of RXB 2012 or XB.

Please go back and read the post again.

[RXB]

Again this is a repost of the results and the program used. I did not post a video as I already took 6 hours to make the last one.

So next let us test the second method but of course TI Basic has to remain with a line number per each command unlike XB or RXB that can use colons on a single line.

So this test ran 30 minutes:

103826 TI Basic equals per minute 3460

95374 RXB 2014 equals per minute 3179

28824 RXB 2012 equals per minute 960

28745 XB equals per minute 958

This is the program used in TI Basic, RXB 2014, RXB 2012 and Extended Basic.

100 N=RND

110 C=C+1

120 GOTO 100

Edited September 17, 2014 by RXB

[+Lee Stewart]

I found, in my tests, that the XB call takes about 49 ms longer than the native TI call.

 

What is "the native TI call"?

 

Heck, even using the PEEK -31880 call (with randomize called everytime!) is only 11 ms longer than the native TI call. So anybody using XB should be PEEKing everytime and ditch the RND call entirely.

 

???? PEEKing the VDP interrupt timer which can only ever have 256 different, linearly changing values (only 1 byte changes) does not double for the RND routine, which returns an 8-byte pseudo-random number.

 

The biggest problem with RND in all of the Basics under discussion is that they are composing an 8-byte, floating point number, when only the first 2 bytes would be sufficient for screen position. TI Basic's "fast" RND makes 4 calls to the console GPL ROM's RAND routine to do this. It would be nice to have the option to make just 1 call to the GROM RAND routine.

 

...lee

[RXB]

 

What is "the native TI call"?

 

 

???? PEEKing the VDP interrupt timer which can only ever have 256 different, linearly changing values (only 1 byte changes) does not double for the RND routine, which returns an 8-byte pseudo-random number.

 

The biggest problem with RND in all of the Basics under discussion is that they are composing an 8-byte, floating point number, when only the first 2 bytes would be sufficient for screen position. TI Basic's "fast" RND makes 4 calls to the console GPL ROM's RAND routine to do this. It would be nice to have the option to make just 1 call to the GROM RAND routine.

 

...lee

What do you mean 4 calls to TI Basic RND? I copied it exactly and it does it each byte to fill up the Floating point buffer so I guess that would be 4 times.

* RXB BASIC RND REPLACEMENT FROM TI BASIC
NRND   ST   >3F,@FAC       * Exponent    
       ST   >4B,@VAR5      * Loop counter
NRND1  RAND >63            * 0?
       CZ   @RANDOM        * No, go on
       BR   NRND3     
       DEC  @FAC           * 0?
       CZ   @FAC           * End with 0
       BS   NRND4          * Go on
       BR   NRND1
NRND2  RAND >63            * Till 100
NRND3  ST   @RANDOM,*VAR5  * All digits
       CEQ  >51,@VAR5      * Till >8351
       BS   NRND5 
       INC  @VAR5          * Increase loop counter
       BR   NRND2 
NRND4  CLR  @FAC1          * Set 0
NRND5  XML  CONT

But this is tons faster then the XB RND that does so much Floating point math it is silly.

<0363> A295 42,03,23 X2SEED BYTE >42,>03,>23,>15,>00 * =   33521, X2 INITIAL VAL
       A298 15,00
<0364> A29A 43,02,3E X1SEED BYTE >43,>02,>3E,>2A,>17 * = 2624223, X1 INITIAL VAL
       A29D 2A,17
<0365>               ***********************************************************
<0366>               *           PSEUDO-RANDOM NUMBER GENERATOR
<0367>               *      X(N+1) = (A*X(N)+C) MOD M;  RND = X/M
<0368>               *    WHERE:                 X = X2 * 1E7 + X1
<0369>               *                           A = A2 * 1E7 + A1
<0370>               *                           C = C2 * 1E7 + C1
<0371>               *                           M = 1E14
<0372>               * ASSUMPTIONS:
<0373>               *  (1) All numbers are integers; fractional parts are
<0374>               *      truncated
<0375>               *  (2) If the variables listed below start in the ranges
<0376>               *     specified. They will also end in the ranges specified
<0377>               *
<0378>               * CONSTANTS: 0 <= A2 < 5E6 ; 0 <= C2 < 1E7
<0379>               *            0 <= A1 < 5E6 ; 0 <= C1 < 1E7
<0380>               * VARIABLES: 0 <= X2 < 1E7 ; 0 <= T1 <= 1E14 ; 0 <= T2 < 1E
<0381>               *            0 <= X1 < 1E7 ; 0 <= T3 <= 1E14 ; 0 <= T4 < 1E
<0382>               *
<0383>               *        STACK USAGE:
<0384>               *            CONSTANT REFS      CONTANT REFS    CONTANT REF
<0385>               * +---------+      IN/OUT            IN/OUT          IN/OUT
<0386>               * | STACK+4 | X2*A1(F)(H)       --    ----      --    ----

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0016 
EQUATES EXEC-359
<0387>               * +---------+
<0388>               * | STACK+3 |   T2 (C)(J)       --    ----      --    ----
<0389>               * +---------+
<0390>               * | STACK+2 |   T1 (B)(D)   new X1   (E)(N)     --    ----
<0391>               * +---------+
<0392>               * | STACK+1 |old X1(A)(G)       T3   (K)(L) new X2   (M)(P)
<0393>               * +---------+
<0394>               ***********************************************************
<0395>               * COMPUTE NEW VALUE FOR X1, SAVE IT IN V@RNDX1
<0396>               *                             STACK
<0397>               *                               SREFS   FAC CONTENTS
<0398> A29F 35,00,05 NRND   MOVE 5,V@RNDX1,@FAC        FAC = X1
       A2A2 4A,A3,A5
<0399> A2A5 86,4F           CLR  @FAC5                 FAC = CLR
<0400> A2A7 87,50           DCLR @FAC6                 FAC = CLR
<0401> A2A9 0F,77           XML  VPUSH          (A)    FAC = X1
<0402> A2AB 31,00,08        MOVE 8,G@RNDA1,@ARG        ARG = A1
       A2AE 5C,A3,57
<0403> A2B1 0F,08           XML  FMUL                  FAC = X1*A1
<0404> A2B3 31,00,08        MOVE 8,G@RNDC1,@ARG        ARG = C1
       A2B6 5C,A3,67
<0405> A2B9 0F,06           XML  FADD               T1=FAC = X1*A1+C1
<0406> A2BB 0F,77           XML  VPUSH          (B)    FAC = T1
<0407> A2BD 31,00,08        MOVE 8,G@RNDEM,@ARG        ARG = 1/1E7
       A2C0 5C,A3,77
<0408> A2C3 0F,08           XML  FMUL                  FAC = T1/1E7
<0409> A2C5 06,00,22        CALL GRINT              T2=FAC = INT(T1/1E7)
<0410> A2C8 0F,77           XML  VPUSH          (C)    FAC = T2
<0411> A2CA 31,00,08        MOVE 8,G@RNDEP,@ARG        ARG = 1E7
       A2CD 5C,A3,6F
<0412> A2D0 0F,08           XML  FMUL                  FAC = T2*1E7
<0413> A2D2 A7,6E,00        DSUB 8,@VSPTR
       A2D5 08
<0414> A2D6 0F,0C           XML  SSUB           (D) X1=FAC = T1-T2*1E7
<0415> A2D8 35,00,05        MOVE 5,@FAC,V@RNDX1        FAC = X1 (new)
       A2DB A3,A5,4A
<0416> A2DE 0F,77           XML  VPUSH          (E)    FAC = X1
<0417>               * COMPUTE NEW VALUE FOR X2, SAVE IT IN V@RNDX2
<0418> A2E0 35,00,05        MOVE 5,V@RNDX2,@FAC        FAC = X2
       A2E3 4A,A3,A0
<0419> A2E6 86,4F           CLR  @FAC5                 FAC = CLR
<0420> A2E8 87,50           DCLR @FAC6                 FAC = CLR
<0421> A2EA 31,00,08        MOVE 8,G@RNDA1,@ARG        ARG = A1
       A2ED 5C,A3,57
<0422> A2F0 0F,08           XML  FMUL                  FAC = X2*A1
<0423> A2F2 A3,6E,00        DADD 8,@VSPTR
       A2F5 08
<0424> A2F6 0F,77           XML  VPUSH          (F)    FAC = X2*A1
<0425> A2F8 A7,6E,00        DSUB 24,@VSPTR
       A2FB 18
<0426> A2FC 0F,78           XML  VPOP           (G)    FAC = X1
<0427> A2FE A3,6E,00        DADD 32,@VSPTR
       A301 20
<0428> A302 31,00,08        MOVE 8,G@RNDA2,@ARG        ARG = A2
       A305 5C,A3,4F
<0429> A308 0F,08           XML  FMUL                  FAC = X1*A2
<0430> A30A 0F,0B           XML  SADD           (H)    FAC = X2*A1+X1*A2
<0431> A30C 31,00,08        MOVE 8,G@RNDC2,@ARG        ARG = C2
       A30F 5C,A3,5F
<0432> A312 0F,06           XML  FADD                  FAC = X2*A1+X1*A2
<0433> A314 0F,0B           XML  SADD           (J) T3=FAC = X2*A1+X1*A2
<0434> A316 A7,6E,00        DSUB 16,@VSPTR
       A319 10
<0435> A31A 0F,77           XML  VPUSH          (K)    FAC = T3

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0017 
EQUATES EXEC-359
<0436> A31C 31,00,08        MOVE 8,G@RNDEM,@ARG        ARG = 1/1E7
       A31F 5C,A3,77
<0437> A322 0F,08           XML  FMUL                  FAC = T3/1E7
<0438> A324 06,00,22        CALL GRINT              T4=FAC = INT(T3/1E7)
<0439> A327 31,00,08        MOVE 8,G@RNDEP,@ARG        ARG = 1E7
       A32A 5C,A3,6F
<0440> A32D 0F,08           XML  FMUL                  FAC = T4*1E7
<0441> A32F 0F,0C           XML  SSUB           (L) X2=FAC = T3-T4*1E7
<0442> A331 35,00,05        MOVE 5,@FAC,V@RNDX2        FAC = X2 (new)
       A334 A3,A0,4A
<0443>               * COMPUTE NEW VALUE FOR RND, LEAVE IT IN FAC
<0444> A337 31,00,08        MOVE 8,G@RNDEM,@ARG        ARG = 1/1E7
       A33A 5C,A3,77
<0445> A33D 0F,08           XML  FMUL                  FAC = X2/1E7
<0446> A33F 0F,77           XML  VPUSH          (M)    FAC = X2/1E7
<0447> A341 A3,6E,00        DADD 8,@VSPTR
       A344 08
<0448> A345 0F,78           XML  VPOP           (N)    FAC = X1
<0449> A347 0F,08           XML  FMUL                  FAC = X1/1E7
<0450> A349 0F,08           XML  FMUL                  FAC = X1/1E14
<0451> A34B 0F,0B           XML  SADD           (P)RND=FAC = (X2/1E7)+(X1/1E14)
<0452> A34D 0F,75           XML  CONT
<0453>               ***********************************************************
<0454>               * CONSTANTS FOR THE RANDOM NUMBER ROUTINE
<0455> A34F 43,01,2B RNDA2  BYTE >43,>01,>2B,>59,>52,>00,>00,>00 * = 1438982
       A352 59,52,00
       A355 00,00
<0456> A357 42,2A,08 RNDA1  BYTE >42,>2A,>08,>15,>00,>00,>00,>00 * = 0420821
       A35A 15,00,00
       A35D 00,00
<0457> A35F 43,02,0B RNDC2  BYTE >43,>02,>0B,>20,>30,>00,>00,>00 * = 2113248
       A362 20,30,00
       A365 00,00
<0458> A367 43,06,36 RNDC1  BYTE >43,>06,>36,>05,>13,>00,>00,>00 * = 6540519
       A36A 05,13,00
       A36D 00,00
<0459> A36F 43,0A,00 RNDEP  BYTE >43,>0A,>00,>00,>00,>00,>00,>00 * = 1E7
       A372 00,00,00
       A375 00,00
<0460> A377 3C,0A,00 RNDEM  BYTE >3C,>0A,>00,>00,>00,>00,>00,>00 * = 1/1E7
       A37A 00,00,00
       A37D 00,00

Edited September 17, 2014 by RXB

[+Lee Stewart]

What do you mean 4 calls to TI Basic RND? I copied it exactly and it does it each byte to fill up the Floating point buffer so I guess that would be 4 times.

 

I erred in saying GPL RAND was called 4 times—your reference to "it does it each byte" reminded me that RAND is actually called 7 times—worse than I remembered! The first byte (sign and exponent of FP number) is set with a positive sign and 0 exponent, i.e., 3Fh. So, RAND gets called once for each of the remaining 7 bytes of the FP number.

But this is tons faster then the XB RND that does so much Floating point math it is silly.

 

I agree. My point, however, was that it would be so much faster yet with only 1 or 2 calls instead of 7! Again, for screen coordinates, we only need one pseudo-random byte for each dot-column and dot-row.

 

...lee

[RXB]

 

I erred in saying GPL RAND was called 4 times—your reference to "it does it each byte" reminded me that RAND is actually called 7 times—worse than I remembered! The first byte (sign and exponent of FP number) is set with a positive sign and 0 exponent, i.e., 3Fh. So, RAND gets called once for each of the remaining 7 bytes of the FP number.

 

I agree. My point, however, was that it would be so much faster yet with only 1 or 2 calls instead of 7! Again, for screen coordinates, we only need one pseudo-random byte for each dot-column and dot-row.

 

...lee

Good Point Lee!

But if you look at the GPL Code it only does it 7 times as it puts >3F in FAC and starts generation of numbers at >4B as VAR5 is the index pointer.

When VAR5 hits >51 it is done and FAC has the Exponent and 7 byte Random number.

[Willsy]

I just tried the following program and TIB and XB:

 

 

10 N=0
20 A=RND
30 N=N+1
40 IF N<65536 THEN 20

 

And the following equivalent program in fbForth and TurboForth:

 

 

VARIABLE N
VARIABLE A
: TEST
  BEGIN
    0 RND A !   
    1 N +!  
  N @ 0= UNTIL ;

 

Here's the results:

 

 

It's official. XB is *shockingly* slow. OMG!

 

I don't have RXB installed to test it. I must install it and update the results.

[jstimson]

What is "the native TI call"?

 

 

 

 

 

???? PEEKing the VDP interrupt timer which can only ever have 256 different, linearly changing values (only 1 byte changes) does not double for the RND routine, which returns an 8-byte pseudo-random number.

 

The biggest problem with RND in all of the Basics under discussion is that they are composing an 8-byte, floating point number, when only the first 2 bytes would be sufficient for screen position. TI Basic's "fast" RND makes 4 calls to the console GPL ROM's RAND routine to do this. It would be nice to have the option to make just 1 call to the GROM RAND routine.

 

...lee

"the native TI call" would be the console BASIC version. Not that big a stretch to figure out.

 

As for the PEEK to -31880, it returns a value between 0 and 99. It will return the exact same value everytime unless a RANDOMIZE statement is done before it.

 

For most intents and purposes, the PEEK value is more than sufficient, especially if you are concerned about speed of execution, such as in a tight loop.

 

Let's place some hard values on things....

 

For comparison purposes, the following line creates a random number between 1 and 10:

 

100 A=INT(RND*10)+1

 

The call to RANDOMIZE would have been done earlier and is not part of the measurement. The line is also unchanged between BASIC and XB.

 

The equivalent using the PEEK is:

 

100 RANDOMIZE

110 CALL PEEK(-31880,A):: A=INT(A/10)+1

 

As stated previously, the RANDOMIZE when using this method must be called everytime, otherwise you will get the exact same number on each PEEK.

 

If we normalize the timing values against CONSOLE BASIC we get:

 

TI Console BASIC : 1.0

TI XB BASIC : 1.92

TI PEEK : 1.21 (which includes the call to RANDOMIZE)

 

As you can see, XB is horrible for speed slowdown. The PEEK is still not as fast as Console BASIC, but is certainly a far better solution if speed is a driving factor in your program.

 

Since I use "real iron" I am unable to use RXB with my given hardware. So until an RXB2014 cartridge comes out (hint! hint!) I probably won't be able to run my benchmarks against it. That being said, as I continue developing and compiling numbers, I will reach a point where I am ready to distribute the whole thing with conclusions, that way somebody with RXB can run them as well. Not sure when that will happen since, as with most of us here, the TI is a hobby that we need to set time aside for from our regular lives.

 

My "dream" cartridge would have all kinds of programs on it such as RXB and XB2.7 with an easy way to flash an update to it as programs evolve. But then I would also like to win the lottery or own a fully functional TI 99/8. Sigh.

[Omega-TI]

I just tried the following program and TIB and XB:

 

 

 

It's official. XB is *shockingly* slow. OMG!

 

 

DAMN! Nothing like like a pie chart to club one over the head with the facts. That just jumps off page a screams at ya!

That teeny tiny little purple sliver speaks volumes.

[senior_falcon]

Rich, since you seem to be unwilling to compare Kaleidoscope running under RXB 2014 and RXB 2012, could you post Kaleidoscope here so that others can make that comparison?

[+Lee Stewart]

"the native TI call" would be the console BASIC version. Not that big a stretch to figure out.

 

I generally ask questions for clarification—not because I'm stupid or lazy. Thanks for the clarification

As for the PEEK to -31880, it returns a value between 0 and 99. It will return the exact same value everytime unless a RANDOMIZE statement is done before it.

 

I thought that RANDOMIZE only changed 83C0h – 83C1h (the random number seed). I didn't realize that it messed with 8378h (-31880). I thought only GPL's RAND (through Basic's RND) did that. Good to know.

 

I was wrong about PEEKing -31880. I forgot that PEEK returns bytes not words. My bad. That said, PEEKing 8379h (-31879) would, in fact, sample the VDP interrupt timer and could be used for an even faster, small, pseudo-random number routine:

 

110 CALL PEEK(-31879,A)::A=A-INT(A/10)*10+1

 

This is only about 10 % faster, however. There must be a faster way to do the "MOD 10" in Basic without the FP multiply and divide; but, it is faster, nonetheless.

 

...lee

[senior_falcon]

 

This is only about 10 % faster, however. There must be a faster way to do the "MOD 10" in Basic without the FP multiply and divide; but, it is faster, nonetheless.

 

I did a few tests last night to see whether an assembly subroutine might offer a speed increase when generating a random number. Something along the lines of: CALL LINK("RAND",U,X) where U is the upper limit on the RND and X is returned as a random number integer from 0 to U. Even with the overhead of the CALL LINK and passing values back and forth it looks as if it would be about twice as fast as the equivalent in XB: X=INT(RND*U). So the speed would be about midway between standard XB and the new RXB

 

BTW, it might be appropriate to start a new thread to discuss random numbers when they are not related to RXB.

Edited September 17, 2014 by senior_falcon

[jstimson]

I generally ask questions for clarification—not because I'm stupid or lazy. Thanks for the clarification

 

 

 

 

 

 

I thought that RANDOMIZE only changed 83C0h – 83C1h (the random number seed). I didn't realize that it messed with 8378h (-31880). I thought only GPL's RAND (through Basic's RND) did that. Good to know.

 

I was wrong about PEEKing -31880. I forgot that PEEK returns bytes not words. My bad. That said, PEEKing 8379h (-31879) would, in fact, sample the VDP interrupt timer and could be used for an even faster, small, pseudo-random number routine:

 

 

110 CALL PEEK(-31879,A)::A=A-INT(A/10)*10+1

This is only about 10 % faster, however. There must be a faster way to do the "MOD 10" in Basic without the FP multiply and divide; but, it is faster, nonetheless.

 

...lee

Ooooh, I like the other location you mentioned (-31879). Given that calls to it, in most programs, would not happen at exact intervals then it would be "random enough" for most purposes. I'll throw that into the mix for my benchmarks.

 

And I second the following post by senior_falcon, moving this discussion to a new post and let the RXB discussion proceed with actual RXB topics.

[Omega-TI]

And I second the following post by senior_falcon, moving this discussion to a new post and let the RXB discussion proceed with actual RXB topics.

 

Great idea! I started one << HERE >>

[+Lee Stewart]

And I second the following post by senior_falcon, moving this discussion to a new post and let the RXB discussion proceed with actual RXB topics.

 

FYI—These discussions already exist on this forum:

• TurboForth Random Number Generator
• Random Number in Assembly

 

...lee

Edited September 17, 2014 by Lee Stewart

[RXB]

 

DAMN! Nothing like like a pie chart to club one over the head with the facts. That just jumps off page a screams at ya!

That teeny tiny little purple sliver speaks volumes.

 

 

DAMN! Nothing like like a pie chart to club one over the head with the facts. That just jumps off page a screams at ya!

That teeny tiny little purple sliver speaks volumes.

Well to be fair how much of Turbo Forth is written in GPL?

Edited September 17, 2014 by RXB

[Willsy]

To answer Rich's question: 0%. Though I think that if you wrote an equivalent of the one of the above test programs in pure GPL it would perform quite well. We shouldn't forget that fbForth and TurboForth are dealing with integers in the program that I posted and TIB/XB are dealing with Radix 100. So it's not really a fair comparison. TurboForth is a little faster than fbForth *on this particular example* but in a real world program the difference wouldn't be that great I suspect.