Mailman 3 February 2019 - cython-devel

Performance comparison with CPython for attribute/item access
by Stefan Behnel Feb. 17, 2019

Feb. 17, 2019

Hi, Raymond Hettinger wrote a micro benchmark script for comparing the performance of basic attribute and item access patterns across Python versions and build configurations, so I tested the initially committed version with Cython. https://github.com/python/cpython/blob/master/Tools/scripts/var_access_benc… Results are below, comparing Cython (master) to CPython 3.8 (master), and also disabling all C-time optimisations via the "CYTHON_*" macros (no-opt). Some things to note: - Most operations in Cython are around 30-50% faster. - C-level things like local variables are not measurable in Cython. - Setting class variables is very slow in both CPython and Cython, probably for the same (unknown) reason, maybe the method cache or so. https://bugs.python.org/issue36012 - The dict version check for Python globals is worth it. Disabling it in Cython with "-DCYTHON_USE_DICT_VERSIONS=0" slows down the lookup by 5x (2.2ns -> 10ns). - Disabling PyList optimisations with "-DCYTHON_USE_PYLIST_INTERNALS=0" slows down the "list_append_pop" benchmark by 5x (21ns -> 102ns). - The list append/pop optimisations seem to slow down non-lists unproportionally, for deques by 3x compared to CPython. That seems worth improving. Stefan CPython 3.8 (63fa1cfece) ======================== Variable and attribute read access: 5.4 ns read_local 6.0 ns read_nonlocal 15.7 ns read_global 23.5 ns read_builtin 23.1 ns read_classvar_from_class 20.4 ns read_classvar_from_instance 31.5 ns read_instancevar 25.4 ns read_instancevar_slots 23.8 ns read_namedtuple 34.5 ns read_boundmethod Variable and attribute write access: 6.2 ns write_local 6.7 ns write_nonlocal 19.1 ns write_global 113.2 ns write_classvar 44.6 ns write_instancevar 33.0 ns write_instancevar_slots Data structure read access: 23.5 ns read_list 24.0 ns read_deque 25.6 ns read_dict Data structure write access: 26.0 ns write_list 27.1 ns write_deque 32.0 ns write_dict Stack (or queue) operations: 61.6 ns list_append_pop 53.9 ns deque_append_pop Timing loop overhead: 0.4 ns loop_overhead Cython 3.0a0 (f1eaa9c1f) ======================== Variable and attribute read access: 0.2 ns read_local 0.2 ns read_nonlocal 2.2 ns read_global 0.2 ns read_builtin 13.8 ns read_classvar_from_class 11.1 ns read_classvar_from_instance 21.3 ns read_instancevar 15.5 ns read_instancevar_slots 13.6 ns read_namedtuple 21.5 ns read_boundmethod Variable and attribute write access: 0.2 ns write_local 0.1 ns write_nonlocal 13.0 ns write_global 92.9 ns write_classvar 29.6 ns write_instancevar 16.1 ns write_instancevar_slots Data structure read access: 4.0 ns read_list 4.3 ns read_deque 16.5 ns read_dict Data structure write access: 4.3 ns write_list 6.4 ns write_deque 21.4 ns write_dict Stack (or queue) operations: 20.7 ns list_append_pop 155.4 ns deque_append_pop Timing loop overhead: 0.1 ns loop_overhead Cython 3.0a0 (no-opt) ===================== Variable and attribute read access: 0.2 ns read_local 0.2 ns read_nonlocal 15.6 ns read_global 0.2 ns read_builtin 16.1 ns read_classvar_from_class 12.1 ns read_classvar_from_instance 21.9 ns read_instancevar 16.3 ns read_instancevar_slots 14.5 ns read_namedtuple 23.8 ns read_boundmethod Variable and attribute write access: 0.2 ns write_local 0.2 ns write_nonlocal 14.2 ns write_global 99.4 ns write_classvar 35.0 ns write_instancevar 22.4 ns write_instancevar_slots Data structure read access: 5.7 ns read_list 6.1 ns read_deque 21.1 ns read_dict Data structure write access: 8.4 ns write_list 8.4 ns write_deque 24.0 ns write_dict Stack (or queue) operations: 66.4 ns list_append_pop 75.1 ns deque_append_pop Timing loop overhead: 0.2 ns loop_overhead

