[erlang-questions] Erlang doesn't suck

Kostis Sagonas kostis@REDACTED
Thu Oct 2 19:51:43 CEST 2008

Hynek Vychodil wrote:
> I would like notice that hipe can cause performance lost for some 
> special cases. There is not simple equation, switch on hipe and you gain 
> some amount of performance surplus. Especially when you have tight loop 
> over not so much complex data structures you can gain big amount of 
> performance.

It would have been much more helpful for the discussion if you presented 
some quantitative results (and preferably code) for your claims.  For 
example, what qualifies as "not so much complex data structures" (by the 
way, have you measured what happens in "complex" ones?), "big amount", 
"performance loss for some special cases" (what's "special" about these 
special cases), etc.

> When you do big amount of inter module calls you gain less 

This is slightly misleading: there is no "bad" treatment of inter module 
calls (other than that dictated by the semantics of hot code loading). 
What does have a non-negligible cost is so called mode-switching calls: 
calling interpreted code from native or vice versa. The simplest way to 
avoid this is to native compile everything. Alas, currently this is not 
so easy to do for standard libraries.  But note that even without 
compiling everything, the speed up from native code is not something to 
disregard so quickly.

For example, if I read Joel's mails correctly he got:

3000 games finished
Elapsed: 181.960007s, Average run time: 0.060653335 seconds (for BEAM)
Elapsed:  62.517129s, Average run time: 0.020839043 seconds (for HiPE)

without compiling any of the OTP libraries.  Joel can correct me if I am 
wrong here.

> and when you do big amount of message passings you can lost some 
> preformance when switch it on.

It would help more if, instead of rather unquantified statements, you or 
somebody else posted an actual application (*) showing a non-trivial 
performance loss when native compiled.  It would at least give us 
something to work and improve upon.


(*) not just a synthetic benchmark

More information about the erlang-questions mailing list