[Numpy-discussion] numpy arrays, data allocation and SIMD alignement

Anne Archibald peridot.faceted@gmail....
Tue Aug 7 00:33:24 CDT 2007


On 07/08/07, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:

> Anne, you said previously that it was easy to allocate buffers for a
> given alignment at runtime. Could you point me to a document which
> explains how ? For platforms without posix_memalign, I don't see how to
> implement a memory allocator with an arbitrary alignment (more
> precisely, I don't see how to free it if I cannot assume a fixed
> alignement: how do I know where the "real" pointer is ?).

Well, it can be done in Python: just allocate a too-big ndarray and
take a slice that's the right shape and has the right alignment. But
this sucks. Stephen G. Johnson posted code earlier in this thread that
provides a portable aligned-memory allocator - it handles the freeing
by (always) storing enough information to recover the original pointer
in the padding space. (This means you always need to pad, which is a
pain, but there's not much you can do about that.) His implementation
stores the original pointer just before the beginning of the aligned
data, so _aligned_free is free(((void**)ptr)[-1]). If you were worried
about space (rather than time) you could store a single byte just
before the pointer whose value indicated how much padding was done, or
whatever.

These schemes all waste space, but unless malloc's internal structures
are the size of the alignment block, it's almost unavoidable to waste
some space; the only way around it I can see is if the program also
allocates lots of small, odd-shaped, unaligned blocks of memory that
can be used to fill the gaps (and even then I doubt any sensible
malloc implementation fills in little gaps like this, since it seems
likely to lead to memory fragmentation). A posix_memalign that is
built into malloc can do better than any implementation that isn't,
though, with the possible exception of a specialized pool allocator
built with aligned allocation in mind.

Anne


More information about the Numpy-discussion mailing list