[OT] RE: counter++ versus

[Kevin]

I realize that comparing Forth to xTalk/Transcript is in many ways is akin to comparing apples to oranges.  However, they are both TILs and suffer many of the same design problems.  I am also not running down Revolution it is a impressive product which I use quite regularly.  I would appreciate any documentation on how the Revolution engine works so I may educate myself.  In fact I would love access to the engine source in the hope of speeding up the engines.  I believe that Runtime would greatly benefit from the release of the engine source under some Open Source style license.  I say this since it is my perception that Runtime’s primary investment in the Revolution product line is their RAD/GUI.

Kevin


-==-=-=-=-=-=-==-=-=-=-=-=-=-=-==-=-=-=-=-=-
Disclaimer:

Any resemblance between the above views and those of my
employer, my terminal, or the view out my window are purely
coincidental. 
Any resemblance between the above and my own views is non-deterministic.

 The question of the existence of views in the absence of anyone to hold
them
is left as an exercise for the reader. The question of the existence of
the reader
 is left as an exercise for the second god coefficient. 
(A discussion of non-orthogonal, non-integral polytheism is beyond the
scope of this article.)



 --- On Thu 03/25, Dar Scott < dsc at swcp.com > wrote:
From: Dar Scott [mailto: dsc at swcp.com]
To: use-revolution at lists.runrev.com
Date: Thu, 25 Mar 2004 10:50:10 -0700
Subject: Re: [OT] RE: counter++ versus 

<br>On Thursday, March 25, 2004, at 09:09 AM, Kevin wrote:<br><br>> If you ask me 'RR' is much slower than I would have expected a engine <br>> of its maturity and evolution.  Forth interpreters using direct <br>> threading and even token threading are considerably faster than 'RR'.<br><br>That is how I would do it (being ignorant of the experiences of xTalk <br>developers).<br><br>As mentioned in the discussion on when compiling is done, there are <br>tradeoffs between the two threading methods.<br><br>There are some things to consider in comparing speed.  Revolution uses <br>values that might be arrays or strings and the strings might really be <br>floating point numbers.  Forth interpreters typically uses words.  <br>However, Revolution seems to handle values pretty fast in built-in <br>code.  Also, the Transcript is more complicated than it looks.  An <br>example is an object reference.  In this case, probably more can be <br>done at the compiler level.  Transcript supplies some script <br>information in errors; the selected method might have a speed impact.<br><br>The last time I was timing Revolution constructs, the release I was <br>using turned out to be a debug build or something and ran slowly.<br><br>> There are also several constructs that can drastically alter <br>> performance in a TIL.  For example many TILs use a hash table for <br>> their dictionary.  In a large implementation these can cause <br>> significant speed anomalies.  In many of the engines I built the <br>> dictionary was a Red Black Tree to ensured optimal performance (more <br>> information it available on this data structure can be found int <br>> Robert Sedgewick's Algorithms book).<br><br>The independence of objects and the semantics of calls requires a <br>search through the message path, presumably through a sequence of <br>optimized tables.<br><br>Some methods for optimizing this have been discussed on the "improve" <br>list.<br><br>One dynamically makes the link direct between times of possible changes <br>in scripts and paths and related changes.  This requires no language <br>change.<br><br>Another adds the concept of a script local function or command.  This <br>hides the name from other scripts and requires references to it in the <br>script to skip the message path and use the local function or command.  <br>I would expect the compiler to compile a direct call in this case.  <br>This is a small language change.<br><br><br>As far as only 7 times slower...  Well, I have sometimes said that <br>arithmetic in Revolution is much too fast.  As far as the number?  <br>Well, I spent the first few years of my life in Missouri.<br><br>Dar Scott<br><br>_______________________________________________<br>use-revolution mailing list<br>use-revolution at lists.runrev.com<br>http://lists.runrev.com/mailman/listinfo/use-revolution<br>

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!