Re: Why is GForth-ITC fast?

On May 1, 12:33 pm, Albert van der Horst <alb...@[EMAIL PROTECTED]
>
wrote:
> In article
<62b620ea-05c4-4817-8e52-e2c81e640...@[EMAIL PROTECTED]
>,
<brian....@[EMAIL PROTECTED]
> wrote:
> >I have been dis-assembling pieces of GForth and I don't understand why
> >it is generally faster than other ITC Forths that are written in
> >Assembler like CI-Forth or my old 16 bit HS/Forth.  The Assembler
> >primitives seem to be so much smaller from what I can see.  Is the C
> >compiler smarter than we are?
>
> >Here are some examples
>
> <code samples snipped>
>
> Speed out of the box is no design goal of ciforth.
> Without looking at assembler code you see this in ciforth:
> : 1+ 1   + ;
> : <> -   0=   0= ;
> : 2/   S>D   2   FM/MOD   SWAP   DROP ;
>
> Steve Pelc notes in an other reply that POP and PUSH instructions
> may be unfavourable for certain i86 processors. In the code examples
> you can see that ciforth uses them instead of faster instructions.
> This has to do with optimisation philosophy.
>
> I've published about optimisation in this forum before and you
> can read about it on my website.
>
> The ciforth philosophy to optimisation is total introspective
> capability. The pop's serve very nicely there. Then this
> introspective knowledge is used to optimise in a separate step.
> Release 5.0 of ciforth will be totally introspective,
> meaning that the stack effect of all kernel words are known by
> the kernel or can be derived by simple rules plus few exceptions.
> Replacing the pops and other microscopic inefficiencies up front
> would defeat that.
> A non-optimised program spends most of its time by jumping around and
> pu****ng data around. The payload is in operations like ADD, XOR AND
> and writing the output files. My first goal is to use the
> introspective knowledge to reduce the pu****ng and jumping to a
> minimum, then worry about what's left.
> If this is ever realized, the results on recursive benchmarks
> will be spectacular without even the use of information beyond the
> 80386 programmers manual.
>
> I expect that ciforth as it is now can be made quite a lot faster by
> more classic techniques. If someone is inspired to do so, be my guest.
> Have a look at iforth first, that is the Forth to beat. It could
> take your inspiration away. Anyway I'm certainly willing to help.
> Large f.p. calculations is where speed counts the most.
> Speeding up a Forth without floating point could be a waste of
> time, depending on your POV.
>
> A further note. I think ciforth is amenable to experimentation, like
> changing the threading method, but then you should use the generic
> system, that is one step before the ci86.lina.asm such as used by
> Spykerman. Putting the code field manually at the end of a header
> or changing next is best done at one place in a macro not all over
> the place.
>
> >Brian Fox
>
> Groetjes Albert
>
> --
> --
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- like all pyramid schemes -- ultimately falters.
> albert@[EMAIL PROTECTED]
 &=nhttp://home.hccnet.nl/a.w.m.van.der.horst


Ok so I tried removing LODSW from my old trusty 16 bit Hs/Forth. Code
is below.

These results show no difference from using LODSW or the equivalent
instructions.  Is it possible that LODSW just microcodes into the same
thing in modern CPUs?  Am I doing a valid test here?

What I know, I'm in management now :-)

Anyway, HS/Forth takes 28% longer to run TEST! than GForth-itc

\ Test NEXT without LODSW

\ standard NEXT macro in HS/Forth. Recompiled to be consistent
: NEXT.

           LODSW.
      DI AX XCHG.
      [DI]  JMPI.  ;

\ "new-next" macro
: NNEXT.
      ax ds: [SI] mov.
      si inc.
      si inc.
      DI AX XCHG.
     [DI]  JMPI.  ;

\ store with a NEXT, re-compiled to be conistent
code !
        [bx] pop.
         bx pop.
         next.
end-code

\ store with a new-NEXT
code !!
        [bx] pop.
         bx pop.
         nnext.
end-code

variable x

: test!
      100 0 do
      30000 0 do
      \ 100 ! store ops
        i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !
i x !
        i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !
i x !
        i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !
i x !
        i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !
i x !
        i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !
i x !
        i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !
i x !
        i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !
i x !
        i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !
i x !
        i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !
i x !
        i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !  i x !
i x !
      loop
      loop ;

\ Benchmarks done on AMD Sempron 1.6 GHz, with 1 Gb RAM; Windows XP
SP2
\ Hs/Forth
\ elapse test!
\ Elapsed time =00:00:05.22 ok
\ Hs/Forth
\ elapse test!!
\ Elapsed time =00:00:05.22 ok
\  28% slower than GForth (below)

\ Gforth-itc  version 6
\ elapse test!
\ Elapsed time: 00:00:04.070 ok

: test!!

        100 0 do
        30000 0 do
        \ 100 !! store ops
          i x !!  i x !! i x !! i x !! i x !! i x !! i x !! i x !! i
x !! i x !!
          i x !!  i x !! i x !! i x !! i x !! i x !! i x !! i x !! i
x !! i x !!
          i x !!  i x !! i x !! i x !! i x !! i x !! i x !! i x !! i
x !! i x !!
          i x !!  i x !! i x !! i x !! i x !! i x !! i x !! i x !! i
x !! i x !!
          i x !!  i x !! i x !! i x !! i x !! i x !! i x !! i x !! i
x !! i x !!
          i x !!  i x !! i x !! i x !! i x !! i x !! i x !! i x !! i
x !! i x !!
          i x !!  i x !! i x !! i x !! i x !! i x !! i x !! i x !! i
x !! i x !!
          i x !!  i x !! i x !! i x !! i x !! i x !! i x !! i x !! i
x !! i x !!
          i x !!  i x !! i x !! i x !! i x !! i x !! i x !! i x !! i
x !! i x !!
          i x !!  i x !! i x !! i x !! i x !! i x !! i x !! i x !! i
x !! i x !!
        loop
        loop ;