[REBOL] Re: What language am I looking for?
From: petr:krenzelok:trz:cz at: 17-May-2001 7:08
Hi Joel :-)
Joel Neely wrote:
> Hi, Brent, Ken, and all...
>
> I like REBOL. REBOL is good.
>
> (Did I mention that I like REBOL?) Having said that...
>
> Given REBOL's compact and expressively powerful notation,
> the REBOL implementation is not as fast as those of more
> limited notations.
Ladislav thinks Rebol could become much faster, if certain things are
implemented (see his rep - don't remember url now ...)
> 0) Interpret the language. Accept the reduced execution
> speed as the cost of flexibility.
>
that's ok, ... look I am no expert on languages, but reading Ladislav's
doc I came to conclusion, that sometimes we could accept some small
language limitations gaining us much more execution speed. After all -
the proposed changes are not drastic imo ...
> 2) Use a "just-in-time" compilation strategy, in which the
> compiler is part of the run-time system. Whenever a
> block is first encountered in a code-like usage, compile
> it to machine code and thereafter treat each code-like
> use of the block as an invocation of that machine code.
> However, any data-like mutation of the block voids the
> warranty on the compiled representation. Flag the block
> as no longer being compiled. Any subsequent code-like
> use must first re-invoke the compiler.
>
that's why Ladislav suggest immutable block representation. If you know,
that your block will not be modified during the execution phase, you
could compile it then - this partial compilation could bring us some
nice speed increase ... well, as I said - just my theory without any
experience :-)
> Accept the run-time penalty of compilation, as well as
> the space-wise and code-wise complexity of putting the
> compiler into the run-time system, as the costs of
> higher execution speed.
As for above - maybe for some of us such additions would outweight above
mentioned factors?
Just a sidenote: I like Tao's aproach here - translated and compiled
into machine independent code (Virtual Processor code). During ICOA days
Amigans looked at slim binaries principles too.
> Accept the fact that net speed
> over some programs (e.g., those that keep manipulating
> and evaluating the same block(s) repeatedly) may not
> be much of a gain -- if any -- over plain interpretation.
>
> (Note that "data-like mutation of the block" includes any
> changes to its content, the content of its content, etc.
> Such transitive closures are non-trival to compute! I'll
> not pursue this aspect further, at least for now; I just
> wanted to point out that there are *HAIRY* details.)
>
ah, you are probably right here. But then it's up to app designer to
construct block the way compilation will make sense for him/her if
he/she wants to use it :-)
> 3) Use a probabilistic "just-in-time" compilation strategy,
> in which a block is interpreted for the first few code-
> like uses. Statistics of such use are kept. After the
> number of such uses (or frequency of such uses) passes
> some threshold, the run-time system then decides to make
> and cache a machine-code version of the block. This has
> all of the costs of (2) plus the complexity of the
> decision heuristics. It also has the same property that
> constant twiddle-and-run activity frustrates the speed-
> up mechanisms.
>
interesting technique ....
> I'm very interested to see if anyone can suggest any others.
> Note, again, that I'm talking about implementation strategies,
> not properties of the "source code" notation.
>
> Let's see how these alternatives fare on some trade-off
> criteria, with the following definitions. By "compact" I
> mean both the source code and the size of the run-time
> system (interpreter, compiler, libraries, whatever...)
> By "powerful" I mean expressive power; others are free to
> define their own contexts. ;-) By "simple" I'm referring
> to the implementation and run-time system, and *NOT* to the
> notation. By "fast" I mean... fast execution.
>
> Option Compact Powerful Simple Fast
> ------ ------- -------- ------- ---------
> (0) yep yep likely nope
> (1) sort of less so less so best
> (2) nope yep nope sometimes
> (3) no way yep NOT! sometimes
>
> Obviously, these are broad-brush statements. However, I
> invite anyone who wants to disagree (in qualitative, broad-
> brush terms, please!) either to provide another alternative
> with compelling arguments why it obviously doesn't fall into
> a trade-off, or to show compelling reason why one or more of
> the above generalities must be flawed for some case.
>
heh, I left further comments to language gurus :-)
Cheers,
-pekr-
