<div dir="ltr"><div>A problem, cons is a pointer. Tuple is also a pointer. Currently 2 bits are used for such tags, and adding more special cases will need more bits.<br></div><div><br></div><div>Tagged value must have enough bits to hold a whole pointer, so by using the fact that all memory words are 4 (8) byte-aligned, there are only 2 bits available (for compatibility with 32 bit systems) and on 64-bit it could become 3 bit to fit some extra special cases in there. This 3-bit tagging is not implemented in BEAM VM. With existing C code in BEAM VM i am sure it will create a lot of suffering for a person trying to implement it.<br></div><div><br></div><div>Another trick to tag a pointer is to use high bits above 48 or 56 which depending on platform may be unused and on Intel must always be set to 1. This trick is not portable and is not used.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-06-29 14:14 GMT+02:00 Pierre Fenoll <span dir="ltr"><<a href="mailto:pierrefenoll@gmail.com" target="_blank">pierrefenoll@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Has there been some testing / measurements done on the memory saved by introducing a "tuple of 2" tag only for 2-tuples?<div>{ok, Bla} or {error, R} is such a common pattern and "most" machines being 64bits nowadays this should save many times 8 bytes, shouldn't it?</div><div>So we have a tag for lists (cons), a tag for n-sized tuples and tags for other data. How about a tag for a memory structure that's basically [a|b] but which would be understood as {a,b}.</div><div><div><div dir="ltr" class="m_-8693707071099395339gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div><br></div><div>Cheers,</div><span class="HOEnZb"><font color="#888888"><div>-- </div><div>Pierre Fenoll</div></font></span></div><div><br></div></div></div></div><br></div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Fri, 29 Jun 2018 at 10:16, Dmitry Klionsky <<a href="mailto:dm.klionsky@gmail.com" target="_blank">dm.klionsky@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Some numbers <br>
</p>
<p>1> erts_debug:flat_size([a,b]).<br>
4<br>
2> erts_debug:flat_size({a,b}).<br>
3<br>
3> erts_debug:flat_size([a|b]).<br>
2<br>
<br>
</p>
<br>
<div class="m_-8693707071099395339m_-862425632789854890moz-cite-prefix">On 06/29/2018 03:35 AM, Dmytro
Lytovchenko wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>A tuple of 2 elements will take 3 words of memory minimum</div>
<div><a href="http://beam-wisdoms.clau.se/en/latest/indepth-memory-layout.html#tuple-arityval-0" target="_blank">http://beam-wisdoms.clau.se/<wbr>en/latest/indepth-memory-<wbr>layout.html#tuple-arityval-0</a></div>
<div>tuple1 = [ headerWord, element1, element2 ]<br>
</div>
<div><br>
</div>
<div>A cons cell has no header word, so an improper list of 1
element and 2nd element as a tail, just 2 values stored side
to side<br>
</div>
<div>(same as normal list below except that only 1 cons cell is
used, 2 words)</div>
<div>cons1 = [ element1, element2 ]<br>
</div>
<div><br>
</div>
<div>
<div>A proper list of 2 elements will take 2 cons cells, i.e.
4 words of memory minimum</div>
<div>cons2 = [ element2, [] ]<br>
</div>
<div>cons1 = [ element1, cons2 ]<br>
</div>
<div><a href="http://beam-wisdoms.clau.se/en/latest/indepth-memory-layout.html#lists-cons" target="_blank">http://beam-wisdoms.clau.se/<wbr>en/latest/indepth-memory-<wbr>layout.html#lists-cons</a><br>
</div>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2018-06-29 2:23 GMT+02:00 Dmitry
Belyaev <span dir="ltr"><<a href="mailto:be.dmitry@gmail.com" target="_blank">be.dmitry@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>It's a way to reduce memory footprint.</div>
<div><br>
</div>
<div>Tuple of size N is roughly represented in memory as
an array [TupleTag, N, TupleElement1, TupleElement2,
..., TupleElementN].</div>
<div>Compare it to Cons cell representation: [ConsTag,
HeadElement, TailElement] - it saves 1 word per
structure.<br>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="m_-8693707071099395339m_-862425632789854890m_7606740003781037632m_2917007213273080743gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">Kind regards,
<div>Dmitry Belyaev</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Fri, Jun 29, 2018 at 9:50
AM, Karlo Kuna <span dir="ltr"><<a href="mailto:kuna.prime@gmail.com" target="_blank">kuna.prime@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 dir="ltr">dealing with digraph module i have
noticed use of improper lists as representations
of edges: <br>
['$e' | 123]
<div><br>
</div>
<div>is there a good reason to use improper lists
instead of tuple for this and in general </div>
<div>when is a good idea to use improper lists??
(i can't think of example for justified use)</div>
</div>
<br>
______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="m_-8693707071099395339m_-862425632789854890mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
erlang-questions mailing list
<a class="m_-8693707071099395339m_-862425632789854890moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>
<a class="m_-8693707071099395339m_-862425632789854890moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
<pre class="m_-8693707071099395339m_-862425632789854890moz-signature" cols="72">--
BR,
Dmitry
</pre>
</div>
______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>