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