Evans, Matthew wrote:
>> I hadn't really played with HiPE (native) much, as I was always under the impression that performance gains were negligible. Clearly, for this use case, the gains are far from negligible - a 2x boost is not something to ignore.
>> My questions, simply put are:
>> 1) When should HiPE be used?
Well, my opinion is that you should always try it and decide based on
the performance benefits you get on your application.
Also, in case you were not aware of this there is a configure option
(--enable-native-libs) that compiles some applications (erts, kernel,
stdlib, syntax_tools and dialyzer) to native code.
> 2) When shouldn't HiPE be used?
When you do not get any considerable performance gains from using it.
> 3) What are the disadvantages of using HiPE?
You need more code space, code is currently not unloaded and often you
also lose some precision in the debugging/crash_dump information.
> 4) Shouldn't "team Erlang" be doing more to promote its use?
I will let others reply/comment on this one.
> 5) Are any HiPE changes on the road-map?
The HiPE compiler is pretty stable; the only bug I am aware of is an off
by one error in binary pattern matching which has already been fixed and
the fix will appear on 'dev' soon. (For comparison, incidentally the
R14B02 BEAM compiler also had a bug in binary pattern matching which has
been fixed two days ago.) Such is life, I guess... The only thing to do
about it is to hope that the Erlang community will help by reporting
whatever issues they run across because both the BEAM and the HiPE
compiler developers are currently committed to fixing them.
Besides support, we have developed a PowerPC 64 backend for HiPE which
has not been included to the R14B02 release due to some miscommunication
with the OTP team. Anybody who is interested in it can try it from the
'pu' branch of Erlang/OTP. In addition, we are currently working on an
LLVM backend for HiPE. We'll see what the results will look like.
Kostis