<br><br><div class="gmail_quote">On Wed, Dec 19, 2012 at 8:10 AM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Wed, Dec 19, 2012 at 2:57 PM, Charles R Harris<br>
<<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
><br>
> On Wed, Dec 19, 2012 at 7:43 AM, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
>><br>
>> On Wed, Dec 19, 2012 at 8:40 AM, Henry Gomersall <<a href="mailto:heng@cantab.net">heng@cantab.net</a>> wrote:<br>
>> > I've written a few simple cython routines for assisting in creating<br>
>> > byte-aligned numpy arrays. The point being for the arrays to work with<br>
>> > SSE/AVX code.<br>
>> ><br>
>> > <a href="https://github.com/hgomersall/pyFFTW/blob/master/pyfftw/utils.pxi" target="_blank">https://github.com/hgomersall/pyFFTW/blob/master/pyfftw/utils.pxi</a><br>
>> ><br>
>> > The change recently has been to add a check on the CPU as to what flags<br>
>> > are supported (though it's not complete, I should make the default<br>
>> > return 0 or something).<br>
>> ><br>
>> > It occurred to me that this is something that (a) other people almost<br>
>> > certainly need and are solving themselves and (b) I lack the necessary<br>
>> > platforms to test all the possible CPU/OS combinations to make sure<br>
>> > something sensible happens in all cases.<br>
>> ><br>
>> > Is this something that can be rolled into Numpy (the feature, not my<br>
>> > particular implementation or interface - though I'd be happy for it to<br>
>> > be so)?<br>
>> ><br>
>> > Regarding (b), I've written a test case that works for Linux on x86-64<br>
>> > with GCC (my platform!). I can test it on 32-bit windows, but that's it.<br>
>> > Is ARM supported by Numpy? Neon would be great to include as well. What<br>
>> > other platforms might need this?<br>
>><br>
>> Your code looks simple and portable to me (at least the alignment<br>
>> part). I can see a good argument for adding this sort of functionality<br>
>> directly to numpy with a nice interface, though, since these kind of<br>
>> requirements seem quite common these days. Maybe an interface like<br>
>>   a = np.asarray([1, 2, 3], base_alignment=32)  # should this be in<br>
>> bits or in bytes?<br>
>>   b = np.empty((10, 10), order="C", base_alignment=32)<br>
>>   # etc.<br>
>>   assert a.base_alignment == 32<br>
>> which underneath tries to use posix_memalign/_aligned_malloc when<br>
>> possible, or falls back on the overallocation trick otherwise?<br>
>><br>
><br>
> There is a thread about this from several years back. IIRC, David Cournapeau<br>
> was interested in the same problem. At first glance, the alignment keyword<br>
> looks interesting. One possible concern is keeping alignment for rows,<br>
> views, etc., which is probably not possible in any sensible way. But people<br>
> who need this most likely know what they are doing and just need memory<br>
> allocated on the proper boundary.<br>
<br>
</div></div>Right, my intuition is that it's like order="C" -- if you make a new<br>
array by, say, indexing, then it may or may not have order="C", no<br>
guarantees. So when you care, you call asarray(a, order="C") and that<br>
either makes a copy or not as needed. Similarly for base alignment.<br>
<br>
I guess to push this analogy even further we could define a set of<br>
array flags, ALIGNED_8, ALIGNED_16, etc. (In practice only power-of-2<br>
alignment matters, I think, so the number of flags would remain<br>
manageable?) That would make the C API easier to deal with too, no<br>
need to add PyArray_FromAnyAligned.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br>Another possibility is an aligned datatype, basically an aligned structured array with floats/ints in chunks of the appropriate size. IIRC, gcc support for sse is something like that.<br>
<br>Chuck <br></div><br></div>