On Tue, Jul 26, 2011 at 6:43 AM, John Nilsson <[email protected]> wrote:
> In other words a _lot_ of CPU cycles are spend on deriving the same > information, again and again, each time a program is loaded. Not only is > this a waste of energy it also means that each interpreter of the program > needs to be able to derive all this information on their own, which leads to > very complex programs (expensive to develop). > The right answer here: use a cache. I.e. treat compiled code (or, at least, pre-parsed to AST and annotated code) as a cached optimization of source. This does require we design our language and distribution protocol for effective hashing and caching. > > Would it not be a big improvement if we could move from representing > programs as text-strings into representing them in some format capable of > representing all this derived information? Does any one know of attempts in > this direction? > There have been a lot of efforts on proof-carrying code and the like, that you could look into. But I do not believe that this makes a good distribution format. The basic issue is: the desired annotations are typically 'private' to an implementation of a compiler or interpreter. Attempts to standardize the set of derived information would always miss something. The optimizations one can perform are often contextual (especially for space optimizations - e.g. can you replace this block with code that's already installed?) but information about context doesn't transfer well. I do not believe we'd get a 'big improvement' from these efforts. Consider these alternatives: * modularity and caching * obtain source through a trusted 'intermediate' service that can proxy, cache, and compile on your behalf. (This is how I envision embedded systems working with source - ship the URI off to a trusted compiler in the cloud, and use the signed feedback).
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
