Den 15.07.2010 19:06, skrev Robert Bradshaw: > Yep. If the arrays are large, the speed difference should be > negligible, but there's a huge penalty in object allocation for small > ones. >
Yes, it gets amortized for large arrays. I've seen this when working with PyOpenGL as well. For example looping over glVertex* can suck tremendously, while glDrawArray has the ctypes overhead amortized for large vertex arrays. Tight loops on glVertex* is better done in Cython for that reason. > It sounds like what we need is a non-object-backed array (e.g. a raw > NumPy array struct) where some of the metadata (e.g. type) is carried > around by the compiler rather than at runtime. Yes, but it will be a major task. E.g. Cython has to implement overloaded operators (similar to NumPy), slicing, etc., to get close to what Fortran 95 already does. > The question here is > how to handle memory allocation--is this done manually in Fortran? I > suppose slices could just be structs passed around by value. > Allocatable arrays are garbage collected in Fortan 95 (no specific method is required by the standard). If we allocate to Fortran 95 pointers instead, we also have to manually deallocate. We can also allocate to multiple arrays in one allocate statement; i.e. we only have to check for memory error once, and can amortize the cost of heap allocation. There are also automatic arrays (like C99), and the Fortran RTL can decide to put them on the stack or the heap, depending on size. It is really like using NumPy without the overhead. While far less painful than C, the other niceness of Python is not there. :( So it's common to just use Fortran 95 to crunch numbers, and use scripting from R, S-Plus, Matlab or Python to control it. Sturla _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
