Allocate N elements

[H. S. Teoh]

On Mon, Jul 15, 2013 at 07:32:37PM +0200, monarch_dodra wrote:
> On Monday, 15 July 2013 at 15:54:57 UTC, bearophile wrote:
> >monarch_dodra:
> >
> >>>But that (of new arrays) is a bad design, it wastes too much
> >>>memory, and I think it should be fixed. In Python this doesn't
> >>>overallocate:
> >>
> >>So what? The only thing you showed, is that minimallyInitialized
> >>doesn't know how much it allocated. If you allocate 513 elements
> >>with malloc, you'll way over allocate too. What's your point?
> >>You'll waste memory either way.
> >
> >I didn't know it, sorry. I forgot.
> >Can we let minimallyInitializedArray know the capacity?
> 
> I'm working on it ;)
> 
> >Regarding the small arrays, so to avoid the memory wasting you
> >need to allocate a larger one and slice it.
> >
> >Bye,
> >bearophile
> 
> One of the problems is that when you want an arbitrarily sized
> allocation, it is usually standard to allocate 2^N in size. While
> this is optimal for "traditional" malloc, it's actually the *worst*
> allocation size you could ask for a GC array with appendable info
> (eg, traditional new) :/

This is wrong. The 2^N size should be applied *after* GC appendable info
(or whatever else bookkeeping info you need) has been accounted for, not
before. If the GC header/whatever requires, say, 16 bytes, then the
ideal array size should be 2^N-16, so that everything fits neatly within
a power of 2. Otherwise you end up with 2^N+16 bytes that are actually
allocated, and it just goes downhill from there.


T

-- 
What do you call optometrist jokes? Vitreous humor.