Byte Magazine Sieve Benchmark

[apersson850]

On 5/16/2023 at 1:45 AM, TheBF said:

Variables, branching and code to enter a routine exist separate from the NEXT interpreter. So that's where Forth spends extra time that is not seen if we just look at Forth's NEXT code. 

It's pretty similar to the p-code interpreter I've shown pieces of before. It executes 5-6 instructions to find out two things: What to do to interpret the instruction and if there are any parameters to it, and if there is, how to handle them.

Then it actually interprets the p-code (if there are no parameters) or fetches the parameter(s) and after that executes the interpretation.

 

The p-code interpreter does this:

• Fetch p-code.
• Increment address (runs only if code is in auto-incrementing memory, since then you can't just auto-increment the pointer).
• Shift left to make byte-code a word-index.
• Fetch address to interpreter's code for the instruction from interpreter's instruction table.
• Fetch branch address for parameters for instruction. If there are no parameters, this one just points to the instruction's interpretation code, which normally is the next word.

 

So yes, these byte code interpreters do handle things that are "hidden" when you look at Forth's inner interpreter. The p-code interpreter is probably the most complex of them all, since it can run p-code from VDP RAM, GROM and CPU RAM. The first two are auto-incrementing with the same reading address, the third is not. The first two load the address in different ways, the third is just a normal memory access. Forth and GPL at least runs from the same type of memory all the time.

 

[+chue]

This is the benchmark for "Jason's hacky version of Myarc XB2 on SAMS", version 2.12. 

At least that's what @JasonACT calls it: https://forums.atariage.com/topic/252171-1-meg-super-ams-discussion-thread/?do=findComment&comment=5419075

The code is close to the BYTE magazine version.  I added code to query the clock device.  "CLOCK" is available in Classic99, or the Pico PEB sidecar device.  On the TIPI, the device might be "PI.CLOCK". 

 

1 OPEN #1: "CLOCK" 
2 INPUT #1: A$,B$,C$
3 PRINT C$
5 DEFINT M,COUNT,I,K,ITER,SZ
6 ITER=1 
7 SZ=8192 
8 REM NEXTLINE USE SZ+1  
10 DEFINT DIM FLAGS(8193)
20 PRINT ITER;"ITERATIONS" 
30 FOR M=1 TO ITER
40 COUNT=0 
50 FOR I=0 TO SZ
60 FLAGS(I)=1 
70 NEXT I
80 FOR I=0 TO SZ
90 IF FLAGS(I)=0 THEN 170
100 PRIME=I+I+3 
105 REM PRINT PRIME 
110 K=I+PRIME
120 IF K>SZ THEN 160
130 FLAGS(K)=0 
140 K=K+PRIME
150 GOTO 120
160 COUNT=COUNT+1 
170 NEXT I
180 NEXT M
190 PRINT COUNT;"PRIMES" 
200 INPUT #1: A$,B$,C$
210 PRINT C$

 

 

The result for one iteration - 22 minutes 1 second

 

I have also been trying to get the non-hacky Myarc Foundation version of XB2 to run, but without a lot of success.

[JasonACT]

3 hours ago, chue said:

I have also been trying to get the non-hacky Myarc Foundation version of XB2 to run, but without a lot of success.

You have to have the Myarc DSR ROM on the SD card, load an 8KB ROM cart (the memory tester for example) and have the XB2 disk in DSK1 then CALL CARTMMO and CALL MYARCON and reboot.  The DSR will install the boot-loader into the cart RAM and give you option 2 on the selection screen - which will load the rest of the files from DSK1 into the cart & Myarc expansion RAM.

 

EDIT: I get a "MEMORY FULL IN 10" error - 4096/4097 runs though.

Edited May 3 by JasonACT

[JasonACT]

OK - Line 10 was saved from a different XB (my CALL PASTE("...") function doesn't work properly with XB2) and it hadn't coded "DEFINT" properly - but re-editing the line in XB2 has encoded it properly now and 8193 does actually work.  I had typed line 5 in XB2 already because the XB I had used threw an error on that one, but not line 10.

12 minutes and 16 seconds.

[+chue]

On 5/3/2024 at 1:17 AM, JasonACT said:

You have to have the Myarc DSR ROM on the SD card, load an 8KB ROM cart (the memory tester for example) and have the XB2 disk in DSK1 then CALL CARTMMO and CALL MYARCON and reboot.  The DSR will install the boot-loader into the cart RAM and give you option 2 on the selection screen - which will load the rest of the files from DSK1 into the cart & Myarc expansion RAM.

I used the following files:

 

Myarc DSR - https://forums.atariage.com/topic/308510-research-on-myarc-extended-basic-ii/?do=findComment&comment=5418927

XB2 Disk - https://forums.atariage.com/topic/307501-myarc-extended-basic-ii-mame-setup/

 

I could not get it working, it never shows option 2 from the selection screen.  I probably don't have the right filename for the Myarc DSR though.  Is it even the correct file?

 

 

[JasonACT]

7 hours ago, chue said:

I could not get it working, it never shows option 2 from the selection screen.  I probably don't have the right filename for the Myarc DSR though.  Is it even the correct file?

Nah, I don't think so, you need the Foundation version that's in this post:

 

On 2/12/2024 at 7:52 PM, JasonACT said:

Attached is a new firmware for testing, along with the Foundation 128/512KB XBII ROM that can be optionally copied to your SD card.  CALL CARTMMO in TI BASIC (turns on Mini Memory RAM mode, but in this special case, the whole 8KB is now RAM) will switch the SAMS 1MB to a Foundation (/Myarc) 512KB at CRU >1E00...  Without the ROM, you can load whatever cartridge image [with a single ROM] you like, like the memory tester.  With the ROM, it will wipe out the loaded cartridge image and install the M-XBII booter.  If you have Mini Memory loaded, Easy Bug seems to also still work, since that part is in GROM and I don't wipe it, but best not to use a GROM cartridge image for this.  Without a cartridge image loaded, it won't do much.

 

The M-XBII booter requires a DSK image or directory set up with the appropriate files, before selecting the menu option.  NOTE: the images available have a LOAD file on them, which takes a minute to load and run, just wait until the demo starts.  I initially thought there was a problem, until I left it to run.

 

This firmware runs at 258MHz Pico speed.  If PSRAM chips have an issue at this speed, I can make a 256MHz version, I suppose.

PPEB2.ino.uf2.zip 384.18 kB · 7 downloads

 

[+chue]

1 hour ago, JasonACT said:

you need the Foundation version that's in this post

That's what I was missing, thank you!

[+chue]

TI BASIC + Minimem + 32K

 

I thought it would be interesting to see TI BASIC compared to the other BASICs.  I realize there is another (stock) TI BASIC benchmark earlier in this thread, but that one doesn't find all of the primes.

 

Instead of using an array for working storage, this code uses the Minimem to Peek / Poke into expansion RAM.

 

1 OPEN #1:"CLOCK"
2 INPUT #1:A$,B$,C$
3 PRINT C$
6 ITER=1
8 HIMEM=-24576
9 SZ=8192
20 PRINT ITER;"ITERATIONS"
30 FOR M=1 TO ITER
40 COUNT=0
50 FOR I=0 TO SZ
60 CALL LOAD(HIMEM+I,1)
70 NEXT I
80 FOR I=0 TO SZ
90 CALL PEEK(HIMEM+I,FLAG)
95 IF FLAG=0 THEN 170
100 PRIME=I+I+3
105 REM  PRINT PRIME  
110 K=I+PRIME
120 IF K>SZ THEN 160
130 CALL LOAD(HIMEM+K,0)
140 K=K+PRIME
150 GOTO 120
160 COUNT=COUNT+1
170 NEXT I
180 NEXT M
190 PRINT COUNT;"PRIMES"
200 INPUT #1:A$,B$,C$
210 PRINT C$

 

 

Result for 1 iteration is 25 minutes and 2 seconds.

[+TheBF]

Thanks @chue 

 

I added this TI-BASIC result to the list in the first entry of the thread.

I wonder if this could be compiled ???

 

[GDMike]

It's not finished, add a.m. or p.m.

I think it was Lee that actually threw that code at me one day..

Edited May 5 by GDMike

[+chue]

On 5/5/2024 at 2:57 PM, TheBF said:

I wonder if this could be compiled ???

I gave it a try but the compile process gives an error. I need to do some research on my end. If I can’t figure it out I will call in the experts. 

 

Edit: add error screenshot

 

[Gary from OPA]

8 minutes ago, chue said:

I gave it a try but the compile process gives an error. I need to do some research on my end. If I can’t figure it out I will call in the experts. 

The problem with compiling this code is that it uses the 32k expansion ram as storage for the array of prime numbers. You need to reserve that area so that it doesn't interfere with the compiled code. Looks like it needs 8k of storage.

[+TheBF]

I had an idea! 

Use the E/A Supercart.  I renamed HIMEM to FLAGS.

The memory location of the array is simple to fix. Remove the minus sign and that equals HEX 6000. 

That's exactly where Supercart RAM lives.

There is exactly enough memory for SZ=8192. 

 

I tried it for SZ=100  and seems to work. 

@chue  Maybe this version will compile now. 

 

1 OPEN #1:"CLOCK"
2 INPUT #1:A$,B$,C$
3 PRINT C$
6 ITER=1
7 rem NEEDS E/A Supercart RAM
8 FLAGS=24576
9 SZ=8192
20 PRINT ITER;"ITERATIONS"
30 FOR M=1 TO ITER
40 COUNT=0
50 FOR I=0 TO SZ
60 CALL LOAD(FLAGS+I,1)
70 NEXT I
80 FOR I=0 TO SZ
90 CALL PEEK(FLAGS+I,FLAG)
95 IF FLAG=0 THEN 170
100 PRIME=I+I+3
105 REM  PRINT PRIME
110 K=I+PRIME
120 IF K>SZ THEN 160
130 CALL LOAD(FLAGS+K,0)
140 K=K+PRIME
150 GOTO 120
160 COUNT=COUNT+1
170 NEXT I
180 NEXT M
190 PRINT COUNT;"PRIMES"
200 INPUT #1:A$,B$,C$
210 PRINT C$

 

[+chue]

1 hour ago, TheBF said:

Use the E/A Supercart.  I renamed HIMEM to FLAGS.

I don't have a Supercart, but if anyone knows how to run one... here's the resulting compiled binary.  My error had nothing to do with the location of the flags.  One of the options is to assemble with win99asm - if I choose this, then I get the error.  I chose the other option, which I believe is to assemble with E/A.

 

The resulting binary is smaller than 8k, so I think I can just move the flags from A000 to B000.  Will try that when I get a little time.

BSMM-E

[+TheBF]

Classic99 Editor Assembler is a "supercart" by default.

 

[+chue]

Well there you go.  1 iteration with Harry Wilhelm's compiled BASIC (version "JUWEL6"): 34 seconds

 

An amazing speedup!

[+TheBF]

Very cool. Thanks.

Should I enter 340 seconds or do you want to run 10 iterations with "1899 primes" printed after each iteration.

[+chue]

10 iterations is more consistent, however I did two versions.

- number of primes printed once (5 min 43 sec)

- number of primes printed after each iteration (5 min 44 sec)

 

I believe the first is how BYTE magazine does it, but the difference here is negligible.

 

[senior_falcon]

Looks like you figured it out already, but for what it's worth, there are a couple of places where ram may be available in a compiled program:

VDP ram starting at around v0A00 and up should be safe. You'd use PEEKV and POKEV to access this

Even better would be using CPU ram starting at >A000 and going up to >F000 or higher. So that's over 20K available, and probably more like 22K or more.

To compile you'd choose the option to put runtime in low memory. Then only the compiled part of the program would be in high memory.

With the compiled program in the XB loader you can type SIZE and find out how many bytes are available, although I think XB starts at >A040.

N.B. This assumes no string variables.

(edit) I should add that this same area of memory is available to an XB program, so you shouldn't have to make any changes.

 

Edited May 8 by senior_falcon