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

[Evans, Matthew]

Thanks for the answer. It seems then that there is no negative to using them? Sure, for i/o bound operations you won't see any benefit; but I am assuming there will not be any loss either?

/Rant on

I do agree with the performance issue - with one BIG caveat: At my own company we are up against a certain amount of FUD when it comes to adopting Erlang. It has proven itself many times over: rapid development times, stability, code swapping, scalability, concurrency and all the other good reasons. However, the performance argument is often used as a negative. I feel like smashing my head against a wall knowing that when all is said and done Erlang will still beat (even well  implemented) Java/C/C++ apps of the same complexity (unless they can devote decades of development time in those implementations). But it's often a tough argument to beat. 

What am I saying? Sure, I agree that it's often fast enough and often times faster than many other languages, but to ensure adoption of the language in more domains we should do whatever optimizations we can...

/Rant off


________________________________________
From: Jesper Louis Andersen [jesper.louis.andersen@REDACTED]
Sent: Saturday, March 26, 2011 4:34 PM
To: Evans, Matthew
Cc: erlang-questions@REDACTED
Subject: Re: [erlang-questions 33] HiPE or native....good results, but confused...

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.