<div dir="ltr">This is surely a very naive idea on how to one day get cross-module inlining<div>or at least enlarge the range of possibilities for the JIT.<div><br></div><div>A lot of inlining is impossible due to the possibility to hot-swap code.</div><div>But what about in the context of a release?</div><div><br></div><div>When creating a release (or updating an old one),</div><div>the compiler/relx/whatever is generating the release has a clear and finite scope</div></div><div>of all the code that will be shipped and run.</div><div>Maybe not a clear idea of extra dependencies or resources,</div><div>but at least all the Erlang code should be there.</div><div>Then a compiler would be able to do supercompilation, agressive inlining, …</div><div><br></div><div>I was thinking that we could then get a release that resembles an executable</div><div>and if we can link external dependencies (OpenSSL, …)</div><div>we would then have a somewhat standalone binary that kind of works like escripts.</div><div><br></div><div>Is my reasoning right?</div><div>Where am I on the scale from extremely naive all the way up to ROK?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div><br></div><div>Cheers,</div><div>-- </div><div>Pierre Fenoll</div></div><div><br></div></div></div></div>
<br><div class="gmail_quote">On 7 December 2015 at 05:45, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 3/12/2015, at 8:11 pm, Michael Truog <<a href="mailto:mjtruog@gmail.com">mjtruog@gmail.com</a>> wrote:<br>
> If we had header files that were only allowed to contain functions and<br>
> types that we called "template files" for lack of a better name<br>
> (ideally, they would have their own export statements to help<br>
> distinguish between private functions/types and the interface for modules<br>
> to use)<br>
> AND<br>
> we had the include files (and template files) versioned within the beam<br>
> output (to address the untracked dependency problem).<br>
><br>
> Wouldn't that approach be preferable when compared<br>
> to trying to manage the module dependency graph during a<br>
> runtime code upgrades? Why would the "template files" approach<br>
> not be sufficient?<br>
<br>
</span>These are the differences I can see between 'template files'<br>
and 'import_static modules'.<br>
<br>
(1) 'template files' would not be modules.<br>
Having their own export directives would make them<br>
modul*ar*, but they could not use 'fun M:F/A' to refer<br>
to their own functions, having no M they could use.<br>
<br>
This does not seem like a good thing.<br>
<br>
(2) Headers can be nested. If 'template files' were to be<br>
like headers, this would create nested scopes for top<br>
level functions, and the possibility of multiple<br>
distinct functions with the same name and arity and<br>
in some sense "in" the very same module.<br>
<br>
I don't see that as an insuperable problem, but it's a<br>
very big change to the language in order to avoid what<br>
is really not likely to be a practical problem.<br>
<br>
(3) 'template files' are copied into the including module,<br>
which allows different modules to have included<br>
different versions of a 'template file'.<br>
<br>
Like headers, this DOES NOT SOLVE the dependency and<br>
version skew problems, IT CREATES THOSE PROBLEMS.<br>
<br>
So with 'template files', either you have precisely the<br>
same problems you have with headers plus a whole lot of<br>
extra complexity, or you have to track dependencies anyway.<br>
<br>
If we can take a step away from Erlang,<br>
we can see that we have a fundamental problem.<br>
<br>
Resource A is prepared from foundations x and c.<br>
Resource B is prepared from foundations y and c.<br>
Resources A and B have to "fit together" in some fashion.<br>
Common foundation c has something to do with how that<br>
fitting together works.<br>
<br>
c is revised to c'.<br>
A is re-prepared to A'.<br>
If B were re-prepared, B' and A' would be compatible,<br>
just as B and A were compatible.<br>
But B and A' are not compatible.<br>
<br>
As far as I can see, there are three general ways to<br>
deal with this kind of problem.<br>
<br>
1. Detection. When you try to use A' and B together,<br>
detect that they were prepared from c' and c and<br>
refuse to allow this use.<br>
<br>
This requires dependency tracking.<br>
<br>
2. Prevention. When c is revised to c', use dependencies<br>
forward and queue A and B for rebuilding.<br>
<br>
This requires dependency tracking.<br>
<br>
3. Avoidance. Make the preparation step fairly trivial<br>
so that whenever A (B) makes references to c, the<br>
latest version of c is used.<br>
<br>
In programming language terms, this is not even lazy<br>
evaluation, it's call-by-name. It's the way Erlang<br>
currently handles remote calls. (More or less.)<br>
<br>
As a rule of thumb, early binding is the route to<br>
efficiency (and early error detection), late binding<br>
is the route to flexibility (and late error detection).<br>
The performance cost may be anywhere between slight and<br>
scary depending on the application.<br>
<br>
3'. It is only necessary to provide the *appearance* of late<br>
binding. I have a faint and probably unreliable memory<br>
that the SPITBOL implementation of SNOBOL4 could generate<br>
"optimised" code but could back it out and recompile it<br>
when the assumptions it had made turned out to be wrong.<br>
<br>
Amongst other things, this requires the system to keep<br>
track of this-depends-on-that at run time, so it's still<br>
dependency tracking, but it need not be visible to the<br>
programmer.<br>
<br>
What might be noticeable would be a performance blip as<br>
loading c' caused everything that had been run-time compiled<br>
against c to be de-optimised. TANSTAAFL.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>