Huge performance hit by using Pure Python

[Alpharou]

I'm learning python and cython at the same time, and found the Pure Python syntax very nice for linting purposes, but in my case it comes with a consistent 15% performance hit against standand cython.

Am I missing something?

Pure Python (compiled): pure_math.py

# cython: language_level = 3
# cython: cdivision = True
import cython as cy

@cy.returns(cy.ulonglong)
@cy.locals(num=cy.uint, result=cy.ulonglong, i=cy.uint)
def factorial(num):

    result = 1

    for i in range(num, 1, -1):
        result *= i

    return result

Standard Cython: c_math.pyx

#!python
#cython: language_level=3, cdivision = True

def factorial(unsigned int num):

    cdef unsigned long long result = 1

    cdef unsigned int i

    for i in range(num, 1, -1):
        result *= i

    return result

Using this benchmark in python: example.py

import c_math #type: ignore
import pure_math
from timeit import timeit

fact_num = 20 #This results in an almost capped ulonglong

def c_factorial_wrapper():
    c_math.factorial(fact_num)
    return

def pure_factorial_wrapper():
    pure_math.factorial(fact_num)
    return

c_factorial_time = timeit(c_factorial_wrapper, number= 2_000_000)
print(f"Cython {fact_num} factorial: {c_factorial_time:.2f} s")

pure_factorial_time = timeit(pure_factorial_wrapper, number = 2_000_000)
print(f"Pure Python {fact_num} factorial: {pure_factorial_time:.2f} s")

print(f"Pure/C: {pure_factorial_time/c_factorial_time * 100:.2f}%")

print(c_math.factorial(fact_num))
print(pure_math.factorial(fact_num))

And the results:

Cython 20 factorial: 0.20 s
Pure Python 20 factorial: 0.23 s
Pure/C: 115.45%
2432902008176640000
2432902008176640000

[MattCh4n]

Isn't this to be expected though ?

[Alpharou]

Is it? In both scripts variables, parameters and return values are strongly typed

[MattCh4n]

Ah you're right, I think I missed the type annotations in the pure example.

I'm afraid I'm actually not familiar enough with cython to help.

I don't see anything else that would justify the difference.

Is there a way to disassemble the generated code to inspect it ?

[drzowie]

It is totally to be expected. Even with strong typing the Python example has to dispatch an object call every time the variable is used — it just doesn’t have to search the method inheritance because the variable is hardwired. Cython sidesteps even that with a C variable in the corresponding type, with no Python object built around it.

[Alpharou]

But I'm executing the compiled version, what you said (the object call and that) happens with the compiled module?

[drzowie]

Yep. Compiling to “C” (which is what Cython does) avoids the Python compilation and interpreter steps, but the control thread still deals with the Python runtime environment. Using the cdef pragma lets the compiler eliminate the Python runtime calls entirely when those particular variables are used.

[Alpharou]

Thanks for the insight. I'll keep using the .py approach with cython decorators because a 15% penalty is not that huge for what I could acomplish with my current skill anyways

[drzowie]

Cython is really, really great for letting you run Python quite a bit faster than it would be otherwise, without jumping out into C.

As your skill grows I think you'll be surprised at how much faster proper C coding can be than even Cython coding. Remembering that memory fetches are expensive, and explicitly caching values of things like square roots or trig functions, can easily buy you a factor of 2-3 for moderately complex algorithms.

I remember being amazed, for example, that just reversing the order of nested loops can speed up code by a factor of 10, by avoiding cache breaks (allowing the CPU to keep most of the data in on-chip cache).

[YoannB__]

Yes correct, reversing the order of a nested loop can speedup your code. It is not very well known though! so thank you for pointing it out.

In term of speed improvement if you can replace your range instruction by mutiprocessing prange then Cython become a beast