[erlang-questions] Erlang shows its slow face!

Tue Nov 16 15:51:55 CET 2010

Interesting thread...I think we can all take the following from this:

1) Write your solution in the "Erlang way", using Erlang's strengths such as spawning parallel processes, also HIPE and NIFS where appropriate.

2) Write your solution efficiently - true in all languages, but especially in Erlang where you could end up doing needless recursion.

3) Erlang isn't always the best language for all problems. Neither is C, C++, C#, Java or any other language. Choose the language, or a mix of languages, that are the best fit your problem.

What I would like to add is that we are trying to get Erlang accepted in a very C/C++ centric development environment. Although time and time again Erlang has shown itself a superior language and development environment for our domain, there is still a big problem in people accepting it. One of the main stumbling blocks is it is perceived to be "slow". People always say "it won't be faster than a C/C++ solution", or "a language written in a VM will always be slow [rolleyes]".

We can argue until we are blue in the face that it will be as good or better when you throw multi-cores in the mix. That there are other advantages including shorter development time, better debugging, redundancy, failure detection etc. But overcoming that initial "speed" bias is a tough sell. I'm not saying there is an answer to this, and I know that the development team is doing their best to make Erlang faster, but we mustn't forget that for many, the "perceived" slowness is one factor that prevents them developing in Erlang.

/Rant over

Matt

-----Original Message-----
From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] On Behalf Of Hynek Vychodil
Sent: Tuesday, November 16, 2010 7:35 AM
To: Edmond Begumisa
Cc: Tony Rogvall; Willem de Jong; Gilberto Carmenate García; erlang-questions@REDACTED
Subject: Re: [erlang-questions] Erlang shows its slow face!

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

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED