[erlang-questions] Erlang shows its slow face!

[Hynek Vychodil]

On Sun, Nov 14, 2010 at 5:50 PM, Edmond Begumisa
<ebegumisa@REDACTED> wrote:
> Hynek,
>
> A few comments...
>
>> When Erlang implementation is faster than C implementation *is* badly
>> written even it can be for maintainability or haste reason. C++ is
>> another beast
>
> I disagree. Quick example...
>
> 1. Write a "well-written" web-server in Erlang, the "Erlang way"
> (lightweight-weight concurrency, message passing).
> 2. Write a "well-written" web-server in C/C++, the "C/C++ way"
> (mulit-threading, shared-memory).
>
> See which is faster. Or, you could save yourself some time and look at
> Apache + Yaws. I wouldn't describe either of these as badly written. But the
> performance difference is undeniable.
>

Why I should write C/C++ web-server in "C/C++ way" (mulit-threading,
shared-memory)? Is dumbness included in using C? I can write C
web-server using libevent for example. I can use kernel poll. I can do
all this cool stuff as Erlang does and I can overperform Erlang using
its own weapons. I can do it better and tune for this particular case
and will be better. I can but if I should or would is another
question. Keep in mind that Erlang VM itself is written in C.

>> You can also do tricks in C which you can't in Erlang.
>
> And you can do tricks in Erlang that you can't do in typical C (e.g easy
> parallelism with little change to code as evidenced on this thread.)

Everything what I can do in Erlang I can do in C, principally.
Opposite is not true. Keep in mind that Erlang VM itself *is* written
in C.
>
>> Can you write k/v store which
>> is able do 200 millions of look up operations per second on one 2.4GHz
>> i5 core?
>
> Something is getting lost here. I go back to the promises a language makes.
> In delivering on those promises, priorities have to be set and compromises
> made. The language user has to weight these.
>
> C/C++ gives us pointers (amongst other things). The language makes great
> sacrifices to give us pointers (like garbage collection and debugability) so
> we can create insanely efficient data structures. When the benefits of
> pointers far outweigh the trade-offs, the choice is clear.
>
> Erlang gives us high concurrency (amongst other things). The Erlang team
> made great sacrifices to give us insanely efficient and scalable
> concurrency. When the benefits of this far outweigh the trade-offs the
> choice is clear.
>
> I see few areas where these benefits/trade-offs overlap. The choice is
> usually very clear. In cases where overlapping does occur, there are various
> ways of using both.
>
> - Edmond -
>
>
I would not argue using only one language for everything. Did I? As I
have written slight down in mine reply, I'm surprised by Erlang HiPE
compiler work. It performs surprisingly well and I would not expect
many orders of magnitude improvement by rewriting to C. I would not
say it would be even ten times unless I would try, but I bet it would,
if I pay enough effort.

I would argue that Erlang with NIFs gives you ultimate tool. Erlang
and C are not enemies, they don't fight themselves, they makes prefect
pair for almost all purposes.

>
> On Sun, 14 Nov 2010 22:32:42 +1100, Hynek Vychodil <hynek@REDACTED>
> wrote:
>
>> On Sun, Nov 14, 2010 at 11:55 AM, Tony Rogvall <tony@REDACTED> wrote:
>>>
>>> On 14 nov 2010, at 10.17, Hynek Vychodil wrote:
>>>
>>>
>>>
>>> Good idea but it seems that native (HiPE) compiler does this
>>> optimization for you when you keep staying in one module. (I also
>>> keeps exporting only main function. It can possibly take effect here
>>> also.) In BEAM it gives you 50% performance gain. Anyway Erlang is not
>>> right tool for this job. You should use NIF if performance matter.
>>>
>>> pythag4(N) when is_integer(N) -> pythag4(N,1).
>>>
>>> I have implemented several small Erlang programs that beat "native" C
>>> code.
>>> Most of the time the C programs where badly/hastily written, but that is
>>> the
>>> point ;-)
>>> You must select the algorithm and the implementation wisely, and of
>>> course
>>> use the golden rule "Make it work, then make it fast". I would add, if it
>>> is
>>> needed.
>>> This does not imply that you should write your program unnecessary slow
>>> to
>>> start with!
>>> Any how. A couple of months ago I implemented the AKS algorithm in
>>> Erlang.
>>> The AKS algorithm is a deterministic primality test algorithm
>>> (http://en.wikipedia.org/wiki/AKS_primality_test)
>>> I benchmarked this implementation with an implementation in C++.
>>> I was shocked: The Erlang version was about 5 times faster, NOT using
>>> obvious parallelism.
>>> In this case I would suspect that garbage collection is the major
>>> contributor! The implementation use
>>> a lot of temporary polynomials intermediate results. A copy collector
>>> does
>>> the trick.
>>> /Tony
>>>
>>>
>>>
>>> "Have run Make so many times I dunno what's installed anymore"
>>>
>>
>> When Erlang implementation is faster than C implementation *is* badly
>> written even it can be for maintainability or haste reason. C++ is
>> another beast. Pun intended. I have similar experience to you but when
>> I found that Erlang implementation is faster then I would look how is
>> it possible and you are right, usually it is memory issue. Anyway
>> every time you can do same tricks as Erlang does but you will end up
>> with "half and error prone implementation of Erlang". You can also do
>> tricks in C which you can't in Erlang. Can you write k/v store which
>> is able do 200 millions of look up operations per second on one 2.4GHz
>> i5 core? Anyway HiPE compiler does very good work here. If I count it
>> correctly pythag3 and pythag4 does about hundred millions checks per
>> seconds. Very good result I think.
>>
>>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>



-- 
--Hynek (Pichi) Vychodil

Analyze your data in minutes. Share your insights instantly. Thrill
your boss.  Be a data hero!
Try GoodData now for free: www.gooddata.com