|
Cython: The best of both worlds
Pdf ko'rish
|
| bet | 10/12 | | Sana | 16.11.2023 | | Hajmi | 410,71 Kb. | | #100091 |
Bog'liq cython ciseLimitations
When compared to writing code in pure Python,
Cython’s primary disadvantages are compilation
time and the need to have a separate build phase.
Most projects using Cython are therefore writ-
ten in a mix of Python and Cython, as Cython
sources don’t need to be recompiled when Python
sources change. Cython can still be used to com-
pile some of the Python modules for performance
reasons.
There is also an experimental “pure”
mode where decorators are used to indicate static
type declarations, which are valid Python and ig-
nored by the interpreter at runtime, but are used
by Cython when compiled.
This combines the
advantage of a fast edit-run cycle with a high
runtime performance of the final product. There
is also the question of code distribution. Many
projects, rather than requiring Cython as a de-
pendency, ship the generated .c files which com-
pile against Python 2.3 to 3.2 without any modi-
fications as part of the distutils setup phase.
Compared to compiled languages such as Fortran
and C, Cython’s primary limitation is the limited
support for shared memory parallelism. Python
is inherently limited in its multithreading capa-
bilities, due to the use of a Global Interpreter
Lock (GIL). Cython code can declare sections as
only containing C code (using a nogil directive),
which are then able to run in parallel.
How-
ever, this can quickly become tedious. Currently
there’s also no support for OpenMP programming
in Cython. On the other hand, message passing
parallelism using multiple processes, for instance
through MPI, is very well supported.
Compared to C++, a major weakness is the lack
of built-in template support, which aids in writ-
ing code that works efficiently with many differ-
ent data types. In Cython, one must either repeat
code for each data type, or use an external tem-
plating system, in the same way that is often done
for Fortran codes. Many template engines exists
for Python, and most of them should work well
for generating Cython code.
Using a language which can be either dynamic
or static takes some experience. Cython is clearly
useful when talking to external libraries, but when
is it worth it to replace normal Python code with
Cython code? The obvious factor to consider is
the purpose of the code – is it a single exper-
iment, for which the Cython compilation time
might overshadow the pure Python run time? Or
is it a core library function, where every ounce of
speed matters?
It is possible to paint some broad strokes when
it comes to the type of computation considered.
Is the bulk of time spent doing low-level number
crunching in your code, or is the heavy lifting done
through calls to external libraries? How easy is it
to express the computation in terms of NumPy
operations?
For sequential algorithms such as
equation solving and statistical simulations it is
indeed impossible to do without a loop of some
kind. Pure Python loops can be very slow; but
the impact of this still varies depending on the
use case.
|
| |
