Rev now tied with RB at 78 ticks
ambassador at fourthworld.com
Wed Apr 21 22:45:39 CDT 2004
Chris Yavelow wrote:
> Richard Gaskin wrote
>> the obvious choices for that task, C
>> or Assembler, remain ommitted from the evaluation.
> I don't see C or Assembler as the "obvious choice" -- Although I have
> taken courses in both, I don't know enough about either to make the
> development time-effective. Can C really open a 120,000-word file and
> another file, and then compare them for matches, and then display the
> results in significantly less than 78 ticks?
I thought we'd moved past significant speed differences quite some time
But seriously, what do you think Revolution, RealBASIC, and SuperCard
were written in?
Rev and SC are flexible enough to have their IDEs written in their own
scripting language, but the core engines for all three are based in C.
Most operating systems are written in C, as are most device drivers and
of course most commercial applications. OS vendors document their APIs
with C interfaces, there are millions of lines of efficient code
examples for them, and most C compilers offer a wide range of
So yes, I would imagine that less generalized code written in C to
address the specific task would be much faster than running it through
the Rev VM or the BASIC libraries first.
But all of this raises some questions about "compiled" languages:
If one compiles to true machine code, the language used should not play
a significant role in execution speed; machine instructions are machine
instructions. Tom Pittman used to argue that while Pascal was easier to
write than the Assembler-substitute that is C, with appropriate compiler
optimizations the object code should execute at least as fast (actually,
he felt Pascal was more compilation-friendly and should therefore run
measurably faster, but that's a different story).
In contrast to ostensibly "compiled" languages, Rev makes no bones about
its two-pass on-the-fly compilation. The traditional argument in favor
of 4GLs centers instead around productivity and overall ROI, and since
most of what's executing in a 4GL is indeed highly-optimized C in the
VM, a good modern 4GL like Rev will likely perform adequately for most
But since 4GLs are typically made with a 3GL, no one expects a 4GL to be
as fast as a 3GL.
Yet in this case it is.
So for all the DIM statements, the bit-counting, data typing,
compile-runtime cycles, inability to modify code at runtime, generally
longer blocks of code, translating OS API examples from C to Beginner's
Code, etc., the merely semi-compiled Rev is still as fast as an
ostensibly "fully compiled" language.
In my office when speed is critical the answer is C, and when ROI is
critical the answer is scripting. Rev gives us the option to use either
as needed. I spend _much_ more time on user task analysis than on
coding, but that's not a luxury lower-level languages afford for
vertical products, at least not at the same level of profitability.
And as this exercise has illustrated, with Rev it's pretty rare that
speed is critical enough to require C.
For another fine example of good Transcript in action, check out
MindLube's RevCLIPS library at
<http://www.mindlube.com/developer/revclips/>. It's a native Transcript
implementation of the CLIPS expert system -- Alex has effectively used a
4GL to write a 5GL, with very impressive results.
>> But as of this morning this doesn't matter: Thanks to Brian Yennie's
>> post, Rev either retook the lead or is so close the differences are
>> negligible (depends how the testing will turn out on Yav's machine).
>> Here's the post in case you missed it:
>> On guard! Another Rev entry!
> Yes, Brian Yennie's contribution evened out the playing field. RB and
> Rev are now both at 78 ticks. Bravo!
Now that the speed of this one function is out of the way, what other
criteria will you be evaluating for the project at hand?
Fourth World Media Corporation
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode