Jump to content
IGNORED

Benchmarking Languages


Tursi

Recommended Posts

40 minutes ago, Willsy said:

Oh! Nice - I already have an inliner somewhere I think... Let me see if I can find it - not eveything got transferred from my old Windows box to my Linux box...

 

Yep! Found it - file creation date is 19th May 2015 - Oh boy! Time flies...

 


variable ilExit

: asmHeader ( "name" -- )
  \ creates a dictionary header for a primitive
  header        \ create dictionary entry
  here 2+ ,     \ lay down cfa (points 2 bytes ahead)
;

: appendCode ( cfa -- )
  @        \ addr
  begin 
    dup @ $045C ( NEXT opcode) <> while
      dup @ , 2+
  repeat
  drop
;

: ;inLine ( -- ) ;

: inLine: ( -- )
  asmHeader  ilExit 0!
  begin
    bl word find if
      dup ['] ;inLine <> if appendCode else true ilExit ! then
    else
      true abort" Unknown word in definition"
    then
  >in @ span @ >= ilExit @ or until
  drop 
  $045C ,  \ append NEXT op-code
;

inLine: dup+drop dup + drop ;inLine

: test 0 0 do dup+drop loop ; \ 11.5 seconds
: test 0 0 do dup + drop loop ; \ 15 seconds

~23% speed improvement

The filename is called 'primitives inliner.txt' so I guess I was thinking that 'primitives' (i.e. intrinsic TF machine code words) could be chained end-to-end to reduce inner interpreter machinations. It really needs updating to ensure that the words selected for in-lining are indeed primitives.

This look pretty familiar.  You are creating new code words by stealing code from the kernel.  I started here as well and then kept trying other stuff. 

 

I now compile the code into heap memory as a headless code fragment and then compile that address into a colon definition. This save the header/name bytes.

: MIXEDCODE   INLINE[ FFFF ] BEGIN  INLINE[ DUP 1- ]  WHILE  INLINE[  DUP 2* ]  .  REPEAT ; 

 

My big "idea" was to compile constants, variables and user vars as literal numbers using the LI instruction.  

That made a big difference in the speedup.

 

I have a preliminary version (buggy) that compiles the looping words as machine code but it needs more work.

That is the real holdup once you remove NEXT from the primitives.

After that you loose speed from unneeded pops/pushes at word intersections.

It never ends... :) 

 

 

 

  • Like 1
Link to comment
Share on other sites

21 hours ago, Reciprocating Bill said:

"Size" in the BYTE Sieve is 8192. That yields 1899 primes. 

Yes, the ZX-81 did not have enough memory for an 8K array under the Partial Pascal environment, so I used a 2K array instead and then multiplied the resulting processing time by 4 for comparison with the benchmark table in the Byte article. So for the Forth translation, you need to use an 8K array so your timing is comparable to the Byte results, otherwise multiply by 4.

 

Calculation time was 450 seconds for the 2K array, equivalent to 1800 seconds for 8K. In looking at the benchmark results table provided in the article, Partial Pascal beats all the interpreted Basics of the time although Microsoft MBasic for Z80 comes very close, but comes in dead last by a significant margin compared to the compiled languages. 

 

  • Like 3
Link to comment
Share on other sites

13 hours ago, Vorticon said:

Yes, the ZX-81 did not have enough memory for an 8K array under the Partial Pascal environment, so I used a 2K array instead and then multiplied the resulting processing time by 4 for comparison with the benchmark table in the Byte article. So for the Forth translation, you need to use an 8K array so your timing is comparable to the Byte results, otherwise multiply by 4.

 

Calculation time was 450 seconds for the 2K array, equivalent to 1800 seconds for 8K. In looking at the benchmark results table provided in the article, Partial Pascal beats all the interpreted Basics of the time although Microsoft MBasic for Z80 comes very close, but comes in dead last by a significant margin compared to the compiled languages. 

 

 

Just curious. I only remember ZX-81 from advertising back in the 20th century.

 

