[REBOL] Re: Cross-language benchmarking
From: joel:neely:fedex at: 6-Nov-2002 8:13
Hi again, Carl ...
... on a slightly different tack.
Carl at REBOL wrote:
...
> >Goal (1): Demonstrate to the world that REBOL is a viable,
> > competitive language for many common programming tasks
> > (where "competitive" is defined in terms of run time
> > performance).
> >
...
> >Goal (3): Identify and document REBOL programming techniques that
> > have substantial effect on performance, and build a
> > vocabulary of "performance patterns" for future use.
...
> >Goal (4): Help identify "hot spots" in REBOL where performance
> > optimization would have significant perceived value.
Speaking for myself, the Ackermann discussion has already given me
some ROI on goal (3) with ideas about refactoring expressions to
minimize depth/nesting.
Now, WRT goal (4) ...
This is totally a shot in the dark, as I have no clue about the
internal structure of the REBOL interpreter, but here goes anyway!
Testing inspired by Ladislav's comments would indicate that stack
is being consumed by native functions (such as EITHER) with the
consequence that user-level recursion depth is diminished. Perl
has a mechanism that allows a subroutine to delegate to another
subroutine in a way that does not increase the call stack depth.
In pseudo-REBOL notation, one can replace something like
foo: func [x y] [
either phase-of-moon x y [
bletch x y
][
;; otherwise, do something else
]
]
bletch: func [x y] [
;; transmogrify x y and return something
]
with
foo: func [x y] [
if phase-of-moon x y [become bletch]
;; otherwise, do something else
]
(for the same BLETCH). IOW, instead of creating a new frame and
invoking BLETCH with a subsequent return to FOO and thence to FOO's
caller, the evaluation simply twiddles the state so that BLETCH is
invoked (with FOO's arguments) and BLETCH returns directly to FOO's
caller upon completion (sort of vaguely like an exec() in Unix...)
Now, I'm *NOT* suggesting that we have such a mechanism in high-
level REBOL *AT*ALL*! But I'm wondering if it would be feasible
to allow NATIVE! functions to make use of such a mechanism in
special cases, so as to minimize the stack penalty of using IF,
EITHER, etc. Specifically, could e.g. the native code for EITHER
directly proceed to the evaluation of the first or second block
alternatives without nesting a call, since we're guaranteed (I
am assuming) that the result of the nested block evaluation is
actually going to be passed back to the expression where EITHER
appeared without any further manipulation?
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
