Calling numpy max function within cython code slower than embedding code for finding max in a numpy array

[Ajay Ummat]

I benchmarked cython code (with 2d array compute: 10000 * 2000 + numpy max function on a numpy array for every i,j):

- code with numpy max function: 156268.701077 msecs

- code with no numpy max: 2903.28001976 msecs

Was wondering why using numpy max function on numpy object is slower. Does this has to do with the switching between dynamic interpreter & static compiled code? Is it true in general for any numpy function?

I am beginner cython user and would love to understand the inner workings of it. Additionally I found that cython has a tremendous speed-up with respect to Numba for my codes as well! Thanks!!

 

[Jake Vanderplas]

On Thu, Jun 20, 2013 at 1:32 PM, Ajay Ummat <ajay...@gmail.com> wrote:

Was wondering why using numpy max function on numpy object is slower. Does this has to do with the switching between dynamic interpreter & static compiled code? Is it true in general for any numpy function?

Exactly.  Every numpy function is a Python function, so it is executed dynamically and will add a lot of overhead within loops.  For faster math functions within loops, you should use the c versions available within libc.math

   Jake

I am beginner cython user and would love to understand the inner workings of it. Additionally I found that cython has a tremendous speed-up with respect to Numba for my codes as well! Thanks!!

 

--
 
---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Chris Barker - NOAA Federal]

On Jun 20, 2013, at 4:21 PM, Jake Vanderplas <jak...@gmail.com> wrote:

 this has to do with the switching between dynamic interpreter & static compiled code? Is it true in general for any numpy function?

Exactly.  Every numpy function is a Python function, so it is executed dynamically and will add a lot of overhead within loops.

I'm not sure it's quite that simple. IIUC, the OP is calling:

np.max(a_big_array)

That's going to have a bit of overhead, but should be small for a large array. 

Perhaps it's because numpy is computing strides for an nd array, whereas in cython you can type it as 2d.

If you post the code, it may be more clear what's going on.

-CHB

[Sturla Molden]

On 20.06.2013 22:32, Ajay Ummat wrote:
> I benchmarked cython code (with 2d array compute: 10000 * 2000 + numpy
> max function on a numpy array for every i,j):
> - code with numpy max function: 156268.701077 msecs
> - code with no numpy max: 2903.28001976 msecs
>
> Was wondering why using numpy max function on numpy object is slower.
> Does this has to do with the switching between dynamic interpreter &
> static compiled code? Is it true in general for any numpy function?

1. There is a Python overhead involved in the function call to np.max.
(Cython does not remove that.)

2. If you know the array is contiguous, Cython can generate faster C
code for indexing than NumPy ufuncs.


Sturla

[Daπid]

On 21 June 2013 01:21, Jake Vanderplas <jak...@gmail.com> wrote:
> On Thu, Jun 20, 2013 at 1:32 PM, Ajay Ummat <ajay...@gmail.com> wrote:
> Exactly. Every numpy function is a Python function, so it is executed
> dynamically and will add a lot of overhead within loops. For faster math
> functions within loops, you should use the c versions available within
> libc.math

I always thought that was what cimport numpy was for, but it looks I
was mistaken. So, there is no way one could include numpy calls in the
cython layer?

Thanks.

David.

[Chris Barker - NOAA Federal]

On Fri, Jun 21, 2013 at 3:46 AM, Daπid <david...@gmail.com> wrote:

>> Exactly. Every numpy function is a Python function, so it is executed
>> dynamically and will add a lot of overhead within loops. For faster math
>> functions within loops, you should use the c versions available within
>> libc.math
>
> I always thought that was what cimport numpy was for, but it looks I
> was mistaken.

"cimport numpy" imports the numpy.pxd file -- declarations of numpy
functions, contants, what have you. This lets you use cython to do
_some_numpy stuff with direct C calls, etc.

> So, there is no way one could include numpy calls in the
> cython layer?

of course you can -- but they will still be pyton function calls, just
like most of Cython code.

IN theory, you could set things up so that cython could call, for
instance, np.max() directly without the python function caling
overhead, but chances are that would buy you nothing significant --
it's the work being done in that function that takes the time, not the
call itself (for any but trivially small arrays).

As for the OP's case, we haven't seen the code, but I suspect Sturla
is right -- np.max() takes longer than a cython loop that does the
same thing because np.max() is written to accommodate the general case
of strided nd-arrays -- a little more overhead in the iteration
through all the elements, and since the actual comparison is trivial,
the iteration overhead is significant.

-Chris

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris....@noaa.gov

[Sturla Molden]

On 21.06.2013 18:43, Chris Barker - NOAA Federal wrote:

> "cimport numpy" imports the numpy.pxd file -- declarations of numpy
> functions, contants, what have you. This lets you use cython to do
> _some_numpy stuff with direct C calls, etc.

Only the Numpy C API functions, not NumPy's Python API.

Sturla

[Sturla Molden]

On 21.06.2013 18:43, Chris Barker - NOAA Federal wrote:

> As for the OP's case, we haven't seen the code, but I suspect Sturla
> is right -- np.max() takes longer than a cython loop that does the
> same thing because np.max() is written to accommodate the general case
> of strided nd-arrays -- a little more overhead in the iteration
> through all the elements, and since the actual comparison is trivial,
> the iteration overhead is significant.

I think the OP's main problem was the Python overhead, not the extra
indexing overhead. But it is important to be aware of both.

Sturla