[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

function application in rtl

From: Stefan Israelsson Tampe
Subject: function application in rtl
Date: Tue, 01 Oct 2013 19:13:22 +0200
User-agent: KMail/4.9.5 (Linux/3.5.0-30-generic; KDE/4.9.5; x86_64; ; )


As I understand, currently in rtl loops get's faster but function
application intense code becomes less effective. Function application
is currently quite expensive, but we might get it done faster in
native compiled code e.g. after we have focused on optimizing that
one. Of cause it's not the primary task right now to do this, but the
function call semantics can be good to settle before the realease.

So some points.
1. Moving data to and from a new function frame and then calling shows
some innefficiency. And we shold try to avoid this as much as
possible. This will be a problem later. A solution might be to
allocate a scratch region at the end of the frame where we simply
evaluate expressions with a simulated stack but using direct
adresses. The problem is we need to add information about where the
frame ends when returning from a funciton call. The only sane solution 
to add that number as a meta data to the function call. This might
look like a non nice solution but in practice I doubt it to be an
issue. We can keep the same number at the first function
call which means that we do not need to write it to a new function is
evaluated the second time. Of cause this trick cant't be used for g in
(f (g x)) but still it would make the problem less of an issue.

2. A good way of programming is to use monad like techniques to
transport state information. So if we use state S1, ..., Sk one
typically end up with code like

(let-values* (((S1 ... Sk X) (f R1 ... Rk Z))
              ((T1 ... Tk Y) (g S1 ... Sk Q X))

And one can sort of define a parse combinator like language to handle
the streaming. Now moving all the arguments to the end of the function
frame then all the values back and continue like this is really crazy,
because one can have say 10 states and just one state at the time is
touched by the generator etc. Now what we would like to do is to keep
the state information on the same locations in the stack and just
change the memory positions touched by e.g. f,g,X,Y,Z. My intention is 
make sure that guile can handle this pattern effectively.

3. A minor optimization in a stack based expression is to let the
first memory position in a function frame be the first return value
that means that in (f (g X) (h Y)) we do not need to move the return
value of g and h after they have been evaluated. A small but perhaps
useful optimisation.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]