<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>OK, there is a bunch of limitations listed in
<a class="moz-txt-link-freetext" href="http://erlang.org/doc/man/HiPE_app.html#feature-limitations">http://erlang.org/doc/man/HiPE_app.html#feature-limitations</a></p>
<p>Erlang tracing is one of them. Are those limitations inherent to
the HiPE compiler, i.e. they can't be fixed, or they are simply
there because they haven't been implemented? Or in other words, is
AOT compilation of Erlang code into native code doomed and JIT is
the only solution to speed it up?</p>
<p>Grzegorz<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 20/06/2020 13:47, Tristan Sloughter
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:90d18ec2-6180-4f15-9b82-3bb49e2a2d42@www.fastmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title></title>
<style type="text/css">
p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
<div>No, tracing is not just part of dbg. Tracing is part of the
`erlang` module and there is now `erl_tracer`.<br>
</div>
<div><br>
</div>
<div>It is common to trace (not using dbg) in production, it is
one of the great benefits of Erlang.<br>
</div>
<div><br>
</div>
<div>I always include Fred's recon library in my releases so I can
easily and safely trace in production <a
href="http://ferd.github.io/recon/recon_trace.html"
moz-do-not-send="true">http://ferd.github.io/recon/recon_trace.html</a> <br>
</div>
<div><br>
</div>
<div>Tristan<br>
</div>
<div><br>
</div>
<div>On Sat, Jun 20, 2020, at 02:41, Grzegorz Junka wrote:<br>
</div>
<blockquote type="cite" id="qt" style="">
<p>Thanks Tristan. By tracing do you mean dbg? Isn't tracking
also a niche use anyway?<br>
</p>
<p>I guess if someone needs tracing for profiling or bug fixing
they still can do that before compiling to HiPE?<br>
</p>
<p>Grzegorz<br>
</p>
<p><br>
</p>
<div class="qt-moz-cite-prefix">On 19/06/2020 22:41, Tristan
Sloughter wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6b9a5aeb-a818-49f8-840f-70a16f36f96b@www.fastmail.com">
<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="qt-qt" style="">
<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 class="qt-qt-moz-cite-prefix">On 18/06/2020 08:35,
Kenneth Lundin wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOzgw91uH8j3uvXksznPWoYa_U6nyiujAOEtoU_ZvG0+KRDuOA@mail.gmail.com">
<div dir="ltr">
<h4 style="color:rgb(0, 0,
0);font-family:sans-serif;font-size:13px;"><span
class="qt-qt-gmail-mw-headline"></span><br>
</h4>
<p
style="margin-top:1em;margin-right:0px;margin-bottom:1em;margin-left: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-top:1em;margin-right:0px;margin-bottom:1em;margin-left: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-top:0.3em;margin-right:0px;margin-bottom:0px;margin-left:1.5em;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left: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-top:1em;margin-right:0px;margin-bottom:1em;margin-left: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>
</blockquote>
</blockquote>
<div><br>
</div>
</blockquote>
</body>
</html>