<div dir="ltr"><div>Given the highly constrained resources of the OTP team, I would generally expect them to go the other way, and try to hitch their wagons to large systems being built or maintained by others.  The cost of building a de novo high performing JIT and then committing to its ongoing maintenance and development doesn't look, from the outside, like the kind of investment that the OTP team has traditionally made.  Even relatively fundamental subsystems tend to age out for lack of curation.  Is there a new source of funding or staffing which gives the team confidence that they'll be able to make that commitment?</div><div><br></div><div>To ROK's point more specifically -- many new architectures are emerging these days and it's not clear that x86 is the long term winner -- various flavors of ARM, at a minimum, look to be contenders in the near future, at both the consumer and industrial levels.  Clang + co are clearly going to keep getting optimizers and JITs for those environments through the work of thousands of well-incentivized contributors.  What does the BEAMJIT vector look like by comparison?<br></div><div><br></div><div>F.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 19, 2020 at 3:42 PM Tristan Sloughter <<a href="mailto:t@crashfast.com">t@crashfast.com</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"><u></u><div><div>The JIT will support tracing like normal. So even if it was on-par or even a little slower than HiPE I think that is reason enough alone to switch -- and reason enough to have been attempting at alternatives all these years.<br></div><div><br></div><div>JIT could be a solution that makes sense in general usage while HIPE because of its limitations (even before recent OTP changes that diverged from HIPE even more so) meant it was a niche tool. Very useful to those problems it fit, but still niche.<br></div><div><br></div><div>Tristan<br></div><div><br></div><div>On Fri, Jun 19, 2020, at 10:45, Grzegorz Junka wrote:<br></div><blockquote type="cite" id="gmail-m_-7807645118566817951qt"><p>Hi Kenneth,<br></p><p>Thanks to Richard's link I was able to see the presentation about
      JIT and it looks like the team was putting a lot of effort since
      as early as 2012 into JIT. But on none of the benchmarks JIT was
      actually better than HiPE.<br></p><p>I am interested, in what way JIT is better than HiPE that it's
      worth putting the effort into developing something new instead of
      fixing HiPE?<br></p><p>Regards<br></p><p>Grzegorz<br></p><p><br></p><div>On 18/06/2020 08:35, Kenneth Lundin
      wrote:<br></div><blockquote type="cite"><div dir="ltr"><h4 style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px"><span></span><br></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.<br></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:<br></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-bottom:0.1em">we plan to introduce a new way
            of executing Erlang, the "JIT" described by Lukas Larsson at
            Code Beam V<br></li><li style="margin-bottom:0.1em">since OTP 22, HiPE is not
            fully functional (does not handle all beam instructions and
            combinations)<br></li><li style="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.<br></li><li style="margin-bottom:0.1em">The current support for HiPE
            in the code is a blocker or creates extra work in our new
            development.<br></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.<br></p><div>/Kenneth Erlang/OTP, Ericsson<br></div></div></blockquote></blockquote><div><br></div></div></blockquote></div>