<div dir="ltr"><div>Following up my own post.</div><div>We have got a lot of questions and comments regarding this post and this is an attempt to summarize and answer most of them.</div><br><div class="gmail_quote"><span class="gmail-im" style="color:rgb(80,0,80)"><div dir="ltr" class="gmail_attr">On Thu, Jun 18, 2020 at 10:35 AM Kenneth Lundin <<a href="mailto:kenneth@erlang.org" target="_blank">kenneth@erlang.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><h4 style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px"></h4><p style="margin:1em 0px;color:rgb(0,0,0);font-family:sans-serif;font-size:13px">HiPE is the runtime and compiler support for native code generation of Erlang modules that some of you might have tried, it is part of the OTP repository today.</p><p style="margin:1em 0px;color:rgb(0,0,0);font-family:sans-serif;font-size:13px">The OTP team is planning to remove HiPE in the OTP 24 release for the following reasons:</p><ul style="line-height:1.5em;list-style-type:square;margin:0.3em 0px 0px 1.5em;padding:0px;color:rgb(0,0,0);font-family:sans-serif;font-size:13px"><li style="margin-left:15px;margin-bottom:0.1em">we plan to introduce a new way of executing Erlang, the "JIT" described by Lukas Larsson at Code Beam V</li><li style="margin-left:15px;margin-bottom:0.1em">since OTP 22, HiPE is not fully functional (does not handle all beam instructions and combinations)</li><li style="margin-left:15px;margin-bottom:0.1em">there is no use of HiPE among our primary customers. We actually don't know where HiPE is used except for speeding up Dialyzer which we have another solution for.</li><li style="margin-left:15px;margin-bottom:0.1em">The current support for HiPE in the code is a blocker or creates extra work in our new development.</li></ul><p style="margin:1em 0px;color:rgb(0,0,0);font-family:sans-serif;font-size:13px">In order to not remove HiPE in OTP 24, we really soon need maintainers committing (long term) to keep HiPE in shape and up to date with the rest of OTP.</p></div></blockquote></span><div>This is not a choice between HiPE and the new way of executing Erlang, the "JIT". We will introduce our "JIT" anyway. </div><div>The question is about who is using HiPE and if there is someone that wants to commit to a lot of work getting HiPE in shape and keep it there.</div><div><br></div><div>## Reported uses of HiPE ##<br><br>So far we have heard of 2 uses of HiPE, one with OTP 21.3 and one with<br>OTP 18.<br>Both are very special cases and the claimed speedup of 100 times in the OTP 18 case must have another explanation than only the difference between interpreted or native code. Maybe an unfortunate effect of GC, etc. normally the absolute best you can expect from HiPE is 10 times faster than the interpreted variant (for a specific function with a perfect fit for the optimizations done in HiPE).<br><br>## Why implement a new JIT instead of continuing with HiPE? ##<br><br>- There are a number of issues with HiPE very well described by Mikael Pettersson<br>- The JIT the OTP team have developed is a simple solution that gives good performance improvements for a small work effort.<br>- All JITs are not the same, the previous experiments that Lukas mentions in his talk has been tracing JITs generating native code for the hot spots. </div><div>We have learned a lot from those JIT experiments and that is why we now will introduce a JIT that is very simple, it does not need a register allocator and other optimizations.</div><div>What we now call "JIT" is rather a new way of executing beam instructions, so it is an integral part of the Erlang VM and everything about execution is 100% equivalentto the interpreted variant (except speed) so all tests can be reused as is.<br><br>## Is an AOT compiler like HiPE doomed for Erlang? ##<br><br>No but HiPE in its current form need a major work effort to get in shape with the rest of the system as Mikael Pettersson written in his excellent answer.<br><br><br>## More questions about the new way of executing Erlang, also called the "JIT". ##<br><br>Q: Why is there only support for X86-64 in the first version?<br><br>We must start with something and X86-64 happens to be the most used platform.<br>More processors like ARM will come later and current way of interpreting will still be supported for all architectures. </div><div>So there will not be fewer architectures supported than we have today.<br><br>The "JIT" is rather a new way of executing beam instructions which is a super simple translation to native code.<br>We begin with support for X86-64 because we must begin with something and don't want to wait until we have support for all CPU architectures before we release this.<br>The "ordinary" beam threaded code interpreter will still be available for all platforms.<br><br>The cost for implementation and maintenance of the "JIT" is low  which means that we can handle it with the current team.<br>We estimate the cost of implementing the "JIT" to much less than fixing HiPE and it will be easier to maintain since<br>it will be 100% equivalent to  the interpreter. Another important property of the JIT is that .beam files will still<br>be target independent.<br>LLVM or corresponding technology is not needed since there are no compiler optimizations going on.</div><div>When it comes to compiler optimizations we focus on the Erlang compiler and how to generate "optimal" </div><div>sequences of beam instructions. <br><br>The new "JIT" will not have a negative impact on the possibility to run Erlang where low power consumption is important because:<br>1. The current interpreter will still be around supporting all architectures.<br>2. The JIT is just working extra during load time (and very little at that) and has no overhead in a system that is up and running.<br>   The JIT is excuting less CPU instructions per BEAM instruction, which must be power saving.<br><br>The main thing with the "JIT" is not that it give better performance than HiPE for all cases. It will give a<br>significantly better performance while still being low cost to implement and maintain. It will take the same platform<br>independent .beam files and just run, no differences for the users.<br>Supporting tracing and live code update in the same manner as before.<br><br>A cost effective increase of performance but not the optimal performance.<br><br>Mikael Petterssons mail was very good an explain most of the problems with keeping HiPE.<br>I think the work effort would be even more that 6 man months just to bring it up on par<br>with the interpreted version.</div><div><br></div><div>We plan to present details about the "JIT" in Sept but I hope I have answered most of your questions in this mail.</div><div>Otherwise welcome with more comments and questions </div><div>and of course if there are some more uses of HiPE  or someone who wants to work with HiPE please tell us.<br></div><div><br></div><div>Kenneth Erlang/OTP Ericsson</div></div></div>