Concatenating atoms

Joe Armstrong (AL/EAB) joe.armstrong@REDACTED
Thu Feb 3 12:12:18 CET 2005



> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Thomas Lindgren
> Sent: den 2 februari 2005 12:22
> To: erlang-questions@REDACTED
> Subject: RE: Concatenating atoms
> 
> 
> 
> --- "Joe Armstrong (AL/EAB)"
> <joe.armstrong@REDACTED> wrote:
> 
> >     Speedup = (... above ...) - cycles to do GC
> >             +/- cycles to handle page faults 
> > 		+ cycles spent while system was down because it
> > 	        crashed because the atom table was filled
> > 	      - ...
> > 		+ Speedups gained because I can write more
> > 		  efficient code.
> 
> I started out with looking at the details of your
> estimate (is it speedup or cycles?) but I think the
> core issue is really another one.
> 
> First: I fully support not running out of atoms -- I
> hardly would have asked for atom GC if I didn't. I
> think it's an implementation flaw to have to worry
> about such a thing.
> 
> Second: Whether the proper method of managing atoms is
> atom GC, per-module atom tables with a new data
> representation, or something else, is an engineering
> issue. If your formula above indicates success,
> implement your proposal and see if it was right.
> 

Absolutely - I have no idea which approach is best.
I have a "gut feeling" that a true 64 bit erlang
with two forms of atoms would be best

Short atoms (10 packed characters) which fit into a single
and Long atoms in a local module table with a cached hint
pointer.

Unfortunately (as Björn pointed out) this is not a minor
change - this is a pretty bit re-write before you get to
know the answer.

/Joe


> Best,
> Thomas
> 
> 
> 
> 	
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - You care about security. So do we. 
> http://promotions.yahoo.com/new_mail
> 



More information about the erlang-questions mailing list