HiPE to be removed in OTP 24?

[Kenneth Lundin]

Following up my own post.
We have got a lot of questions and comments regarding this post and this is
an attempt to summarize and answer most of them.

On Thu, Jun 18, 2020 at 10: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.
>
This is not a choice between HiPE and the new way of executing Erlang, the
"JIT". We will introduce our "JIT" anyway.
The question is about who is using HiPE and if there is someone that wants
to commit to a lot of work getting HiPE in shape and keep it there.

## Reported uses of HiPE ##

So far we have heard of 2 uses of HiPE, one with OTP 21.3 and one with
OTP 18.
Both are very special cases and the claimed speedup of 100 times in the OTP
18 case must have another explanation than only the difference between
interpreted or native code. Maybe an unfortunate effect of GC, etc.
normally the absolute best you can expect from HiPE is 10 times faster than
the interpreted variant (for a specific function with a perfect fit for the
optimizations done in HiPE).

## Why implement a new JIT instead of continuing with HiPE? ##

- There are a number of issues with HiPE very well described by Mikael
Pettersson
- The JIT the OTP team have developed is a simple solution that gives good
performance improvements for a small work effort.
- All JITs are not the same, the previous experiments that Lukas mentions
in his talk has been tracing JITs generating native code for the hot spots.
We have learned a lot from those JIT experiments and that is why we
now will introduce a JIT that is very simple, it does not need a register
allocator and other optimizations.
What we now call "JIT" is rather a new way of executing beam instructions,
so it is an integral part of the Erlang VM and everything about execution
is 100% equivalentto the interpreted variant (except speed) so all tests
can be reused as is.

## Is an AOT compiler like HiPE doomed for Erlang? ##

No but HiPE in its current form need a major work effort to get in shape
with the rest of the system as Mikael Pettersson written in his excellent
answer.


## More questions about the new way of executing Erlang, also called the
"JIT". ##

Q: Why is there only support for X86-64 in the first version?

We must start with something and X86-64 happens to be the most used
platform.
More processors like ARM will come later and current way of interpreting
will still be supported for all architectures.
So there will not be fewer architectures supported than we have today.

The "JIT" is rather a new way of executing beam instructions which is a
super simple translation to native code.
We begin with support for X86-64 because we must begin with something and
don't want to wait until we have support for all CPU architectures before
we release this.
The "ordinary" beam threaded code interpreter will still be available for
all platforms.

The cost for implementation and maintenance of the "JIT" is low  which
means that we can handle it with the current team.
We estimate the cost of implementing the "JIT" to much less than fixing
HiPE and it will be easier to maintain since
it will be 100% equivalent to  the interpreter. Another important property
of the JIT is that .beam files will still
be target independent.
LLVM or corresponding technology is not needed since there are no compiler
optimizations going on.
When it comes to compiler optimizations we focus on the Erlang compiler and
how to generate "optimal"
sequences of beam instructions.

The new "JIT" will not have a negative impact on the possibility to run
Erlang where low power consumption is important because:
1. The current interpreter will still be around supporting all
architectures.
2. The JIT is just working extra during load time (and very little at that)
and has no overhead in a system that is up and running.
   The JIT is excuting less CPU instructions per BEAM instruction, which
must be power saving.

The main thing with the "JIT" is not that it give better performance than
HiPE for all cases. It will give a
significantly better performance while still being low cost to implement
and maintain. It will take the same platform
independent .beam files and just run, no differences for the users.
Supporting tracing and live code update in the same manner as before.

A cost effective increase of performance but not the optimal performance.

Mikael Petterssons mail was very good an explain most of the problems with
keeping HiPE.
I think the work effort would be even more that 6 man months just to bring
it up on par
with the interpreted version.

We plan to present details about the "JIT" in Sept but I hope I have
answered most of your questions in this mail.
Otherwise welcome with more comments and questions
and of course if there are some more uses of HiPE  or someone who wants to
work with HiPE please tell us.

Kenneth Erlang/OTP Ericsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200624/65ab5552/attachment.htm>