<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Adding new layers into existing system is a very attractive tendency which need to be considered with serious cautions.</div><div class=""><br class=""></div><div class="">I think Erlang excels at its simplicity and obvious. Take module:function/arity as an example, we put a list of functions into one module, and that's all, no more layering.</div><div class=""><br class=""></div><div class="">I feel strong similarity between language design and system structure.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Yao</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">在 2020年6月20日，20:08，Valentin Micic <<a href="mailto:v@micic.co.za" class="">v@micic.co.za</a>> 写道：</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">First, my apologies for accidentally sending an empty message (my fingers were moving whilst my brain was farting).</div><div class=""><br class=""></div><div class=""><div class="">I am a late adopter of HiPE — even though I did some testing over years (and, mind you, it was fairly shaky in early days, hence my reluctance to use it in production), it took years before I really found a good reason (or became desperate enough) to “really” use it.</div><div class=""><br class=""></div><div class="">Presuming that something is available and in a good working order, a natural question to ask would be: Why would someone chose *not* to use it?</div><div class=""><br class=""></div><div class="">Usually, I do not like figuring out why anyone does anything — it is a fool’s errand, how can one ever know what motivate others; but if I were to speculate in this manner, I’d say that “abandonment” of HiPE could be a consequence of its tight relationship with Erlang language (and, thus, Erlang compiler). </div><div class=""><br class=""></div><div class="">Approaching the "conclusion” from this direction, and given that HiPE benefits only Erlang (as in Erlang language) community, it may follow that OTP team’s intention behind this (new) iteration of “JIT” was to provide something that may benefit both, Elixir and Erlang communities.</div><div class=""><br class=""></div><div class="">I must say, I was uneasy when I’ve learned about HiPE abandonment, but cannot say that I can see a downside if experiences acquired with HiPE can be improved upon and presented in a way that benefit both communities.</div><div class=""><br class=""></div><div class="">Of course, this might seem entirely unnecessary if you only use Erlang language (as I do). Not so, if you’re using Elixir to make living. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Kind regards</div><div class=""><br class=""></div><div class="">V/</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""></blockquote></div></div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 20 Jun 2020, at 08:39, Richard O'Keefe <<a href="mailto:raoknz@gmail.com" class="">raoknz@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:monospace,monospace">From watching the BEAMJIT video, they *tried* building on top of clang, and that turned out to be a mistake. Then they *tried* building on top of LLVM, and that turned out to be a mistake too. In fact the detours through Clang and LLVM cost so much time that the whole BEAMJIT idea was very nearly shelved sine die.</div><div class="gmail_default" style="font-family:monospace,monospace"><br class=""></div><div class="gmail_default" style="font-family:monospace,monospace">Just because clang & co are getting optimisers &c does not mean that they are getting optimisers that pay off *for Erlang*.</div><div class="gmail_default" style="font-family:monospace,monospace"><br class=""></div><div class="gmail_default" style="font-family:monospace,monospace">By the way, I am sick of the way people credit Java with the idea of JITs.</div><div class="gmail_default" style="font-family:monospace,monospace">The idea goes back to load-and-go systems, via Lisp, Brown's invention of "throwaway compiling" for a BASIC system, to Smalltalk (Deutsch & Schiffman), and Self. Indeed, one issue raised in the video could have been answered by considering Brown's throw-away compiling and the application of that idea in early commercial Smalltalk.<br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 20 Jun 2020 at 12:35, Felix Gallo <<a href="mailto:felixgallo@gmail.com" class="">felixgallo@gmail.com</a>> wrote:<br class=""></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" class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">F.<br class=""></div></div><br class=""><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" target="_blank" class="">t@crashfast.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u class=""></u><div class=""><div class="">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 class=""></div><div class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">Tristan<br class=""></div><div class=""><br class=""></div><div class="">On Fri, Jun 19, 2020, at 10:45, Grzegorz Junka wrote:<br class=""></div><blockquote type="cite" id="gmail-m_5413258387620334439gmail-m_-7807645118566817951qt" class=""><p class="">Hi Kenneth,<br class=""></p><p class="">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 class=""></p><p class="">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 class=""></p><p class="">Regards<br class=""></p><p class="">Grzegorz<br class=""></p><p class=""><br class=""></p><div class="">On 18/06/2020 08:35, Kenneth Lundin
wrote:<br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><h4 style="font-family: sans-serif; font-size: 13px;" class=""><span class=""></span><br class=""></h4><p style="margin: 1em 0px; font-family: sans-serif; font-size: 13px;" class="">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 class=""></p><p style="margin: 1em 0px; font-family: sans-serif; font-size: 13px;" class="">The
OTP team is planning to remove HiPE in the OTP 24 release for
the following reasons:<br class=""></p><ul style="line-height: 1.5em; list-style-type: square; margin: 0.3em 0px 0px 1.5em; padding: 0px; font-family: sans-serif; font-size: 13px;" class=""><li style="margin-bottom:0.1em" class="">we plan to introduce a new way
of executing Erlang, the "JIT" described by Lukas Larsson at
Code Beam V<br class=""></li><li style="margin-bottom:0.1em" class="">since OTP 22, HiPE is not
fully functional (does not handle all beam instructions and
combinations)<br class=""></li><li style="margin-bottom:0.1em" class="">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 class=""></li><li style="margin-bottom:0.1em" class="">The current support for HiPE
in the code is a blocker or creates extra work in our new
development.<br class=""></li></ul><p style="margin: 1em 0px; font-family: sans-serif; font-size: 13px;" class="">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 class=""></p><div class="">/Kenneth Erlang/OTP, Ericsson<br class=""></div></div></blockquote></blockquote><div class=""><br class=""></div></div></blockquote></div>
</blockquote></div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></body></html>