On Fri, Jan 9, 2015 at 1:34 AM, Keean Schupke <[email protected]> wrote:
> On 9 January 2015 at 09:31, William ML Leslie < > [email protected]> wrote: > >> I don't mean to say that all instances need to be static constants, >> only that functions that use them can be specialised statically if the >> instance can be resovled statically at the call site, which is a >> fairly common case. >> > You need whole-program compilation to trace from the top level to do that > surely? > Yes and no. My quibble here is that when people say "whole program compilation" they tend to mean *static* whole program compilation. We don't actually need that. It is sufficient if we perform staged or just-in-time compilation, and if we do so only for that portion of the program that is actually executed. In other words: yes, but we can cheat. The reason I'm emphasizing staged compilation here is that it gives us an interesting implementation escape hatch. The two problems with JIT are (a) startup cost, and (b) total loss of code reuse across processes. The cute part about specialization is that we can remember what specializations were needed, mark them for offline generation, and have a dynamic library format that combines pre-specialized code with yet-to-be-specialized code. The pre-specialized code is shareable. The dynamically specialized code is some variant of a (hopefully low level) AST. By keeping a record to the side of which specializations were needed at run time, we can have a background agent that performs incremental expansion of the specialized part of the library. That's actually a very interesting position, because it allows us to specialized (a) explicitly, at static compile time, based on source-langauge directives [so very early], (b) at dynamic load time [very late] (c) in the background [the hybrid approach above], or (d) at install time. A suitable combination of these will hopefully get us to the program startup times that we want to see. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
