[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: goops and memoization
From: |
Mikael Djurfeldt |
Subject: |
Re: goops and memoization |
Date: |
Wed, 04 Dec 2002 03:25:51 +0100 |
User-agent: |
Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) |
Tom Lord <address@hidden> writes:
> > 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.
Yes.
> 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.
Hmm... could you please clarify this suggestion. What is the core
idea? To specify O in a custom language and compile it? To optimize
the composition of M O and U? Something else that I have missed?
Best regards,
Mikael Djurfeldt
Re: goops and memoization, Mikael Djurfeldt, 2002/12/03
Re: goops and memoization, Mikael Djurfeldt, 2002/12/03