With Partial Pascal does the entire dev. environment exist in memory while the program runs? (I am thinking so since it seems to be cassette based) 

I read that the machine could have as much as 56K useable RAM. 

How much ram did your system have?

 

It makes me wonder if it compiles to some kind of virtual machine code since the CPU was clocked at 3.5Mhz. 

Other Z80 benchmarks I have seen seem pretty quick.

 

  • Like 1
Link to comment
Share on other sites

11 hours ago, TheBF said:

 

Just curious. I only remember ZX-81 from advertising back in the 20th century.

 

With Partial Pascal does the entire dev. environment exist in memory while the program runs? (I am thinking so since it seems to be cassette based) 

I read that the machine could have as much as 56K useable RAM. 

How much ram did your system have?

 

It makes me wonder if it compiles to some kind of virtual machine code since the CPU was clocked at 3.5Mhz. 

Other Z80 benchmarks I have seen seem pretty quick.

 

Yes, Partial Pascal resides in memory, and the editor, compiler and loader all have to be loaded separately every time you need one of them. For this test I used the standard 16K RAM pack, but yes, with the appropriate extension device, you could go as high as 56K. However, most programs did not take advantage of anything beyond 16K for compatibility reasons, and Partial Pascal was no exception.

I believe it did compile to an intermediate "pcode".

Here's a video I recently made about using Partial Pascal on the ZX-81: 

 

  • Thanks 1
Link to comment
Share on other sites

18 hours ago, Vorticon said:

However, most programs did not take advantage of anything beyond 16K for compatibility reasons, and Partial Pascal was no exception.

I like it better when the program/system determines how much memory is available, and then use that. It does of course imply that some program have to have a larger memory to run, or they do run with smaller memories, but can't handle the same amount of data, or that they run with the same functionality but are slower with less memory.

But rather that than having more memory is of no benefit at all, as it's never used.

Link to comment
Share on other sites

18 hours ago, Vorticon said:

Yes, Partial Pascal resides in memory, and the editor, compiler and loader all have to be loaded separately every time you need one of them. For this test I used the standard 16K RAM pack, but yes, with the appropriate extension device, you could go as high as 56K. However, most programs did not take advantage of anything beyond 16K for compatibility reasons, and Partial Pascal was no exception.

I believe it did compile to an intermediate "pcode".

Here's a video I recently made about using Partial Pascal on the ZX-81: 

 

He said "Zed"X81. I love you forever!! :lolblue:

  • Like 3
Link to comment
Share on other sites

  • 1 month later...

 

Allan Mcleod posted a simple visualization of bubble sort in ZX-81 Basic on the ZX-81 Owners Club Facebook page and it was excruciatingly slow. So I thought it would be fun to create a version for the TI. Here's a video of it running in UCSD Pascal which takes 23 seconds to complete:

 

 

Spoiler

PROGRAM BUBBLE;
USES SUPPORT,RANDOM;

VAR
  D: ARRAY [0..31] OF INTEGER;
  L,N,T: INTEGER;
  
PROCEDURE SETUP;

VAR
  I: INTEGER;
  
BEGIN
  FOR I:=0 TO 31 DO
    BEGIN
      D[I]:=RND_INT(24)-1;
      GOTOXY(I,D[I]);
      WRITE('*')
    END;
END;


PROCEDURE UPDATE(I: INTEGER);

BEGIN
  T:=D[I];
  GOTOXY(I,D[I]);
  WRITE(' ');
  D[I]:=D[I-1];
  GOTOXY(I-1,D[I-1]);
  WRITE(' ');
  D[I-1]:=T;
  GOTOXY(I,D[I]);
  WRITE('*');
  GOTOXY(I-1,D[I-1]);
  WRITE('*')
END;

PROCEDURE COMPARE;

VAR
  I: INTEGER;
  
BEGIN
  N:=L;
  REPEAT
    T:=0;
    FOR I:=1 TO N DO
      IF D[I]<D[I-1] THEN
        UPDATE(I);
    N:=N-1
  UNTIL T=0
END;

