Joe Jevnik via capi-sig schrieb am 31.07.2018 um 18:26:
One issue I have with the Cython model is that it is very difficult to reason about the computation that is being performed. It is almost impossible to tell when an object will be boxed/unboxed and control for that.
I agree that that's not obvious, in the same way that a C compiler may generate non-obvious code that changes with new versions. Yes, there is a tool chain between you and the CPU instructions.
People commonly use "cython -a" to reason about what Cython generates.
Also, I am not sure which operations will be invoking a lot of Python code or which will be using specialized functions. The behavior also changes from version to version in Cython.
That's called "enhancement" and "optimisation". There is no guarantee that a compilers will never change its capabilities. ;)
When I add an extension I have already decided that the code is performance sensitive* so I want to be able to understand the runtime behavior.
Most people I've seen use Cython actually care more about benchmarks and profiling results. You'd be surprised how often people ask things on mailing lists, stackoverflow, etc., that is obvious from looking at the generated C code.
One of the reasons for that is probably that Cython allows people to write correct and fast C extensions who do not have a C background at all. (Very similar to the way Python allows people to solve their problems with programming who do not have a programming background.)
The auto boxing/unboxing is especially bad because often Cython/C extensions are used when an algorithm is naturally expressed as a loop, and many small object allocations can dramatically affect the performance. I think that for some people, not worrying that much about C type or Python type is a core feature of Cython; however, this makes it harder to use for performance sensitive problems.
These cases will show up in bright yellow in Cython's code annotation view.