Re: a unified caching system for avoiding recomputation
Johnicholas Hines <[email protected]> Thu, 19 Jul 2012 08:47:39 -0400
| Newsgroups | gmane.culture.people.kragen.discuss |
|---|---|
| Message-ID | <CAEpeLrM+CmYRw2SpBvXZx9jWmLYM0Pqv0woyhRkUqW46TMd2-A@mail.gmail.com> |
--===============1027019986== Content-Type: multipart/alternative; boundary=14dae9cfcdb84dfdab04c52e2f0f --14dae9cfcdb84dfdab04c52e2f0f Content-Type: text/plain; charset=ISO-8859-1 I am not sure if you want more examples, but: Spreadsheets often carefully avoid recomputation (a.k.a. caching or memoization) Gosper's HashLife is an example of clever memoization Blelloch, Acar and Harper have a couple papers called "Selective Memoization" and "Adaptive Functional Programming" about memoization and incremental recomputation that seem (to my idiot eyes) to offer a programming language theory-based approach to control of memoization (you can memoize everything and some programming languages do but it's not usually practical.) Soar has a form of memoization called chunking that is a little bit "lifted". Rather than a function computing an output from an input, and then storing an input/output pair, there's a backtracing step and the thing that is memoized is a rule that has variables in it - it may be able to apply to sufficiently similar inputs, a form of explanation-based generalization. I think it's also a bit like just-in-time compilation. Just-in-time compilation is an example of selective memoization - the compiled code (as you mention) is the output of a computation, and keeping an executable around is a cache. However, you don't necessarily want to do the compilation step; the heuristics around just-in-time computation are about how to decide when it would be worthwhile to start a cache. Johnicholas --14dae9cfcdb84dfdab04c52e2f0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not sure if you want more examples, but:<br><br>Spreadsheets often car= efully avoid recomputation (a.k.a. caching or memoization)<br>Gosper's = HashLife is an example of clever memoization<br>Blelloch, Acar and Harper h= ave a couple papers called "Selective Memoization" and "Adap= tive Functional Programming" about memoization and incremental recompu= tation that seem (to my idiot eyes) to offer a programming language theory-= based approach to control of memoization (you can memoize everything and so= me programming languages do but it's not usually practical.)<br> <br>Soar has a form of memoization called chunking that is a little bit &qu= ot;lifted". Rather than a function computing an output from an input, = and then storing an input/output pair, there's a backtracing step and t= he thing that is memoized is a rule that has variables in it - it may be ab= le to apply to sufficiently similar inputs, a form of explanation-based gen= eralization. I think it's also a bit like just-in-time compilation.<br> <br>Just-in-time compilation is an example of selective memoization - the c= ompiled code (as you mention) is the output of a computation, and keeping a= n executable around is a cache. However, you don't necessarily want to = do the compilation step; the heuristics around just-in-time computation are= about how to decide when it would be worthwhile to start a cache.<br> <br>Johnicholas<br> --14dae9cfcdb84dfdab04c52e2f0f-- --===============1027019986== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- To unsubscribe: http://lists.canonical.org/mailman/listinfo/kragen-discuss --===============1027019986==--