Antoine Pitrou schrieb am 11.08.2018 um 15:19: > On Fri, 10 Aug 2018 19:15:11 +0200 Armin Rigo wrote: >> Currently, the C API only allows Psyco-style JITting (much slower than >> PyPy). All three other points might not be possible at all without a >> seriously modified C API. Why? I have no proof, but only >> circumstantial evidence. Each of (2), (3), (4) has been done in at >> least one other implementation: PyPy, Jython and IronPython. Each of >> these implementation has also got its share of troubles with emulating >> the CPython C API. You can continue to think that the C API has got >> nothing to do with it. I tend to think the opposite. The continued >> absence of major performance improvements for either CPython itself or >> for any alternative Python implementation that *does* support the C >> API natively is probably proof enough---I think that enough time has >> passed, by now, to make this argument. > [...] > That leaves us with CPython and PyPy, which are only two data points. > And there are enough differences, AFAIK, between those two that picking > up "supports the C API natively" as the primary factor leading to a > performance difference sounds arbitrary.
IMHO, while it's not clear to what extent the C-API hinders performance improvements or jittability of code in CPython, I think it's fair to assume that it's easier to improve internals when they are internal and not part of a public API. Whether it's worth the effort to design a new C-API, or at least make major changes to it, I cannot say, lacking an actual comparable implementation of such a design that specifically targets better performance. As it stands, extensions can actually make good use of the fact that the C-API treats them (mostly, see e.g. PEPs 575/580) as first class citizens in the CPython ecosystem. So, the status quo is at least a tradeoff. Stefan _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com