This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author skrah
Recipients benjamin.peterson, neologix, njs, pitrou, rhettinger, skrah, tim.peters, trent, vstinner, wscullin, xdegaye
Date 2017-10-31.20:57:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20171031205738.GA7005@bytereef.org>
In-reply-to <1509474377.77.0.213398074469.issue18835@psf.upfronthosting.co.za>
Content
> For large allocations, you'll probably be better off implementing your own aligned allocator on top of calloc than implementing your own calloc on top of an aligned allocator. (It's O(1) overhead versus O(n).) And once you're doing that you might want to use the same code for regular allocations too, so that you don't need to keep track of whether each memory block used aligned_calloc or aligned_malloc and can treat them the same... Depends on your exact circumstances.

Yes, but if the whole array is initialized with actual values, then
the memset() overhead is not very large (something like 16% here).

If uninitialized (or very sparse), the overhead is of course gigantic.

What is more, in some crude tests the posix_memalign() performance isn't
that great compared to malloc()/calloc().

C11 aligned_alloc() is also quite a bit faster than posix_memalign() here.

I think you're right that a hand-rolled solution on top of calloc() is
best for my use case.
History
Date User Action Args
2017-10-31 20:57:50skrahsetrecipients: + skrah, tim.peters, rhettinger, pitrou, vstinner, benjamin.peterson, trent, njs, neologix, xdegaye, wscullin
2017-10-31 20:57:50skrahlinkissue18835 messages
2017-10-31 20:57:50skrahcreate