HiPE to be removed in OTP 24?

Grzegorz Junka list1@REDACTED
Sat Jun 20 22:05:31 CEST 2020


OK, there is a bunch of limitations listed in 
http://erlang.org/doc/man/HiPE_app.html#feature-limitations

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?

Grzegorz


On 20/06/2020 13:47, Tristan Sloughter wrote:
> No, tracing is not just part of dbg. Tracing is part of the `erlang` 
> module and there is now `erl_tracer`.
>
> It is common to trace (not using dbg) in production, it is one of the 
> great benefits of Erlang.
>
> I always include Fred's recon library in my releases so I can easily 
> and safely trace in production 
> http://ferd.github.io/recon/recon_trace.html
>
> Tristan
>
> On Sat, Jun 20, 2020, at 02:41, Grzegorz Junka wrote:
>>
>> Thanks Tristan. By tracing do you mean dbg? Isn't tracking also a 
>> niche use anyway?
>>
>> I guess if someone needs tracing for profiling or bug fixing they 
>> still can do that before compiling to HiPE?
>>
>> Grzegorz
>>
>>
>> On 19/06/2020 22:41, Tristan Sloughter wrote:
>>> 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.
>>>
>>> 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.
>>>
>>> Tristan
>>>
>>> On Fri, Jun 19, 2020, at 10:45, Grzegorz Junka wrote:
>>>>
>>>> Hi Kenneth,
>>>>
>>>> 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.
>>>>
>>>> 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?
>>>>
>>>> Regards
>>>>
>>>> Grzegorz
>>>>
>>>>
>>>> On 18/06/2020 08:35, Kenneth Lundin wrote:
>>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> The OTP team is planning to remove HiPE in the OTP 24 release for 
>>>>> the following reasons:
>>>>>
>>>>>   * we plan to introduce a new way of executing Erlang, the "JIT"
>>>>>     described by Lukas Larsson at Code Beam V
>>>>>   * since OTP 22, HiPE is not fully functional (does not handle
>>>>>     all beam instructions and combinations)
>>>>>   * 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.
>>>>>   * The current support for HiPE in the code is a blocker or
>>>>>     creates extra work in our new development.
>>>>>
>>>>> 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.
>>>>>
>>>>> /Kenneth Erlang/OTP, Ericsson
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200620/b714fd11/attachment.htm>


More information about the erlang-questions mailing list