"Shared heaps can scale well and eliminate the need to copy data on message sends."<div><br></div><div>The advantages seem obvious, but ... with cache-per-core, there will be copying anyway: into the core's data cache. Immutable data is nice, because you don't have to worry so much cache coherence.  But how many CPU architectures are mutability-aware, at least at the right level?</div>
<div><br></div><div>Copying a data structure is also an opportunity to construct a "fresh" data structure that's relatively unfragmented. Lower fragmentation of data structures would make cache fetches more efficient, and cache hits hits more likely, for the receiver.</div>

<div><br></div><div>Probably most Erlang code would faster with a shared heap, but some code might slow down -- maybe by a lot. Putting certain smarts in Send might help: e.g., if the receiving process isn't ready to run, copy; if it is ready, just pass the pointer to shared memory. I'm sure lots more strategies might be devised. And I'm about equally sure they'll all have their own limits and pitfalls.</div>

<div><br></div><div>-michael turner</div><div><br><div class="gmail_quote">On Wed, Jun 1, 2011 at 4:20 PM, Tony Arcieri <span dir="ltr"><<a href="mailto:tony.arcieri@gmail.com" target="_blank">tony.arcieri@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>On Tue, May 31, 2011 at 5:01 PM, Jack Moffitt <span dir="ltr"><<a href="mailto:jack@metajack.im" target="_blank">jack@metajack.im</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>Could you elaborate a bit on the reason why you'd prefer a shared</div>
heap? I was under the impression that individual heaps were one of the<br>
ways Erlang achieved soft real-time performance. Is CPU power enough<br>
improved (or garbage collectors) since Erlang made that decision that<br>
it's no longer worth it?</blockquote><div><br></div></div><div>Erlang has to copy terms whenever they're sent in a message, aside from the exceptions noted earlier regarding binaries. With a shared heap, sending messages could be done by reference instead of actually copying data between process heaps.</div>



<div><br></div><div>There are realtime (and even hard realtime) garbage collectors in the Java world which use a shared heap. Azul systems with 768 cores and 500GB+ heaps managed to keep GC pauses in the 10-20ms range, albeit with hardware memory barriers. Perhaps commodity x64 chips will get them at some point in the future as the number of CPU cores continues to grow.</div>



</div><div><br></div><div>Shared heaps can scale well and eliminate the need to copy data on message sends.</div><br>--<br><font color="#888888">Tony Arcieri<br><br>
</font><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>