Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: GRAPHICS BUGS
Message-ID: <212.UUL1.3#5129@willett.UUCP>
Date: 6 Jan 90 01:33:52 GMT
Organization: Latest Link in ForthNet Chain
Lines: 75


 Date: 01-05-90 (01:54)              Number: 1699 (Echo)
   To: MARK SMILEY                   Refer#: 1696
 From: MIKE SPERL                      Read: 01-05-90 (01:46)
 Subj: GRAPHICS BUGS                 Status: PUBLIC MESSAGE

 Mark,

     It's interesting to look at next with tt.  I've said that next 
 is faster than the subroutine call-ret mechanism.  It turns out 
 thhat this is only true for forths with next inline, as F-PC.  
 Forths without inline next are slower than other languages!  And 
 that's igoring nesting and un-nesting, which slows forth even 
 more! 

 The code:
 DDDDDDDDD
 Modifications to tt:
 PUSH SI as the first instruction in tt, and POP SI just before 
 NEXT.  The inner loop of tt to test NEXT is: 

     here
     es: lodsw       \ 18 + 11 + 15 = 44 (next not inline)
     mov ax, # here 5 +  \ instruction common to both tests
     jmp ax          \ these two inst. simulate next
 \ next instruction simulates next NOT inline (omit for inline)
     jmp here 2 +    \ each word needs to jmp >next (like ret)
     loop

 The inner loop of tt to test CALL-RET is:

     here
     mov ax, # here 5 +  \ filler, to equalize loops
     call testing    \ 23 clocks
     loop

 and, of course add:

 label testing       \ something to call
     ret             \ 20 clocks
     c;

 The results: (on 8088, with mss = 40)
 DDDDDDDDDDDDDDDDDDDDDDDDDDDD
 For ccaall - ret:
     Elapsed time =  00:00:46.80 

 For next not inline:
     Elapsed time =  00:00:48.11 

     result of testing:
          48.11 / 46.80 = 1.028 (forth takes 3% more time)

     predicted result, from manual:
         44 / 43 = 1.02 (2% more time)

 For inline next:
     Elapsed time =  00:00:37.30 

     result of testing:
         46.79 / 37.30 = 1.254 (call/ret take 25% more time)

     predicted result, from manual:
         43 / 29 = 1.48 (48% more)

 It seems software timing can vary from predicted time by as much 
 as 18%;  however, sometimes, as in the case of next not inline, 
 tt's result appears almost identical to that predicted.  So, 
 what's going on?  Is the INTEL manual inaccurate? 

     - Mike -

-----
This message came from GEnie via willett through a semi-automated program.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'