Anne Archibald wrote:
> 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
>
> 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 ?).
Visual Studio seems to offer a counter part
On 07/08/07, David Cournapeau <[EMAIL PROTECTED]> 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 alloca
Anne Archibald wrote:
>
> I have to agree. I can hardly volunteer David for anything, and I
> don't have time to implement this myself, but I think a custom
> allocator is a rather special-purpose tool; if one were to implement
> one, I think the way to go would be to implement a subclass of ndarra
On 06/08/07, David Cournapeau <[EMAIL PROTECTED]> wrote:
> Well, when I proposed the SIMD extension, I was willing to implement the
> proposal, and this was for a simple goal: enabling better integration
> with many numeric libraries which need SIMD alignment.
>
> As nice as a custom allocator mig
Lisandro Dalcin wrote:
> On 8/3/07, David Cournapeau <[EMAIL PROTECTED]> wrote:
>> Here is what I can think of:
>> - adding an API to know whether a given PyArrayObject has its data
>> buffer 16 bytes aligned, and requesting a 16 bytes aligned
>> PyArrayObject. Something like NPY_ALIGNED, ba
On 8/3/07, David Cournapeau <[EMAIL PROTECTED]> wrote:
> Here is what I can think of:
> - adding an API to know whether a given PyArrayObject has its data
> buffer 16 bytes aligned, and requesting a 16 bytes aligned
> PyArrayObject. Something like NPY_ALIGNED, basically.
> - forcing da
Nicely done Travis. Working code is always better than theory. I copied your
interface and used the brute-force, non-numpy approach to construct the
pivot table. On the one hand, it doesn't preserve the order that the entires
are discovered in as the original does. On the other hand, it's about 40%
Lars Friedrich wrote:
> Hello,
>
> thanks for your comments. If I got you right, I should look for a
> FFT-code that uses SSE (what does this actually stand for?), which means
> that it vectorizes 32bit-single-operations into larger chunks that make
> efficient use of recent CPUs.
>
> You mentio
>
> MKL is from Intel (free as in beer on Linux and for academic purpose I
> think, but of course, you should check whether this applies to you).
AFAIK, the MKL is free for non-commercial purposes under Linux only, and
there is a special license for academics.
Matthieu
__
Lars Friedrich wrote:
> Hello,
>
> thanks for your comments. If I got you right, I should look for a
> FFT-code that uses SSE (what does this actually stand for?), which means
> that it vectorizes 32bit-single-operations into larger chunks that make
> efficient use of recent CPUs.
>
> You mentio
Lars Friedrich wrote:
> Hello,
>
> thanks for your comments. If I got you right, I should look for a
> FFT-code that uses SSE (what does this actually stand for?), which means
> that it vectorizes 32bit-single-operations into larger chunks that make
> efficient use of recent CPUs.
>
>
http://
12 matches
Mail list logo
