[erlang-questions 38] Re: HiPE or native....good results, but confused...

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Sat Mar 26 21:34:07 CET 2011


On Sat, Mar 26, 2011 at 20:56, Evans, Matthew <mevans@REDACTED> wrote:

> My questions, simply put are:
>
> 1) When should HiPE be used?

When the problem is mostly CPU-bound, you can often gain a factor of
2-5 from using HiPE. Beware there is an overhead in switching to/from
HiPE, so if you intermix modules which are HiPE'd and not, you will
often incur a penalty in performance. So it is important to compile
all used modules into native format. That includes stdlib, so beware
of your calls to those.

> 2) When shouldn't HiPE be used?

For some problems, you are not waiting that much on the CPU, but more
time is spent waiting on other subsystems, disk, the database, the
network interface and so on. In those cases, the gains from switching
to HiPE is neglicible. The programs I work on myself hardly benefits
from enabling HiPE. We are talking very little CPU-time spared by
doing it.

(rant coming)

In general, the main reason could be that Erlang is not really built
for CPU-bound computation. With current compiler tech, the fastest
languages are *clearly* the statically typed languages. Yes,
V8+crankshaft is impressive, but it still cannot beat a well-laid-out
Haskell or Ocaml program. Common Lisp can be fast, but you need to
type the program yourself through type hints to the CL compiler (See
CMUCL or SBCL for instance).

You are far better off outsourcing the computationally heavy parts.
There are at least 4 different ways to get that done in Erlang,
(hidden node, port, port_driver, NIF) so you have plenty of options.

Then again, people are too obsessed with performance in the first
place. Often, it is far more important to think and choose the
algorithms and datastructures so they are the right kinds. If you do
this well, then your interpreted program can easily be as fast or
faster than natively compiled counterparts. This is *especially* true
for programs written in weak languages such as C and Java where people
don't have access to abstraction features and hence bake everything in
with the lowest common denominator.

> With native set:
> 20> c(sudoku,[native]).

Try c(sudoku, [native, {hipe, o3}]) to give it a tad more optimization
to work with. It is often faster.

-- 
J.



More information about the erlang-questions mailing list