[erlang-questions] Did Erlang's grammar change in R16A?

[Björn-Egil Dahlberg]

2013/2/15 Richard A. O'Keefe <ok@REDACTED>

>
> On 15/02/2013, at 11:42 AM, Björn-Egil Dahlberg wrote:
> > 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.
>
> A 'local atom' uses the same space *per reference* as existing atoms do.
> On the heap of the process that created it,
> it holds the bytes of the name plus a 3-word header (32-bit machine
> design).
> The minimum imaginable overhead would be a 1-word header, and that
> would sacrifice some of the efficiency that the 3-word header allows.
>
> Now, I'm looking at an elderly (R12B-5) set of sources (on an elderly
> machine),
> and I see that
>  - a ProcBin requires 6 words on the process's heap
>  - a Binary requires a 3-word header plus the bytes,
>    or on a 32-bit machine, a 4-word header plus the bytes.
> I believe a Binary is the "equivalent heap binary" you are talking about.
>

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


>
> So no, a local atom would NOT require larger heap space than a binary.
> Why did you think it would?
>

+----------+
| size+tag |    boxed object header; see below
+----------+
| hashcode |    a 32-bit hash code
+----------+
| equivrep |    points to Union/Find representative
+----------+
| bytes of |
| name ... |
+----------+

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.

So boxed pointers and unification will fix this memory eventually .. goody,
goody. Geared towards many references one object usecase .. i get it.


> > I agree that atom gc is needed but it shouldn't be an excuse for using
> dynamic atoms instead of binaries.
>
> On the one hand, it isn't.  The EEP is very explicit that the goal is
> _safety_ rather than _convenience_.
>

Good point. Totally agree that safety > convenience.


>
> However, haven't we had enough complaints about the confusion between
> lists of integers
> and strings of text?  Don't you think that a clean distinction between a
> sequence of bits in some
> unknown encoding and a chunk of text in a known encoding is useful?
>

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. =)


>
> > 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).
>
> Oh, if people are bigger than houses, we should all use Perl.
>

I always suspected we could just build extremely tall ivory towers. Though
it would defy physics, it's completely alright since hubris trumps physics.

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.

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!

I don't want one solution. I want many solutions. Choose the best one and
then implement it.

I want to say plenty more but ..

// Björn-Egil .. seriously need sleep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130215/f3d2201f/attachment.htm>