[erlang-questions] Re: Shared/Hybrid Heap

Morten Krogh <>
Thu Nov 4 14:49:53 CET 2010


Hi

I agree with Paulo and others with the same view. It is like Erlang 
wants to solve the concurrency problems twice.
First by splitting things up into processes and then by having the 
processes use immutable data.
The message passing processes are enough to secure consistency, if the 
messages themselves are fully copied.

The rationale for mutable data is of course mostly performance in space 
and time. But actually in some cases the code is even nicer with mutable 
data.

Here is a simple test between the process dictionary and a dict.

-module(hash).
-compile(export_all).

insert(0) ->
   ok;
insert(N) ->
   put(N,N),
   insert(N-1).

dinsert(D, 0) ->
   ok;
dinsert(D, N) ->
   D2 = dict:store(N, N, D),
   dinsert(D2, N-1).


1> timer:tc(hash, dinsert, [dict:new(), 3000000]).
{481300522,ok}
2> timer:tc(hash, insert, [3000000]).
{658345,ok}

Exceptions should of course not occur with mutable data, but mutavble 
data is mostly suited for "databases", where all operations
should be well tested "stored procedures".

The clojure transients seem interesting. I just don't follow how they 
can have high performance without copying the data to start with.
Suppose we start with map

M1

then
M2 = M1
M2 transient, do stuff, persistent.

M3 = M2.
M3 transient, do stuff, persistent.

M4 = M1.
M4 transient....
M1 transient ....

How can the implemntation keep track of this without disturbing any old 
data, and not have a very high overhead. It seems like all
pieces of data within the structure must be reference counted or 
something like that. I suspect performance of this construct might have 
a very nasty
worst case behaviour. Does anyone know how this is implemented?

Also, I will claim that the by far most common pattern is this
M1
M2 = M1 + small change.
discard M1.

Mutable data structures are made for that.

Cheers,

Morten.













On 11/4/10 12:52 PM, Paulo Sérgio Almeida wrote:
> Hi Robert,
>
> there is a point on which I do not agree; when you say:
>
> On 11/4/10 10:46 AM, Robert Virding wrote:
>
>> - I think that having immutable data even within only one process is 
>> a big win. Having mutable data gives you all the problems of global 
>> data. Immutable data makes it much easier to keep track of what is 
>> happening with your data, which is always a Big Win.
>
> I would say that having mutable data gives us SOME problems, but much 
> LESS than when we have global mutable data.
>
> You are mixing the problems due to:
>
> - global data
> - mutable data
>
> In most languages around we have the nightmare of mutable global data, 
> and the nasty problem of aliasing in object references.
>
> On the other hand in Erlang we have processes that give us locality, 
> but only immutable data in each process.
>
> I (and others) think there is a place for a middle-ground where 
> processes give us locality, allowing a divid-and-conquer of the global 
> problem into simple parts, where the data in a given process is 
> manageable, but where if the algorithm calls for mutable data then we 
> should be able to use it. All the nasty problems of shared memory 
> concurrency (from the programmer's point of view) have already 
> disappeared when we have only per-process mutable data as opposed to 
> global mutable data.
>
> If the data is immutable and only pure functions are used, we have 
> extra benefits, but not always can we afford it, nor is it necessary 
> even for proving correctness. Lot's of classic formal methods stuff 
> with pre-conditions, post-conditions, invariants, Hoare logic, etc, 
> were made for the mutable data world. They become difficult to apply 
> when we have global data and aliasing, but may well be applied when we 
> have just a little local data.
>
> The idea would be to be able to use the many proven algorithms that 
> were created for the imperative sequential world inside each process, 
> and let the process concept a la Erlang deal with the concurrency 
> aspects.
>
> I am not saying it is now practical to add it to Erlang, but that some 
> language in this design spot (actors + local mutable data) makes much 
> sense.
>
> Regards,
> Paulo
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:
>



More information about the erlang-questions mailing list