Am Donnerstag, 08. November 2007 16:37:06 schrieb David Cournapeau:
The problem is not F vs C storage: for element-wise operation, it does not matter at all; you just apply the same function (perform_operation) over and over on every element of the array. The order does not matter at all.
Yet Fortran order leads to several times slower operations, see the figures in my original post. :-( This is because the current implementation for at least some of the operations you are talking about are using PyArray_GenericReduce and other similar functions, which are really high level (they use python callable, etc..). This is easier, because you don't have to care about anything (type, etc...), but this means that python runtime is handling all the thing. Instead, you should use a pure C implementation (by pure C, I mean a C function totally independant of
On Nov 9, 2007 12:50 AM, Hans Meine <meine@informatik.uni-hamburg.de> wrote: python, only dealing with standard C types). This would already lead a significant performance leap. Once you do that, you should not see difference between F and C storage, normally.
But what if you have segmented buffers, non aligned, etc... arrays ?
The code I posted should deal with it - by sorting the indices by decreasing stride, I simply ensure that all (source and target) segments are traversed in order of increasing memory addresses. It does not affect segments or alignment.
If you have segmented addresses, I don't think the ordering matters much anymore, for memory access, no ? For example,
All this has to be taken care of,
Right - my "perform_operation(aprime)" step would need to apply the operation on every memory segment.
and this means handling reference count and other things which are always delicate to handle well...
I am not sure that I understand where refcounting comes into play here.
Or you just use the current situation, which let python handle it (through PyObject_Call and a callable, at a C level).
I need to look at the code to see what you mean here. Probably, I have a wrong picture of where the slowness comes from (I thought that the order of the loops was wrong).
As I wrote above, I don't think this is good. A fortran-order-contiguous array is still contiguous, and not inferior in any way to C-order arrays. So I actually expect copy() to return an array of unchanged order.
Maybe this behaviour was kept for compatibility with numarray ? If you look at the docstring, it is said that copy may not return the same order than its input. It kind of make sense to me: C order is the default of many numpy operations.
That is very sad, because Fortran order is much more natural for handling images, where you're absolutely used to index with [x,y], and x being the faster-changing index in memory.
-- Ciao, / / /--/ / / ANS _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion