[erlang-questions] Re: Shared/Hybrid Heap

Hynek Vychodil <>
Thu Nov 4 10:40:13 CET 2010


I honestly will put one more point to your list.

On Thu, Nov 4, 2010 at 1:50 AM, Robert Virding
<> wrote:
> This question is much more complex that you would at first realise. Some thoughts (in no specific order):
>
> 1. Shared/hybrid heaps are wonderful BUT:
> - They are more difficult to implement in a real-time environment. Yes, this is a known problem with solutions but the benefits are less than you would expect. Real-time gc costs.
> - They don't port easily to multi-core systems as you suddenly start needing locks and stuff everywhere to control access or have complex schemes to get around this. Which copying doesn't.
>
> For some problems shared heaps are much better, for others much worse.
>
> 2. I would assert that the operations on immutable data structures cost less then you imagine.
>
> 3. From the way you describe it having data structures which are both mutable and immutable would very confusing. You would need to have two sets of operations on them and every application would have to keep track of when to use them.
>
> 4. Mutable data structures give you all the things you want to avoid with global data, especially that they can change under your feet without you knowing about it. Yes, you may have to pass a reference around but it still means that I don't know who can access my bit of data and can change it. Yes, you can stipulate that the program should be well-behaved, but we all know how well that works in real-life in a big system.
>
5. More dragons lies in exceptions and error handling. With immutable
data structures you have transaction memory for "free". To keep
immutable semantic but mutable implementation you have to keep
mutability only in functions which can't fail which add much more
complexity and enables mutability to much less place than is worth
for.

> So while I have said that you don't *need* immutable data to get process isolation, instead you can specify data copying between processes, this does not mean that I recommend having mutable data. Immutable data is so much easier to work with and keep track of.
>
> Robert
>
>
> ----- "Tony Arcieri" <> wrote:
>
>> I agree with this sentiment as well. A pure immutable system gives
>> more
>> optimization options to VM implementers, but as is without the
>> shared/hybrid
>> heaps Erlang doesn't do a good job of leveraging the potential of a
>> purely
>> immutable state system.
>>
>> On Wed, Nov 3, 2010 at 5:35 PM, Ryan Zezeski <>
>> wrote:
>>
>> > On Mon, Oct 18, 2010 at 7:28 AM, Morten Krogh <>
>> wrote:
>> > >
>> > >
>> > > On practical terms, I feel that Erlang some times gives up
>> performance
>> > for
>> > > unnecessary reasons. I am especially thinking about mutability.
>> > > There is no reason to give up mutation within a process which is
>> already
>> > a
>> > > serializer.
>> > >
>> > > code like this
>> > >
>> > > loop(Dict)
>> > >    receive
>> > >    {put, K, V} ->
>> > >        Dict2 = dict:store(K, V, Dict),
>> > >        loop(Dict2)
>> > >    end.
>> > >
>> > >
>> > > is just a performance wise inefficient way of doing
>> > >
>> > > loop(Mut) ->
>> > >    receive
>> > >    {put, K, V} ->
>> > >        put(K,V, Mut),
>> > >        loop(Mut)
>> > >    end.
>> > >
>> > > where Mut is a mutable data structure.
>> > > In the dict exampe, there is a unncecessary work and garbage
>> collection
>> > for
>> > > the functional data structure Dict.
>> > > And you gain nothing, since it is sequential code.
>> > >
>> > >
>> > I think this is a good point.  If you are simply creating a data
>> structure
>> > in _one_ process it should be mutable.  Then when you publish it it
>> becomes
>> > immutable.  I have Clojure's transients in mind.
>> >
>> > http://clojure.org/transients
>> >
>> > *If a tree falls in the woods, does it make a sound?**If a pure
>> function
>> > mutates some local data in order to produce an immutable return
>> value, is
>> > that ok?*
>> > *
>> > *
>> > *
>> > *
>> >
>>
>>
>>
>> --
>> Tony Arcieri
>> Medioh! A Kudelski Brand
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:
>
>



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


More information about the erlang-questions mailing list