Introduction

[Ulf Wiger]

Den 2005-09-07 19:40:14 skrev chandru  
<chandrashekhar.mullaparthi@REDACTED>:

>> Q. [Things in the world don't share data]
>>    Doesn't this make the program's inefficient ?
>>    In C programs we have shared data among various threads ?
> One of the design rules when using erlang is that you should first
> write code which solves your problem elegantly. Then you should
> measure the performance to see if it meets your requirements. If it
> does, who cares if it is inefficient. If it doesn't, then you tweak
> your implementation to share data using some built in components such
> as ETS and improve your performance. Sharing data is *bad* - repeat
> this mantra until you believe it

Actually, as the Erlang compiler and runtime system grow ever more
sophisticated, it may become evident that not allowing explicit
data sharing at the programmer level may *improve* performance
rather than hurting it. Take the (experimental) "shared heap"
for example, where all message passing between processes is done
by passing pointer references. True, there is still "copy-on-write",
but even at this point, you'd have to be a pretty expert C
programmer to have the same degree of sharing together with
the same degree of concurrency.

It is not at all uncommon to see Erlang programs outperform C/C++
programs when a lot of concurrency is called for. As Erlang takes
care of the really scary stuff (managing pointers and avoiding
thrashing data structures), the programmer can focus on the
more interesting problem of selecting the right algorithms for the
job.

/Uffe
-- 
Ulf Wiger