So does this mean we can allocate a chunk of 63, put it into the 60-63
bucket, then get it when we ask for a chunk of size 59, then put it back
into the 56-59 bucket, then ask for a chunk of size 55, then put it back
into the 52-55 bucket, and then...?


On Wed, Apr 9, 2014 at 8:00 PM, Nathaniel Smith <njs@pobox.com> wrote:

> Well, it definitely needs a comment at least :-)
>
>
> On Wed, Apr 9, 2014 at 7:36 PM, Julian Taylor <notifications@github.com>wrote:
>
>> In numpy/core/src/multiarray/ctors.c:
>>
>> > +     * very simplistic small memory block cache to avoid more expensive libc
>> > +     * allocations
>> > +     * consists of several buckets of pointers with a minimum size of
>> > +     * (idx + 1) * BUCKSZ bytes
>> > +     * entry 0 contains pointers to 1-3 byte blocks
>> > +     * entry 1 contains pointers to 4-7 byte blocks
>> > +     * entry 2 contains pointers to 8-11 byte blocks
>> > +     * ...
>> > +     */
>> > +    npy_uintp idx;
>> > +    if (sz % BUCKSZ == 0 || sz == 1) {
>> > +        idx = (sz / BUCKSZ);
>> > +    }
>> > +    else {
>> > +        idx = (sz / BUCKSZ) + 1;
>> > +    }
>>
>> yes because one cache bucket only contains pointers of a minimum size so
>> the allocation needs to chose one bucket higher if the size is not
>> divisible by the granularity.
>> E.g. if you put a pointer of size 7 into the cache, it goes into bucket 1
>> (4-7 bytes), retrieving a pointer of size 7 needs to get it from bucket 2
>> (8-11 bytes) as bucket 1 does may contain a right pointer but there is no
>> guarantee for that.
>>
>> this allows to store larger pointers with constant time lookup without
>> wasting more than 3 bytes per pointer, though maybe its an unnecessary
>> complication.
>>
>> —
>> Reply to this email directly or view it on GitHub<https://github.com/numpy/numpy/pull/4606/files#r11451122>
>> .
>>
>
>
>
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
>



-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org