Re: Common allocation sizes for Lua

[Thomas Harning <harningt@...>]

On Sep 11, 2008, at 4:26 AM, David Jones wrote:

> If you're suffering performance problems that you believe are due to  
> memory allocation then plug in another memory allocator.  Such as  
> dlmalloc.  Do NOT write your own.
>
> If you're still suffering performance problems and you are  
> absolutely sure that it is the memory allocator, then better start  
> reading some papers.  Start here: http://www.memorymanagement.org/ 
> bib/ and here: http://www.cs.kent.ac.uk/people/staff/rej/gc.html .
>
> If your summary of Boosts' memory pool template class is correct,  
> then they had better start reading some papers too.
No performance problems at all.  Just looking to see if there's  
another use for what I plan on putting together.

Thinking over what I summarized as what happened, it turns out I got  
it mostly wrong... In trying to digest what needed to be done, I only  
thought out the case of data-size < ptr.  A union will certainly not  
work here... now I see why they did LCM.... and why the ugly case  
looks like it does.

Target usage-- Note: Pools allocated for single data-types
	Certain data items are expected to either be allocated/deallocated  
frequently (esp if no arrays of objects needed) or would like fast  
deterministic time
	OR it's highly beneficial that their memory can be dumped (optionally  
[if 1 element only] destructed w/ a function)

You can also get some other bonuses for normal use, such as locality/ 
etc.

Basic assumptions made:
*	Arrays may not have padding... otherwise most assumptions will not  
work (sizeof array / sizeof element != num elements)
*	Block memory allocator will allocate blocks properly aligned such  
that the returned ptr will be aligned for (at least) a single element  
of any data-type <= the size requested.. ex: alloc(128) good enough  
for double, float, etc since they're all < 128... not necessarily good  
enough for a 200-byte object.

Ascii-drawing of an ugly case
	sizeof(T)         == 5
	sizeof(void*)     == 3
	sizeof(size_type) == 1

LCM(3,1)   == 3
LCM(5,3,1) == 15

Individual unit-chunk....
size  void* T
-----------+--------
1     3    |5
1     (12) | -- (10) left over
1          |
-----------|
1     3    |
1          |
1          |
-----------|
1     3    |
1          |
1          |
-----------|--------

In the normal case... such as a struct { void* ptr, int x, char z }
	The compiler will pad it out such that in an array of them, the  
accesses are aligned...
Ex: AMD64
	sizeof(that T) == 16
	sizeof(void*)  == 8
	sizeof(size_t) == 8
LCM = 16 -- perfect!