Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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-