<div dir="ltr"><div>Thanks for the detailed and informative answer. In my day to day programming I rarely encounter cases where thinking about memory layout would make much sense. However, the referenced article triggered my curiosity to what level BEAM's implementation could take advantage of this, although I already suspected it would be hard, given Erlang's semantics.<br>
<br></div><div>Apart from binaries/bitstrings, the only thing I could think of that might create a tightly packed data structure, is a tuple of small integers, unless my assumption is false that small integers are unboxed values and tuples, as opposed to lists, directly stores it's elements in Erlang. But then again, even if that would be the case, you still have to unpack these integers from the tuple to do something meaningful with them, so that probably mitigates any advantage of having these integers nicely packed together in a tuple.<br>
<br></div><div>BTW, the referenced article did in fact mention that the described techniques only work in a single threaded environment, but it was sneakily put a way in a side bar of the article ;) :<br><br>"There’s a key assumption here, though: one thread. If you are accessing 
nearby data on multiple threads, it’s faster to have it on <em>different</em>
 cache lines. If two threads try to use data on the same cache line, 
both cores have to do some costly synchronization of their caches."<br><br><br><br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 11, 2013 at 4:03 PM, Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@erlang-solutions.com" target="_blank">jesper.louis.andersen@erlang-solutions.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="im"><br><div class="gmail_quote">On Wed, Dec 11, 2013 at 11:34 AM, Vincent Siliakus <span dir="ltr"><<a href="mailto:zambal@gmail.com" target="_blank">zambal@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>Last night I was reading the following article: <a href="http://gameprogrammingpatterns.com/data-locality.html" target="_blank">http://gameprogrammingpatterns.com/data-locality.html</a>.
 It gives a nice overview about the importance of data locality for 
performance critical code these days. So I started wondering how much of
 this applies to my favourite runtime (I say runtime because I use 
Elixir more often than Erlang lately).</div></blockquote></div><br></div>It is hard to say exactly how a given piece of code will execute on a system. The general consensus the latter years has been optimizing for data locality and limiting DRAM access speeds things up. This is mostly due to how caches work and so on. Clock cycles today are almost "free". The Erlang BEAM VM is quite pointer-heavy in the sense that we usually don't pack data that tightly and prefer to use a tree-like term structure. The advantage of the approach is it gives a better and easier path to handle persistence and immutability, which are cornerstones of writing large functional programs.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">Furthermore, you have relatively little control over the concrete memory layout of data in BEAM, making it harder to pack data tightly. It makes it hard to apply those kinds of tricks in the article. The "structural zoo" of Erlang is not that strong and due to the language being dynamic--it is limited how much representational control you have. If you want to exploit memory layout, there are better languages out there.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">However, the article is written for single-core imperative code. One advantage you have on the BEAM is that small process heaps tend to stay in cache. This makes their garbage collection and operation faster and it improves locality for the heap. Also, the article completely forgets to touch on the fact that modern systems have multiple cores. In such a system, immutability and copying can help drive up parallelism, which in turn means you can get more cores to do productive work. It is not as clear-cut as one might believe. Multiple cores changes everything, especially with respect to data mutation which become more expensive.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>
</blockquote></div><br></div>