[erlang-questions] Erlang shows its slow face!

[Edmond Begumisa]

Hello Hynek,

> I can do
> all this cool stuff as Erlang does and I can overperform Erlang using
> its own weapons

I can't :)

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

For me, the opposite is true.

That settles it then! You're a gazillion times a better C programmer than  
I am :) And probably far better than any I've personally met!

Light-weight concurrency, SMP parallelism, soft real-time properties,  
fault-tolerance, hot-code swapping, distribution, etc. My skill-set is  
nowhere near wide enough to implement those things. Actually, from *my* C  
code, those things are damn near impossible! It's quite magical the way  
Erlang brings them to life. And I'd need those things to be able to say  
anything I can do in Erlang I can do in C, principally or otherwise.

My C is just not that good. My knowledge is just not that wide. I rely too  
heavily on the combined effort of others who are much smarter than me.

But I do play a mean blues guitar though! Take that, Erlang team :)

- Edmond -


On Tue, 16 Nov 2010 23:34:51 +1100, Hynek Vychodil <hynek@REDACTED>  
wrote:

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


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/