CODEWITHSUNDEEP
pythonjupyter-notebooknumba
nyenyu
nyenyu

Reputation: 79

Compiling abs() in numba is slower than normal python function

This is all was programmed in jupyter notebook, however i didn't find different results in a "normal" terminal/idle work space. I found that running this function:

def __difference(a,b):
    return abs(a,b)

Is consistently faster than:

@jit(nopython=True)
def __difference_numba(a,b):
    return abs(a,b)

The function compiled and this is the output of __difference_numba.inspect_types() (my inputs are two floats in both cases):

__difference_numba (float64, float64)
--------------------------------------------------------------------------------
# File: <ipython-input-50-f6f52d4cccbf>
# --- LINE 1 --- 
# label 0

@jit(nopython=True)

# --- LINE 2 --- 

def __difference_numba(a, b):

# --- LINE 3 --- 
#   a = arg(0, name=a)  :: float64
#   b = arg(1, name=b)  :: float64
#   $0.1 = global(abs: <built-in function abs>)  :: Function(<built-in function abs>)
#   $0.4 = a - b  :: float64
#   del b
#   del a
#   $0.5 = call $0.1($0.4, kws=[], vararg=None, args=[Var($0.4, <ipython-input-50-f6f52d4cccbf> (3))], func=$0.1)  :: (float64,) -> float64
#   del $0.4
#   del $0.1
#   $0.6 = cast(value=$0.5)  :: float64
#   del $0.5
#   return $0.6

return abs(a-b)#np.abs(a - b)

=============================================================================

Code using timeit to time functions:

Cell defining parameters (I tried different numbers):

#test parameters
a=5.0
b=-2.5

Cell for testing numba implementation and results:

%%timeit
#test numba

__difference_numba(a,b)

239 ns ± 6.03 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

Cell for testing normal python implementation and results:

%%timeit
#test python

__difference(a,b)

156 ns ± 0.823 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

Upvotes: 2

Views: 1337

Answers (1)

JoshAdel
JoshAdel

Reputation: 68722

I believe what you are seeing is the overhead of dispatching into the numba code (rather than necessarily the speed of the compiled abs function) since the work being done in the function is so trivial.

Normally you wouldn't separate a trivial call like that into a function, although calling _difference_numba from within another numba-jitted function might be inlined by the compiler. Either way, you need to stay in the numba code longer than the overhead to begin seeing performance differences between pure python code and numba-jitted code. Calling back and forth across the numba/python boundary like this isn't going to overcome the overhead.

Upvotes: 5

Related Questions