On Sat, Apr 14, 2012 at 4:15 PM, Sandro Magi <[email protected]>wrote:
> On 09/04/2012 11:52 PM, Jonathan S. Shapiro wrote:
> > The simple explanation is that Tarditi's analysis of tree shaking was
> > naive.
>
> I recall you mentioning this before. Has an analysis ever been
> published? This sounds like a valuable empirical insight worthy of
> publication.
>
I'm not aware of such a publication, but the intuitive argument is
straightforward: how many applications do you need that *don't* need the
I/O subsystem portion of the runtime library? Each application uses a
different 85% of that subsystem, but collectively they have a huge amount
of overlap. Similarly for the OpenSSL library. Or for several others.
Where the overlap exists, the benefit of sharing code can be overwhelming.
It's more about sharing cache footprint than main memory footprint these
days, but it's still important.
There is a lesser class of libraries for which the argument is less clear.
Either few client applications run simultaneously, or the degree of
overlapping use is small.
Tree shaking is unquestionably a good idea. The point I'm trying to make is
that tree shaking reduces the size of *one* application where shared
libraries promote reuse across *many* applications. The two benefits are
not entirely orthogonal, but they are distinct.
>
> > In consequence, I proceed from the assumption that the /ability/ to
> > generate and use dynamic shared libraries is a systemic necessity, and
> > that unreserved reliance on whole-program compilation is therefore an
> > absurdity. There are clearly situations where one position or the other
> > can be relaxed. My point is only that there are an overwhelming number
> > of situations where dynamic libraries are required for performance
> > reasons, and so a systems language that is incapable of exploiting them
> > is a non-starter.
>
> I was really confused about this note, and after a few days I believe I
> understand where we crossed signals.
>
> Firstly, your original objection to type classes that I was addressing
> was that they were "too abstract" and impeded inlining. My suggestion of
> source-based "whole program compilation" was to address *that specific*
> problem.
>
> This discussion of dynamic linking seems entirely orthogonal, since if
> you're linking dynamically, you've already given up inlining, assuming
> current linking infrastructure -- although LLVM is beginning to change
> that.
>
This is not true. It is true that you cannot inline across the dynamic
library boundary without a JIT system, but that was never my concern. My
concern was the inability to inline **ground operations** such as integer
addition.
> Assuming dynamic linking is also a requirement, that can be accommodated
> via standard mechanisms and a name-mangling scheme, which I believe
> you've already done for BitC. Technically, the specialization is then no
> longer "whole-program", but only a certain "mode" of the compilation
> where the developer has specified that it's required.
>
The specialization is still whole program. It's just that certain entry
points to the library have been subjected to ahead-of-time (AOT)
specialization.
> Now we reach the crux, which is how do we know when to specialize and
> when to link? I've suggested before that a 'specialize' keyword would
> allow developers to declare compile-time specialization requirements,
> which the compiler must be able to satisfy, ie. source is available.
>
We chose a different route. Our approach was to have the user define an
interface that *declares* the desired specializations. The compiler accepts
these as entry points. The end effect is similar.
However, this approach does not address other forms of specialization -
mainly size based - that we might want to consider. Nor does it address *
partial* specialization, in which (e.g.) we specialize uses at Arith(int)
but not at Arith('a).
> I don't think this is a trivial solution, but I don't think it will
> require any serious innovation either, and it seems to achieve all
> goals. So what is the problem with this approach?
>
Ignoring some find tuning, the only problem with this approach is that I
don't have two years to implement a new type checker and compiler.
But for exactly that reason, none of this is the "real" issue. The real
issue is instance coherence and resolution.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
