[erlang-questions] Erlang doesn't suck

[Hynek Vychodil]

On Thu, Oct 2, 2008 at 7:51 PM, Kostis Sagonas <kostis@REDACTED> wrote:

> 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.


My experience coming from first Wide Finder Project, Cedric Beust's
challenge and some other works. I was busy to make some worth synthetic
tests which only is valuable in this array, I think. My observation is that
HiPE gain strongly depend on how task is solved. The fastest BEAM solution
of some nontrivial task is often different from fastest HiPE solution. And
from another point of view, same code compiled using HiPE can vary from 30
times faster to 20% slower. It means, that for some modules from OTP
switching on HiPE can be worth thing (for nondebug environment only) but
only for some modules, not for all.

>
>
>  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.
>
> Kostis
>
> (*) not just a synthetic benchmark
>

Why not synthetic benchmark? My experience is that good synthetic benchmark
is far worthy than "real" application because exactly point where is problem
and which way is faster. I know, it is worthy only for one which understand.
Application benchmarks are usefull just only for marketing and looks good in
PR materials. They allege only how thing works for one special task and it
solution, they tells nothink how it will works for a little bit different
solution or task. Synthetic benchmarks contrary tell how work each component
and you can predict how it will work in different tasks and solutions. It is
harder, may be not so modern, but good engeneering.

-- 
--Hynek (Pichi) Vychodil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081002/2607a4d2/attachment.htm>