Byte Magazine Sieve Benchmark

[+RXB]

1 hour ago, Reciprocating Bill said:

Rich - Are your Call Load (when used to poke) and Call Peek operations GPL routines? Seems to me that having fast, assembly equivalents would be very useful. It would then be practical to set up the equivalent of integer arrays larger than are possible with ordinary DIM statements - just as I did with Cortex BASIC. The original Xbasic calls are too slow for that purpose. (Although perhaps that wouldn't be much help vis speed - as anything to be poked or handled after being peeked would have to be floating point...but it would allow more compact data structures when integer values are sufficient.)

LOL no RXB does not use CALL LOAD to increase speed that is TML or XB 2.9 that does that, I wrote new ROMs for XB to make many command in XB (RXB) faster dealing with VDP

For example CALL HCHAR, CALL VCHAR, CALL CLEAR and a version of DISPLAY AT(row,column) in RXB 2022 named CALL HPUT(row,column,variable or string  or string variable) and

CALL VPUT(row,column,variable or string  or string variable)

Also RXB 2022 has Assembly routines CALL ROLLLEFT(repetitons), CALL ROLLRIGHT(repetions), CALL ROLLUP(repetions) and CALL ROLLDOWN(repetitons) all you can do not need (repetions) at all.

Like CALL ROLLRIGHT or CALL ROLLUP see no (repetions) needed.

Additionally RXB 2022 has CALL SCROLL routines that do same thing but adds the same thing as you get in PRINT.

Example: CALL SCROLLUP(8,"This is a test!") would be just like this normal XB program PRINT ::::::::"This is a test!"

Or optionally CALL SCROLLLEFT or optionally CALL SCROLLDOWN(1,"  Put this on screen")

All of these are Assembly routings and no CALL LOAD or CALL LINK to make them work and no 32K needed to work as these work in just a Console with RXB CART or FinalGROM cart.

 

All above are still Floating Point but have you seem my Youtube Demos?

 

 

2021-12-23 15-37-42.mkv 2021-12-31 21-06-05.mkv 2022-01-18 15-40-24.mkv 2022-01-11 15-23-10.mkv

[+TheBF]

A funny thing happened on the way the benchmark... ?

 

I found an alternative coding for the Sieve of ERASTOTHENES in Forth.

It told me there were 1028 prime numbers between 0 and 8192.

The Byte version in Forth says there are 1899.

 

So I checked on this web site:  Prime numbers between 0 and 8192 (factors-of.com)

Guess what?  The correct answer is 1028.

 

I have a dim memory of this problem from the years ago.

 

Now I am curious about the Byte magazine code in the other languages.

I can start with BASIC.

[Reciprocating Bill]

The BYTE Sieve actually looks for primes from 1 to 16384 (2*8192), of which there are 1899. The highest prime it finds is 16381. 

 

Perhaps it needs an array only half that size because all primes are odd numbers.

[+mizapf]

22 minutes ago, Reciprocating Bill said:

Perhaps it needs an array only half that size because all primes are odd numbers.

Except for 2, the only even prime.

[+TheBF]

37 minutes ago, Reciprocating Bill said:

The BYTE Sieve actually looks for primes from 1 to 16384 (2*8192), of which there are 1899. The highest prime it finds is 16381. 

 

Perhaps it needs an array only half that size because all primes are odd numbers.

Ah...  Thanks!

[+TheBF]

On 4/24/2022 at 2:40 PM, lucien2 said:

For this benchmark program, we could also keep the default character set.

That could improve it by a few seconds, but I was expecting something 1.5x slower than Forth (~150-200 seconds).

I believe the difference between your estimate and the actual numbers is because GPL is a "byte-code" interpreter but the Forth examples are address interpreters.

If we made a byte-coded Forth, with that extra layer of indirection, I am betting your estimate would be spot on.

I thought about doing one just to see how much functionality I could stuff into 8K.  

[+TheBF]

I posted a results table on the first Post of this topic along with some historical results from a paper from 1989 that complained about the Forth version.

?

[senior_falcon]

On 4/25/2022 at 1:05 AM, RXB said:

I wrote new ROMs for XB to make many command in XB (RXB) faster dealing with VDP. For example CALL HCHAR, CALL VCHAR, CALL CLEAR and a version of DISPLAY AT(row,column) in RXB 2022 named CALL HPUT(row,column,variable or string  or string variable) and

 

This sounds like you have rewritten CALL CLEAR in assembly. In normal XB, CALL CLEAR uses GPL ALL which uses assembly to put an >80 on the screen 768 times. The loop is pretty standard:

gpl all                                                                   rxb call clear

LOOP MOVB R5,@>FFFE(R15)   r15=8c02               LOOP MOVB R1,*R8    r8=8c00

        DEC R7                                                                DEC R3

        JNE LOOP                                                             JNE LOOP

Turns out this is not a performance enhancer for RXB. The reason is that the GPL interpreter is on the 16 bit bus, while the RXB routine is on the 8 bit bus.

 

(edit) I should add that, since you never do more than one CALL CLEAR at a time, either way is plenty fast enough. Maybe it has to be this way to enable the new routine that clears just the 28 center columns.

Edited April 26, 2022 by senior_falcon

[+RXB]

Ok run this program in TI Basic, XB, RXB 2020, XB3, Super XB, XB 2.9 and RXB 2022.

 

100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 CALL CLEAR
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

I am doing that now to get results!

 

[+RXB]

Results are:

TI Basic 13 Minute 44 seconds

XB  13 Minute 9 seconds

XB 2.9 13 Minute 9 seconds

RXB 2022A 13 Minute 8 seconds

 

Yes a very very small increase in speed but then RXB 2022A has CALL CLEARPRINT that clears the 28 columns only PRINT or DISPLAY use.

 

Now the RXB 2022A rest like CALL HCHAR, CALL VCHAR are way faster then the others. 

Plus CALL HPUT or CALL VPUT are faster versions of DISPLAY AT(row,col) that use all the ROW and COLUMNS also in Assembly unlike XB does.

Now added CALL ROLL up down left right or CALL SCROLL up down left right added with options of acting like PRINT in any directions.

[senior_falcon]

For CALL CLEAR, you must have reverted to GPL ALL for RXB 2022A. Nope, still runs in cartridge rom in RXB 2022A.

 

"Now the RXB 2022A rest like CALL HCHAR, CALL VCHAR are way faster then the others."

 

You would not see a noticeable difference comparing RXB with XB 2.9 G.E.M. when performing HCHAR and VCHAR.

Edited April 27, 2022 by senior_falcon

[GDMike]

Doesn't switching from 32 column to 40 then back to 32 column Also Clear the screen as a part of the process, or merely calling 32 column mode do a clear screen? Just wondering..

[senior_falcon]

22 minutes ago, GDMike said:

Doesn't switching from 32 column to 40 then back to 32 column Also Clear the screen as a part of the process, or merely calling 32 column mode do a clear screen? Just wondering..

Is this T40XB? If so, then the first time you CALL LINK("T40") will clear the screen and load the character set. After that switching between G32 and T40 changes the graphics modes but does not clear the screen.

[HOME AUTOMATION]

2 hours ago, GDMike said:

Doesn't switching from 32 column to 40 then back to 32 column Also Clear the screen as a part of the process, or merely calling 32 column mode do a clear screen? Just wondering..

Yes, it does not. I demonstrated this in another thread.

 

Third pic. down, I switch EASYBUG to TEXTMODE by changing >80D4 to >F0. The debugger's text becomes misaligned, but nothing is lost.

Switching from TEXTMODE to GRAPHICSMODE, would make part of the screen unviewable, but again, nothing cleared.

[senior_falcon]

4 hours ago, RXB said:

Results are:

TI Basic 13 Minute 44 seconds

XB  13 Minute 9 seconds

XB 2.9 13 Minute 9 seconds

RXB 2022A 13 Minute 8 seconds

From my video in post #33 above you can see that XB is about twice as fast as RXB doing a CALL CLEAR. So with just one look at these results you know they are bogus.

The results I get running the program in post #34 are:

TI Basic           8:40

XB                  5:31

RXB 2022A      9:33

[Asmusr]

These are my results using Classic99 QI399.057:

 

TI BASIC: 10:24

XB: 3:43

RXB 2022A: 8:39

 

 

[HOME AUTOMATION]

And the winner is: XP

[+RXB]

48 minutes ago, Asmusr said:

These are my results using Classic99 QI399.057:

 

TI BASIC: 10:24

XB: 3:43

RXB 2022A: 8:39

 

 

Are you using this those times the entire thing?

100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 CALL CLEAR
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

I fail to see how you get these results as you are saying RXB Assembly for CALL CLEAR is slower then GPL in XB?

I ran this test multiple times with same results:

TI Basic 13 Minute 44 seconds

XB  13 Minute 9 seconds

XB 2.9 13 Minute 9 seconds

RXB 2022A 13 Minute 8 seconds

 

I will change the loop to 100000 instead of 10000 to see a bigger difference.

 

[+RXB]

OK RAN A 100000 LOOP TEST SO RESULTS ARE:

XB       = 37 Minutes 5 Seconds

XB 2.9 = 37 Minutes 6 Seconds

RXB     = 26 Minutes 2 Seconds

 

100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 100000
140 CALL CLEAR
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

Run this program you will get same results!

As I use the same program to time everything you can discount the FOR NEXT loop as they are all the same speed.

Prove it by taking out line 140 and run it in any XB!

[Reciprocating Bill]

Running:

 

10 FOR I = 1 TO 1000          (I don't see any reason to wait around for 30+ minutes to get the basic ratios).

20 CALL CLEAR

30 NEXT I

 

...on real iron* running out of a FinalGrom, I get:

 

TI-BASIC 60 seconds

Extended Basic 23 seconds

RXB 2020  23 seconds

RXB 2022  52 seconds

 

*Console with RAM on 16-bit bus, which doesn't have significant impact on the speed of these BASICs.

 

(Just to check the assumption that FinalGrom has no impact on these numbers, I ran the code on an Extended Basic cartridge. No difference.) 

[senior_falcon]

Rasmus                      Senior_Falcon  (both used Classic99 QI399.057)

TI BASIC: 10:24          TI Basic           8:40

XB: 3:43                     XB                  5:31

RXB 2022A: 8:39         RXB 2022A      9:33

 

These agree (sort of). They are enough different that it makes me wonder about the validity of using this method for timing programs.

In the past, I don't remember discrepancies like this. It seems unlikely, but perhaps there is something in the latest Classic99 that is causing it?

(For what it's worth, my geriatric Dell Optiplex 780 was rescued from the trash and is running Classic99 in linux from a virtual box.)

 

 

I fail to see how you get these results as you are saying RXB Assembly for CALL CLEAR is slower then GPL in XB?

This is not complex. The code used by the loops is in my post #33.

RXB runs from the cartridge rom on the 8 bit bus; GPL runs from console rom on the 16 bit bus, which of course is faster.

For once GPL has a speed advantage!

 

 

I ran this test multiple times with same results: (looping 10000 times)

TI Basic 13 Minute 44 seconds

XB  13 Minute 9 seconds

XB 2.9 13 Minute 9 seconds

RXB 2022A 13 Minute 8 seconds

I will change the loop to 100000 instead of 10000 to see a bigger difference.

---------------------------------------------------------------------------------------

OK RAN A 100000 LOOP TEST SO RESULTS ARE:

XB       = 37 Minutes 5 Seconds

XB 2.9 = 37 Minutes 6 Seconds

RXB     = 26 Minutes 2 Seconds

 

 

In the second test, it only takes twice as long for RXB to do 10 times the number of loops. From this, what can you infer about the validity of your tests?

Edited April 27, 2022 by senior_falcon

[HOME AUTOMATION]

I'm no math wiz, but...

 

XB@10,000 iterations

13min. 9sec...

 

100/60=1.6666667

1.6666667*9=15

13.15*10=131.5

.5/1.6666667=.3

 

XB@10,0000 iterations x10

131min. 1/3rd. sec.

 

XB@10,000x10 vs. XB@100,000

131-37=94min.

 

So, 94min. relative difference between 10,000 and 100,000 loops.

If the tests were identical, there would be no difference at all.

 

I'm thinking the leading 1, was dropped somewhere along the line ...(1)37min. 5sec..

[senior_falcon]

2 hours ago, Reciprocating Bill said:

Running:

10 FOR I = 1 TO 1000          (I don't see any reason to wait around for 30+ minutes to get the basic ratios).

20 CALL CLEAR

30 NEXT I

...on real iron* running out of a FinalGrom, I get:

TI-BASIC 60 seconds

Extended Basic 23 seconds

RXB 2022  52 seconds

Multiply x10 and you get:

Basic     10:00        rasmus got 10:24

XB          3:50        rasmus got 3:43

RXB        8:40        rasmus got 8:39

So Rasmus got times that were the virtually the same as real iron.

There must be something about my system that causes the clock to be off. As noted above, it is a relic from a bygone era.

 

 

[Asmusr]

2 hours ago, senior_falcon said:

These agree (sort of). They are enough different that it makes me wonder about the validity of using this method for timing programs.

In the past, I don't remember discrepancies like this. It seems unlikely, but perhaps there is something in the latest Classic99 that is causing it?

Timing using a stop watch instead of Classic99 CLOCK gives me the exact same results. But maybe if the computer is not fast enough to run Classic99 at full speed you would get longer times? I also tried using JS99er, which is not so accurate as Classic99, but the results match pretty well.

[senior_falcon]

22 minutes ago, Asmusr said:

Timing using a stop watch instead of Classic99 CLOCK gives me the exact same results. But maybe if the computer is not fast enough to run Classic99 at full speed you would get longer times? I also tried using JS99er, which is not so accurate as Classic99, but the results match pretty well.

The funny thing is that the XB times are a little longer but the BASIC time is shorter.

I will try going back to an earlier Classic99 to see what happens.

Maybe it is time to upgrade my computer!