Le 31/07/2018 à 18:25, Victor Stinner a écrit :
2018-07-31 18:03 GMT+02:00 Antoine Pitrou firstname.lastname@example.org:
For example, PyPy uses different memory allocators depending on the scope and the lifetime of an object. I'm not sure that you can implement such optimization if you are stuck with reference counting.
But what does reference counting have to do with memory allocators exactly?
I repeated what I heard from other developers and made my own guess. But it seems like you disagree. I think that it's better that you ask directly authors of other Python implementations like PyPy or Pyston their mood on the C API and if they see any opportunity to make their runtime faster by modifying the current C API.
Why don't you go and ask them? You are the one making claims such as "changing the C API will allow making CPython 2x faster", and trying to back them with allusions about how PyPy got 5x faster than CPython, as if there was an obvious connection between the C API and PyPy's performance.
I'm not interested in finding arguments in favour of your position. That's your job, not mine.
How can we make CPython 2x faster? Why everybody, except of PyPy, failed to do that?
Because PyPy spent years working full time on a JIT compiler. It's also written in (a dialect of) Python, which helps a lot with experimenting and building abstractions, compared to C or even C++.
Ok. But PyPy doesn't support natively the C API, and cpyext is still causing troubles to PyPy.
I'm sorry, but it seems you have a hard time sticking to a precise topic. Are you talking about PyPy's performance, or about how to make CPython faster, or are you talking about issues with cpyext?
If you want to make cpyext's life better, I would recommend asking the cpyext authors for suggestions, instead of trying to second-guess their wishes.
If we modify CPython to make similar changes than PyPy, we will hit the same issues.
I don't understand what this sentence means, sorry.