Does it worth the trouble to support non contiguous array in C extensions ?
Hi, I am about to push in SVN the first version of a small package to compute lpc coefficients and lpc residual. I spent most of the time trying to understand how to handle non contiguous arrays in various parts of the C code... Now, I am wondering: does it really worth the trouble ? I noticed that most of the time, it is even faster (and obviously much easier to code/debug/test, and much more reliable) to just copy the data in a contiguous new array before processing with a C function expecting contiguous array... Is there a general policy regarding thoses issues for scipy ? Is it enough to write simple C extensions expecting contiguous arrays, and converting input to contiguous layout if necessary ? Cheers, David
David Cournapeau wrote:
I am about to push in SVN the first version of a small package to compute lpc coefficients and lpc residual. I spent most of the time trying to understand how to handle non contiguous arrays in various parts of the C code... Now, I am wondering: does it really worth the trouble ? I noticed that most of the time, it is even faster (and obviously much easier to code/debug/test, and much more reliable) to just copy the data in a contiguous new array before processing with a C function expecting contiguous array... Is there a general policy regarding thoses issues for scipy ? Is it enough to write simple C extensions expecting contiguous arrays, and converting input to contiguous layout if necessary ?
Well, I do it the simple way - you usually loose more time figuring out the c-code for general arrays then ensuring contiguous arrays in Python. Premature optimization is bad, so unless your code consumes too much memory or is too slow (in reality), there is no need to wrestle with complex C extensions. just my 2 cents and imho, r. ps: not sure if there is a general policy - people's cases do differ.
David Cournapeau wrote:
Is there a general policy regarding thoses issues for scipy ? Is it enough to write simple C extensions expecting contiguous arrays, and converting input to contiguous layout if necessary ?
That's what I've always done when hand-writing C code. That's essentially what most f2py wrappers do, too, since FORTRAN-77 will *only* deal with contiguous arrays. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
David Cournapeau wrote:
Hi,
I am about to push in SVN the first version of a small package to compute lpc coefficients and lpc residual. I spent most of the time trying to understand how to handle non contiguous arrays in various parts of the C code... Now, I am wondering: does it really worth the trouble ? I noticed that most of the time, it is even faster (and obviously much easier to code/debug/test, and much more reliable) to just copy the data in a contiguous new array before processing with a C function expecting contiguous array... Is there a general policy regarding thoses issues for scipy ? Is it enough to write simple C extensions expecting contiguous arrays, and converting input to contiguous layout if necessary ?
There is no policy. I'm of the opinion that strided arrays are often handled very straightforwardly (except in Fortran) and so try to implement the algorithm on strided arrays when possible. But, if it takes me too much time to think about it, then I just force a contiguous array. There is also the problem of byte-order and alignment that can occur for a general NumPy array. Dealing with these always involves a copy (at least of a chunk at a time). Therefore, at the very least you should request an "aligned" array of a native data-type. Most, just extend that request to a CONTIGUOUS array as-well (either FORTRAN or C-order). I don't see it as a problem except for in memory-limited situations. Lot's of code in NumPy itself forces a contiguous array in order to do the processing. -Travis
participants (4)
-
David Cournapeau
-
Robert Cimrman
-
Robert Kern
-
Travis Oliphant