[erlang-questions] Erlang shows its slow face!

[Edmond Begumisa]

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.

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

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



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/