<br><br><div class="gmail_quote">2013/2/15 Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 15/02/2013, at 11:42 AM, Björn-Egil Dahlberg wrote:<br>
> If I'm reading [EEP 20] correctly: a local atom would actually require a larger heap space than an equivalent heap binary .. which is a feat all by itself.<br>
<br>
A 'local atom' uses the same space *per reference* as existing atoms do.<br>
On the heap of the process that created it,<br>
it holds the bytes of the name plus a 3-word header (32-bit machine design).<br>
The minimum imaginable overhead would be a 1-word header, and that<br>
would sacrifice some of the efficiency that the 3-word header allows.<br>
<br>
Now, I'm looking at an elderly (R12B-5) set of sources (on an elderly machine),<br>
and I see that<br>
 - a ProcBin requires 6 words on the process's heap<br>
 - a Binary requires a 3-word header plus the bytes,<br>
   or on a 32-bit machine, a 4-word header plus the bytes.<br>
I believe a Binary is the "equivalent heap binary" you are talking about.<br></blockquote><div><br></div><div>A heap binary has a header + size + data, minimum three words (Thats two words and data by your counting). This will only take two words (one word + data) in an upcoming release after R16B, sub-binaries and proc-bins will also loose one word of memory. along with some other stuff i won't go into</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So no, a local atom would NOT require larger heap space than a binary.<br>
Why did you think it would?<br></blockquote><div><br></div><pre style="margin-top:15px;margin-bottom:15px;padding:6px 10px;border:1px solid rgb(204,204,204);font-size:13px;font-family:Consolas,'Liberation Mono',Courier,monospace;background-color:rgb(248,248,248);line-height:19px;overflow:auto;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;color:rgb(51,51,51)">
<code style="margin:0px;padding:0px;border:none;font-size:12px;font-family:Consolas,'Liberation Mono',Courier,monospace;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">+----------+
| size+tag |    boxed object header; see below
+----------+
| hashcode |    a 32-bit hash code
+----------+
| equivrep |    points to Union/Find representative
+----------+
| bytes of |
| name ... |
+----------+
</code></pre><div>This made me count 1, 2, 3, 4 boxes, i.e. minimum 4 words. 4 > 3 .. I wanted to answer your rhetorical(?) question just so we could launch this discussion on a complete tangent to outer space.</div><div>
<br></div><div>So boxed pointers and unification will fix this memory eventually .. goody, goody. Geared towards many references one object usecase .. i get it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> I agree that atom gc is needed but it shouldn't be an excuse for using dynamic atoms instead of binaries.<br>
<br>
</div>On the one hand, it isn't.  The EEP is very explicit that the goal is _safety_ rather than _convenience_.<br></blockquote><div><br></div><div>Good point. Totally agree that safety > convenience.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, haven't we had enough complaints about the confusion between lists of integers<br>
and strings of text?  Don't you think that a clean distinction between a sequence of bits in some<br>
unknown encoding and a chunk of text in a known encoding is useful?<br></blockquote><div><br></div><div>Is that the argument for atoms as strings or the argument against it? Yet another way to represent a string? Granted, it's already there but I won't sway from my beliefs. =)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Besides, if locals atoms are larger than binaries why would you use atoms. (I might be wrong about the size though .. didn't look that hard).<br>
<br>
</div>Oh, if people are bigger than houses, we should all use Perl.<br></blockquote><div><br></div><div>I always suspected we could just build extremely tall ivory towers. Though it would defy physics, it's completely alright since hubris trumps physics.</div>
<div><br></div><div>The endgame is the same. A nice syntax, good apis, great performance and a lovely experience. Perl is probably the least lovely I know of.</div><div><br></div><div>So a side note, last I looked at a roadmap with "when will we implement at atom gc?" I think a saw R20-ish. So it is naturally we haven't been thinking about it. Up til now I've been perfectly fine with saying "don't use dynamic atoms. It's bad". Actually I'm perfectly fine by still saying don't create atoms dynamically .. bad! </div>
<div><br></div><div>I don't want one solution. I want many solutions. Choose the best one and then implement it. </div><div><br></div><div>I want to say plenty more but .. </div><div> </div></div>// Björn-Egil .. seriously need sleep