HiPE to be removed in OTP 24?

[Max Lapshin]

You really get 100x speedup with hipe?

On Fri, Jun 19, 2020 at 8:32 PM Rich Neswold <rich.neswold@REDACTED> wrote:
>
> We are not a “primary customer” but HiPE is essential at Fermilab. We have an in-house, protocol code generator that aggressively builds binaries using bitstream comprehensions. We also adjusted our generator to follow hints given from +bin_opt_info. The last time we measured performance between byte-code and HiPE, we found the native code ran 100x faster making Erlang a viable option for our systems.
>
> We’re currently at OTP 21 and have no problem staying there until we feel the JIT performs similarly and supports ARM. I’m building OTP 23 without HiPE on a test system to see if the binary manipulation instructions improved enough that this isn’t an issue.
>
> Just thought I’d let you know that HiPE does have its users.
>
>
> On Thu, Jun 18, 2020, 3:35 AM Kenneth Lundin <kenneth@REDACTED> 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