[erlang-questions] Building / releasing with HIPE / native

Kostis Sagonas kostis@REDACTED
Wed Apr 2 22:31:23 CEST 2014

On 04/02/2014 08:11 PM, Adrian Roe wrote:
> We’ve been using Erlang in production for quite a few years now and for
> the first time we have a project that really benefits from HIPE / native
> code being turned on (before things have always been fast enough without
> and the benefit of more detailed stack traces etc outweighed any
> performance gains).  We did some benchmarking by compiling single
> modules with HIPE - both in our application code and then going through
> key OTP / Erlang library modules, clearing sticky_directory errors and
> recompiling them one by one with +native.
> Now that it is clear that (for this use case) native / HIPE is the way
> to go, I went to the project’s build box and recompiled Erlang (R16B03)
> from source with
> ./configure --enable-hipe --enable-native-libs
> in the expectation that all libraries would be compiled with +native
> I’ve tried this on OSX, CentOS and Ubuntu all with the same result, so
> it’s clearly me doing something stupid, but I can’t see it.

Can it be that you have not done a 'make clean'?  Note that ./configure 
(with or without flags) does not actually build the system or recreate 
any dependencies.

Can you try the following sequence of commands on your Ubuntu machine 
(unfortunately, I've never tried HiPE on OSX or CentOS to know what is 
its status there) and tell us what happened?

   make clean
   ./otp_build autoconf
   ./configure --enable-native-libs
   make -j

As Sverker suggested, you can find out whether some module, say lists, 
contains native code or not by: code:is_module_native(lists).

Some more info:

  - Note that for better or worse, --enable-native-libs does not build 
the complete set of libraries with native code. Only kernel, stdlib, 
compiler, hipe, syntax_tools and dialyzer are built with native code. If 
your application requires some other modules in native code, you need to 
explicitly compile them to native or change the Makefile of their 
library in a way similar to the Makefiles of these libraries.

  - I would recommend against R16B03 as it is seriously broken in some 
respects.  (This comment is unrelated to native code.)  Use R16B03-1 


More information about the erlang-questions mailing list