3 ms·

The overall speed-up factor (calculated from the numbers in the Benchmarks diagram, geomean of factors) is 1.6, which is much less than the factor 4 achieved wi

by Rochus 5y ago

The overall speed-up factor (calculated from the numbers in the Benchmarks diagram, geomean of factors) is 1.6, which is much less than the factor 4 achieved with PyPy (or the even higher factor claimed by Graal Python). CLI is not very well suited for dynamic languages; as far as I remember the results presented here correspond with Iron Python, which is to be expected based on the proposed concept. EDIT: Yes, indeed pretty much the same factor, see e.g. https://web.archive.org/web/20090324020143/http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP20VsCPy25Perf&referringTitle=IronPython%20Performance https://web.archive.org/web/20090324020143/http://www.codepl...

ksec 5y ago
Assuming zero compatibility problems and a simple drop in, I say 1.6 is pretty damn good from the start. Ruby' drop in YJIT barely managed ~20% speed up.
- joelbluminator 5y ago
  It's at 28.4% so let's make it barely managed ~30% :) https://speed.yjit.org/ https://speed.yjit.org/ I'd give these guys some more time, it's a long project. They're working hard.
- Rochus 5y ago
  > Ruby' drop in YJIT barely managed ~20% speed up. I don't know what they calculated, but if I use the numbers given in the table of https://speed.yjit.org/benchmarks/bench-2021-11-04-071006 https://speed.yjit.org/benchmarks/bench-2021-11-04-071006 I get a factor 1.9 which is much better than the reported 27%.
Twirrim 5y ago
From the details on https://pypi.org/project/pyjion/ https://pypi.org/project/pyjion/ > Goal #1 is explicitly to add a C API to CPython to support JIT compilers. Given the plural compilers, hopefully this means it's going to support multiple JITs, which would be interesting. Choose the right JIT for your particular workload.
- int_19h 5y ago
  That particular statement was written several years ago. In practice, the API in question boils down to letting you plug in your own implementation of PyEval_EvalFrameEx. This has already been added in Python 3.9: https://www.python.org/dev/peps/pep-0523/ https://www.python.org/dev/peps/pep-0523/ As the PEP notes, this is useful for a lot more than just JIT. In particular, modern Python debuggers use it to dynamically patch bytecode to make breakpoints more efficient.

by Rochus 5y ago

ksec 5y ago

Assuming zero compatibility problems and a simple drop in, I say 1.6 is pretty damn good from the start. Ruby' drop in YJIT barely managed ~20% speed up.

joelbluminator 5y ago
It's at 28.4% so let's make it barely managed ~30% :) https://speed.yjit.org/ https://speed.yjit.org/ I'd give these guys some more time, it's a long project. They're working hard.
Rochus 5y ago
> Ruby' drop in YJIT barely managed ~20% speed up. I don't know what they calculated, but if I use the numbers given in the table of https://speed.yjit.org/benchmarks/bench-2021-11-04-071006 https://speed.yjit.org/benchmarks/bench-2021-11-04-071006 I get a factor 1.9 which is much better than the reported 27%.

Twirrim 5y ago

From the details on https://pypi.org/project/pyjion/ https://pypi.org/project/pyjion/ > Goal #1 is explicitly to add a C API to CPython to support JIT compilers. Given the plural compilers, hopefully this means it's going to support multiple JITs, which would be interesting. Choose the right JIT for your particular workload.

int_19h 5y ago
That particular statement was written several years ago. In practice, the API in question boils down to letting you plug in your own implementation of PyEval_EvalFrameEx. This has already been added in Python 3.9: https://www.python.org/dev/peps/pep-0523/ https://www.python.org/dev/peps/pep-0523/ As the PEP notes, this is useful for a lot more than just JIT. In particular, modern Python debuggers use it to dynamically patch bytecode to make breakpoints more efficient.