[petsc-dev] Using multiple mallocs with PETSc

Jed Brown jed at jedbrown.org
Tue Mar 14 16:18:43 CDT 2017


Richard Mills <richardtmills at gmail.com> writes:

> On Tue, Mar 14, 2017 at 1:23 PM, Jed Brown <jed at jedbrown.org> wrote:
>
>> Barry Smith <bsmith at mcs.anl.gov> writes:
>>
>> >> On Mar 13, 2017, at 1:27 PM, Jed Brown <jed at jedbrown.org> wrote:
>> >>
>> >> Satish Balay <balay at mcs.anl.gov> writes:
>> >>> stash the metadata for each allocation (and pointers for corresponding
>> >>> free) in a hash table for all mallocs that we need to track? [this
>> >>> avoids the wasted 'space' in each alloc.]
>> >>
>> >> Sure, but this is just duplicating an implementation of malloc.
>> >
>> >    No it isn't. It is a very thin wrapper around multiple current
>> mallocs.
>>
>> Meh, the proposal has more storage overhead than malloc().
>>
>
> I was bored or something, so I actually looked into how people who want to
> track all the allocations inside a special malloc() do so, and it seems
> that plenty of people use a red-black tree for this (balanced binary tree,
> O(log(n) for search, insert/delete, and tree rearrangement) rather than a
> hash table.  This is getting pretty far down in the weeds... but this would
> have less storage overhead than a hash table.  Just FYI. =)

Tcmalloc has an overhead of 1% for common usage patterns when allocating
8-byte objects.  A tree is much higher overhead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20170314/7370082e/attachment.sig>


More information about the petsc-dev mailing list