[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: goops and memoization
From: |
Tom Lord |
Subject: |
Re: goops and memoization |
Date: |
Tue, 3 Dec 2002 00:38:53 -0800 (PST) |
> But, as said earlier, being a efficiency freak, I'd like a
> solution which works on the memoized code. In order to
> maintain a reasonably clean separation of goops code and the
> details of memoizing, it might then be a good idea to provide
> some kind of code traverser which goops can plug into and
> operate with minimal knowledge of memoized representation and
> environment.
Abstractly, you're computing something like:
(M (O (U (M <source>))))
where M is the memoizer, O the optimizer, and U the unmemoizer.
Your ideal is to have O be a clean, perhaps even portable,
source->source transform that knows nothing about memoization, yet for
the whole composition to be fast.
Have you considered the approach of writing a custom optimizer (not O,
but another optimizer) that can do a good job of "compiling" (scheme
to scheme):
(lambda (ms) (M (O (U ms))))
?
If O is very clean/high-level, you can do all kinds of tricks by
transforming it (e.g. automatic conversion to demand-driven
execution). Writing O is just writing (with nothing extraneous) the
transforms that describe the possible optimizations, and then tools
that compile O and compositions of O with M and U can work out when to
apply those transformations and short-cut the compositions.
-t
Re: goops and memoization, Mikael Djurfeldt, 2002/12/03
Re: goops and memoization, Mikael Djurfeldt, 2002/12/03