BEGIN
  PAGE(OUTPUT);
  RANDOMIZE;
  SET_SCREEN(2);
  L:=31;
  SETUP;
  COMPARE;
  READLN
END.
  

 

 

I also tried it in TI BASIC and XB with 56 seconds and 36 seconds respectively.

Spoiler

10 CALL CLEAR
20 RANDOMIZE
30 OPTION BASE 1
40 L=32
50 DIM D(32)
60 GOSUB 100
70 GOSUB 300
90 GOTO 90
100 FOR I=1 TO L
110 D(I)=INT(RND*24)+1
115 CALL HCHAR(D(I),I,42)
120 NEXT I
130 RETURN
300 N=L
310 T=0
320 FOR I=2 TO N
330 IF D(I)<D(I-1)THEN 335 ELSE 340
335 GOSUB 400
340 NEXT I
350 N=N-1
360 IF T>0 THEN 310
370 RETURN
400 T=D(I)
410 CALL HCHAR(D(I),I,32)
420 D(I)=D(I-1)
430 CALL HCHAR(D(I-1),I-1,32)
440 D(I-1)=T
450 CALL HCHAR(D(I),I,42)
460 CALL HCHAR(D(I-1),I-1,42)
470 RETURN

 

 

Just a little diversion :)

 

  • Like 2
Link to comment
Share on other sites

In trying get combsort to work I found a superfluous ELSE clause in the sorter.

Here is the smaller version.

rem bubble sort
300 N=L
310 T=0
320 FOR I=2 TO N
330 IF D(I)>D(I-1)THEN 340
335 GOSUB 400
340 NEXT I

In TI BASIC where IF THEN jumps to lines it's more like Assembly Language and ELSE can usually be eliminated by changing logic comparisons and jumping differently.

Combsort is proving harder for me to get working. Been distracted all morning by phone calls.

  • Like 1
Link to comment
Share on other sites

9 hours ago, Vorticon said:

Here's a video of it running in UCSD Pascal which takes 23 seconds to complete:

In line with discussions in another thread, you could turn off range checking, now when you know it works. Just to see the difference.

 

Why did you use graphics mode? Just to make it appear the same as in BASIC?

Link to comment
Share on other sites

1 minute ago, apersson850 said:

In line with discussions in another thread, you could turn off range checking, now when you know it works. Just to see the difference.

 

Why did you use graphics mode? Just to make it appear the same as in BASIC?

Yes although I could have kept it in text mode and just used 32 columns instead of 40 to keep things similar. This is the first time I had used graphics mode in Pascal, so why not :) 

  • Like 1
Link to comment
Share on other sites

7 hours ago, TheBF said:

In trying get combsort to work I found a superfluous ELSE clause in the sorter.

Here is the smaller version.


rem bubble sort
300 N=L
310 T=0
320 FOR I=2 TO N
330 IF D(I)>D(I-1)THEN 340
335 GOSUB 400
340 NEXT I

In TI BASIC where IF THEN jumps to lines it's more like Assembly Language and ELSE can usually be eliminated by changing logic comparisons and jumping differently.

Combsort is proving harder for me to get working. Been distracted all morning by phone calls.

Ah yes. Thanks for pointing that out. 

Link to comment
Share on other sites

  • 2 weeks later...

I have been away for a few days so I thought I would see what happens translating this to Forth.

I used the same sections as the original versions but added some language extensions to help me navigate writing in a more conventional language style.  

I still doesn't have the beauty of PASCAL.  :) 

However it moves pretty quickly.

 

Edit: Fixed the sort order.  Changed comparison to use CELL+ rather than computing array address twice. 

 

Spoiler

\ BUBBLESTARS.FTH  adapted from TI-BASIC   for Camel99 Forth

\ INCLUDE DSK1.TOOLS
INCLUDE DSK1.RANDOM
INCLUDE DSK1.ARRAYS
INCLUDE DSK1.GRAFIX
INCLUDE DSK1.VALUES

DECIMAL
32 ARRAY ]D
 0 VALUE T
