<div dir="auto"><div>Yes, but it was a very specific case in how we where building a binary. And this was OTP 18.<div dir="auto"><br></div><div dir="auto">We weren't using HiPE at the time and our protocol generator was producing acceptable code. Then a colleague and I decided to test the generator with larger arrays so we marshaled 2048 floating point values (among other things in the protocol message.) It took about 80 ms to create the binary! One thing we noticed was we didn't have +native when compiling. Once we did that, we could build the messages in under 1 ms. So, for this very specific case, it was ~100x faster.</div><div dir="auto"><br></div><div dir="auto">HiPE wasn't giving us 100x across the board. I think, in OTP18, our code stumbled across a use of binaries that HiPE handled much better than the byte-code. As we upgraded to new OTP releases, we didn't bother to see if we could turn off +native. </div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 19, 2020, 10:34 PM Max Lapshin <<a href="mailto:max.lapshin@gmail.com">max.lapshin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You really get 100x speedup with hipe?<br>
<br>
On Fri, Jun 19, 2020 at 8:32 PM Rich Neswold <<a href="mailto:rich.neswold@gmail.com" target="_blank" rel="noreferrer">rich.neswold@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Just thought I’d let you know that HiPE does have its users.<br>
><br>
><br>
> On Thu, Jun 18, 2020, 3:35 AM Kenneth Lundin <<a href="mailto:kenneth@erlang.org" target="_blank" rel="noreferrer">kenneth@erlang.org</a>> wrote:<br>
>><br>
>> 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>
>><br>
>> The OTP team is planning to remove HiPE in the OTP 24 release for the following reasons:<br>
>><br>
>> we plan to introduce a new way of executing Erlang, the "JIT" described by Lukas Larsson at Code Beam V<br>
>> since OTP 22, HiPE is not fully functional (does not handle all beam instructions and combinations)<br>
>> 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>
>> The current support for HiPE in the code is a blocker or creates extra work in our new development.<br>
>><br>
>> 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>
>><br>
>> /Kenneth Erlang/OTP, Ericsson<br>
</blockquote></div></div></div>