[colorforth] FS/Forth for DOS: crude performance test

[Samuel Falvo <falvosa@xxxxxxxxx>]

I entered the following program in a block:

: i 1+ 1- 15 * 16 / 2* 2* 2/ 2/ DUP DROP DUP DROP SWAP SWAP ;   ( test 1 )
: i ;                                                           ( test 2 )

: 8i i i i i i i i i ;
: 64i 8i 8i 8i 8i 8i 8i 8i 8i ;
: 512i 64i 64i 64i 64i 64i 64i 64i 64i ;
: 4ki 512i 512i 512i 512i 512i 512i 512i 512i ;
: 32ki 4ki 4ki 4ki 4ki 4ki 4ki 4ki 4ki ;
: 256ki 32ki 32ki 32ki 32ki 32ki 32ki 32ki 32ki ;
: 2mi 256ki 256ki 256ki 256ki 256ki 256ki 256ki 256ki ;
: 16mi 2mi 2mi 2mi 2mi 2mi 2mi 2mi 2mi ;
: run 0 16mi DROP ;

I executed run under both PygmyForth and FS/Forth for DOS.  The platform is a
80486 33MHz processor with 8MB of RAM, with *I think* 512K of cache, but I'm
not sure.  It's a Toshiba Satellite laptop, T2100.

Test 1:  exercises some commonly used math/stack ops
  PygmyForth: 63s
  FS/Forth:   53s

Test 2:  exercises subroutine call overheads
  PygmyForth:  9s
  FS/Forth:    1.5s (approximately -- we're getting into noise floor here!)

Interpretation: FS/Forth has negligable threading overhead; it is, in fact,
almost 6x faster (approximately) than PygmyForth.  Pygmy spends 54s doing
actual arithmetic and stack operations.  FS/Forth spends 51.5s.  Most of this
time is dominated by how long it takes the CPU to execute these instructions.

Even so, FS/Forth is faster than PygmyForth, though only slightly.  For most
applications, however, there will not be a noticable difference.

Some things to consider about FS/Forth:

1.  It's constantly exchanging BP and SP to selectively gain access to the data
stack.  It's aggressive about keeping SP the return stack pointer and BP the
data stack pointer.  Thus, there are a lot of useless sequences, like this:

    . . .
    XCHG BP,SP ; BP is once again the data stack pointer.
    XCHG BP,SP ; OOPS!  We need to access the data stack again!
    . . .

This code usually appears only when doing a lot of manipulation with literals
or conditionals.

2.  Primitives ARE NOT compiled inline; hence +, -, *, /, U/MOD, et. al. are
all encoded as subroutine calls, which means CALL and RET overheads are
everywhere.  FS/Forth 1.3 for DOS is quite definitely not a MachineForth
implementation.

Despite these deficiencies (which will utterly disappear in the Linux version
of FS/Forth, which WILL be a MachineForth), FS/Forth is still slightly faster
than PygmyForth.  I am very pleased with the results.  Things can only improve
from here.

--
Samuel A. Falvo II


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com