31 VALUE N

CHAR * CONSTANT '*'

: PUTCHAR  ( char col row --) >VPOS VC! ;
: [<]      ( addr1 addr2 -- ?)  @ SWAP @ < ;  \ array compare "less than"

: SETUP ( n --)
    0
    DO
      24 RND 1+  I ]D !
      '*'    I DUP ]D @ PUTCHAR
    LOOP
;

: UPDT-LINE ( n --)
     DUP>R
     ]D @ TO T
     BL R@ DUP ]D @ PUTCHAR
     R@ 1- ]D @  R@ ]D !
     BL  R@ 1-  DUP ]D @ PUTCHAR
     T   R@ 1- ]D !
     '*' R@    DUP ]D @ PUTCHAR
     '*' R> 1- DUP ]D @ PUTCHAR
;

: RUN
    CLEAR
    N DUP SETUP
    BEGIN
       0 TO T
       DUP 1
       DO
         I 1- ]D DUP CELL+ [<]
         IF
            I UPDT-LINE
         THEN
       LOOP
       1-
    T 0=
    UNTIL
    DROP
    0 23 AT-XY ." Done" KEY
;

 

 

 

 

  • Like 4
Link to comment
Share on other sites

Is there that much difference in a pascal approach? I don't believe I've ever seen, from my knowledge anyway, of seeing a pascal program in action. But I assume it's not practical anyway due to limited hardware out there? I know very little about that system. I've been taught, extended basic is faster than basic, Forth is faster, Assembly is faster.  And thar aren't anything else.

Is the pascal card in the same camp as a Geneve card or even the strange cart? 

 

Edited by GDMike
Link to comment
Share on other sites

4 hours ago, GDMike said:

Is there that much difference in a pascal approach? I don't believe I've ever seen, from my knowledge anyway, of seeing a pascal program in action. But I assume it's not practical anyway due to limited hardware out there? I know very little about that system. I've been taught, extended basic is faster than basic, Forth is faster, Assembly is faster.  And thar aren't anything else.

Is the pascal card in the same camp as a Geneve card or even the strange cart? 

 

@apersson850  has provided tons of detailed explanations around here on USCD Pascal but here is my "executive" level version. 

 

So the PASCAL approach to programming is actually similar to Forth in that you (mostly) have to define things before you can use them. Forward references can be done but are not to be used unless there is no other option.

No GOTO,  only Structured programming  looping and branching.  The main Program: is the last definition just like you see in a Forth program and uses the stuff the came before.

 

When you talk speed of execution, its always important to distinguish between the "language" and the "implementation".   

The PASCAL card for TI-99 implements a virtual machine. This is again similar to Forth.  P-codes are bytes that represent instructions in the P-code virtual machine.

Programs compile those bytes to make programs. When you run the program the bytes are "interpreted" by a pretty quick little Assembly language program.

It's pretty fast but not native code speed. Our PASCAL card is faster than XBASIC because the bytes are "pre-compiled" and the interpreter is not written in GPL. (another virtual machine)

 

Now... we could make a Pascal compiler that emits 9900 machine code and it could run programs about the same speed as C depending on how much optimization is used.

I have that plan on the stack from an old teaching series called "Let's make a compiler".

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Forth and Pascal couldn't be further apart in clarity and readability, however. I wrote a lot of code in Pascal when I got my first Mac in 1984 (TML Pascal, then Think Pascal), since Pascal was essentially the native language of the original MacOS. I still have the source files and can still figure out what I was up too fairly easily. 

 

Forth code I wrote last week can be a mystery.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

I have a different problem, I can usually remember what my code is doing when I see it but I can't tell you what it's doing without seeing it.

I'm weird that way.

 

I have great number recollection, but can't remember names. 

My phone number from when I was in 6th grade was calculated on a calculator by 96X3x96x96+123-10000 which is my Florida phone number 264-4229.

I still remember part numbers from working on jet engines bitd. 

I can also tell you I'm a million bucks away from the number I need to have.

 

 

 

 

 

 

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...