1 1

Re: [Cython] [cython-users] Should Cython 3.0 still have Python 2.x support?
by Stefan Behnel Feb. 16, 2019

Feb. 16, 2019

Robert Bradshaw schrieb am 11.02.19 um 16:54: > On Fri, Feb 8, 2019 at 12:45 PM Stefan Behnel wrote: >> Robert Bradshaw schrieb am 06.02.19 um 10:37: >>> Realistically, I think that if we don't support 2.7 in the 3.0 >>> release, we're signing up for maintaining a long-lived 2.9 branch, >>> which I'd like to avoid. >> >> Although the same would probably apply to Cy3.0 if we cut Py2.7 support in >> Cy3.1. Some Linux enterprise distributions will support Py2.7 for another >> 6-10 years or so. It doesn't feel like switching now or in a couple of >> months makes a big difference on that front. > > I think the changes in Cy2.9 and Cy3.0 are bigger than those between > Cy3.0 and Cy3.1, and in particular there are user-facing changes (e.g. > the language level default) that make it harder for users of Cython to > support both from a single codebase (though for that one I suppose one > could manually set a directive). Ok, lets's keep Py2 support for Cy3.0. Why have one reason to celebrate when you can have two? Stefan

1 0

Cython 0.29.5 fixes a crash for cpdef functions
by Stefan Behnel Feb. 9, 2019

Feb. 9, 2019

Hi everyone, Cython 0.29.5 was released with an important bug fix for extension types that have "cpdef" methods. If they get subclassed by Python classes that do not define additional attributes (or anything that would require them to have an instance `__dict__`), then calling the cpdef-methods repeatedly triggers a crash in the optimised code in 0.29.x that checks for subclass overrides. The issue was reported here: https://github.com/cython/cython/issues/2823 It's a new issue in the 0.29.x series and only appears under Python 3.6 and later, so older versions were not affected. Everyone using 0.29.x with cpdef methods is encouraged to upgrade. Stefan

1 0

Should Cython 3.0 still have Python 2.x support?
by Stefan Behnel Feb. 2, 2019

Feb. 2, 2019

[CC-ing cython-devel, but please keep the discussion on cython-users] Hi all, we were recently asked on the bug tracker [1] when Cython is planning to end its support for Python 2.x, so I'd like to get some more user opinions on this. We are planning to release Cython 3.0 this year [2], with some well selected backwards incompatible changes and a tiny bit of feature reduction, so … wouldn't that be a good time to cut off even more of the old cruft? Should we really have a release that supports the CPython versions 3.8 (~October) all the way back to 2.7? Or would Python 2.7-3.7 be enough in 0.29, and only Python 3.[345]-3.8+ for Cython 3.0? (*) Remember, removing legacy support as part of a new release doesn't change anything about the old releases, so they will still keep working for everyone who wants Python 2.x support, even long after January 1st, 2020. As I wrote in the ticket, I would not object to anyone backporting fixes to 0.29 that we implement for newer releases, and continuing with point releases for it whenever there is something to release in the legacy maintenance branch. (And as long as there aren't any breaking changes in Py3.8, 0.29.x might also work there.) What do you think? Stefan [1] https://github.com/cython/cython/issues/2800 [2] https://github.com/cython/cython/milestone/58 (*) We currently support Py3.3+ for Py3. Py3.4 is expected to reach its EOL in March, but still seems worth supporting for another while. Not sure about 3.3, probably an "as long as it doesn't hurt" case.

1 1

Cython 0.29.4 fixes exception handling for division by zero
by Stefan Behnel Feb. 1, 2019

Feb. 1, 2019

Hi all, I just released Cython 0.29.4 with an important bug fix(*) for division operations that involve constant numerators. If the denominator turns out to be zero at runtime, it could happen that no ZeroDivisionError gets raised, and instead an arbitrary result returned. https://github.com/cython/cython/issues/2820 Upgrading is recommended to restore correctness. Stefan (*) You could argue that support for division by zero is a rather oustanding feature, but … I think the surprise factor outweighs the coolness here.

1 0