<div dir="auto">When it comes to optimization, I would rather see something like this: <a href="https://github.com/lumen/lumen">https://github.com/lumen/lumen</a> - statically compiled, portable single binary with all optimizations already executed AOT. If a compiler includes typecheck/dyalizing in compile time, that's extra bonus. Then we would approach Haskell/Go type of deployments (most modern languages adopt this approach). TBH, I never used hot-code swapping anyway, so for me it is rally a small price to pay considering all the benefits this brings.<div dir="auto"><br></div><div dir="auto">BR,</div><div dir="auto">Drasko</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 21, 2020, 14:37 Grzegorz Junka <<a href="mailto:list1@gjunka.com">list1@gjunka.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 21/06/2020 10:16, Mikael Pettersson wrote:<br>
> On Sat, Jun 20, 2020 at 10:05 PM Grzegorz Junka <<a href="mailto:list1@gjunka.com" target="_blank" rel="noreferrer">list1@gjunka.com</a>> wrote:<br>
>> OK, there is a bunch of limitations listed in <a href="http://erlang.org/doc/man/HiPE_app.html#feature-limitations" rel="noreferrer noreferrer" target="_blank">http://erlang.org/doc/man/HiPE_app.html#feature-limitations</a><br>
>><br>
>> Erlang tracing is one of them. Are those limitations inherent to the HiPE compiler, i.e. they can't be fixed,<br>
>> or they are simply there because they haven't been implemented? Or in other words, is AOT compilation<br>
>> of Erlang code into native code doomed and JIT is the only solution to speed it up?<br>
> AOT compilation of Erlang is not inherently difficult.  The problems<br>
> faced by HiPE are due to a few<br>
> unfortunate facts:<br>
><br>
> ...<br>
><br>
> A way to resurrect HiPE could be to:<br>
><br>
> A. Retarget the compiler to consume a higher-level more stable<br>
> intermediate representation from the<br>
>      BEAM compiler, perhaps Core Erlang but even that is a moving target.<br>
> B. Drop all remnants of being able to native-compile individual MFAs,<br>
> just handle whole modules.<br>
>       (That restriction is already in place, but the internals still<br>
> operate on individual MFAs.)<br>
> C. Fix the bugs, streamline the VM interfaces between BEAM and HiPE.<br>
><br>
> Realistically this would require 6 person-months or more.<br>
<br>
<br>
Thanks Mikael for the explanation. I understand the facts but still <br>
don't understand why it's worth investing in JIT instead of developing <br>
the features you listed that would be needed to resurrect HiPE.<br>
<br>
For example, you mentioned HiPE was abandoned 10 years ago, but that's <br>
roughly also the time when the core team started working on the first <br>
implementations of JIT. Did you think at that time that JIT would be <br>
less effort than improving HiPE, or maybe there was no personal interest <br>
in HiPE among the core team?<br>
<br>
To me, as a software developer, it just seems strange to abandon HiPE <br>
and allow the code to deteriorate after it has been proven to work, and <br>
instead put so much effort into JIT that has never worked and never been <br>
proven to work as well as HiPE.<br>
<br>
Maybe there are some politics involved between the core team and the <br>
team that worked on HiPE that you don't want to mention, which is fine, <br>
or maybe there were some mistakes made in the past that no one wants to <br>
admit to, which is again understandable. But none of the technical <br>
reasons I've read so far favor JIT over HiPE, so I hope you don't mind <br>
me drilling this subject.<br>
<br>
One technical reason mentioned, that wasn't related to the abandonment <br>
of the code, was that JIT would benefit both, Elixir and Erlang. But <br>
surely that must be also true if HiPE targets the intermediate <br>
representation from the BEAM compiler?<br>
<br>
Grzegorz<br>
<br>
</blockquote></div>