On Wed, Oct 21, 2020 at 10:38 PM Matti Picus matti.picus@gmail.com wrote:
On 10/21/20 20:42:02 +1100 Chris Angelico rosuav@gmail.comwrote:
When I go looking for PyPy performance stats, everything seems to be Python 2.7. Is there anywhere that compares PyPy3 to CPython 3.6 (or whichever specific version)? Or maybe it's right there on https://speed.pypy.org/ and I just can't see it - that's definitely possible:)
ChrisA
They are not on the front page. You can find them, but it requires digging around in the Comparison page[0].
Executables: use only "cpython 3.7.6" and any of the "pypy3-jit-64"
Chart type: normal bars
Normalization: cpython3.7.6 or pypy3-jit-64, whichever way makes more
sense to you
- horizontal.
Ah, cool, got it - thanks! My reading of this is that a good few of the benchmarks are coming out firmly in PyPy's favour, but a number of them are still in CPython's favour (including "telco" where PyPy is staggeringly worse for some reason). But a number of the "PyPy is worse" benchmarks are ones that seem less significant - for instance, SQLAlchemy seems to be slower, but if you're using SQLAlchemy, you're probably more concerned about database performance than the CPU cost inside Python.
For some reason the "permalink" feature does not let me share that configuration.
Yeah, there seem to be some issues with that page. The first time I loaded it, the chart was entirely broken - I was looking for the "show chart" button, but it was just that it had errored out for some reason. Still, at least the data's there.
I guess we could switch to emphasizing python3 on the front page, help in updating and reconfiguring Codespeed [1] would be awesome.
If only I had infinite time in the day, I'd love to dive in and help out... It definitely would be worth at least having a quick summary and link somewhere.
ChrisA
On Wed, 21 Oct 2020 22:48:59 +1100 Chris Angelico rosuav@gmail.com wrote:
Ah, cool, got it - thanks! My reading of this is that a good few of the benchmarks are coming out firmly in PyPy's favour, but a number of them are still in CPython's favour (including "telco" where PyPy is staggeringly worse for some reason).
The "telco" benchmark benefits heavily from the C decimal module written and ex-maintained by Stefan Krah.
for instance, SQLAlchemy seems to be slower, but if you're using SQLAlchemy, you're probably more concerned about database performance than the CPU cost inside Python.
I certainly wouldn't say that. The ORM's overhead can be quite important, and SQLAlchemy has dedicated C extensions to mitigate it.
Regards
Antoine.
Antoine Pitrou solipsis@pitrou.net writes:
On Wed, 21 Oct 2020 22:48:59 +1100 Chris Angelico rosuav@gmail.com wrote:
SQLAlchemy seems to be slower, but if you're using SQLAlchemy, you're probably more concerned about database performance than the CPU cost inside Python.
I certainly wouldn't say that. The ORM's overhead can be quite important, and SQLAlchemy has dedicated C extensions to mitigate it.
To be precise, that's unrelated to the ORM layer: the C extension speed ups the handling of the "records" returned by a database driver, so basically a custom mixin between a tuple and a dictionary.
ciao, lele.