Edit: Why is this being downvoted? Is my statement incorrect or offensive to some people?
IIRC Firefox 3 was the first browser to have what we would call a modern JS engine, with heavy emphasis on JIT compiling. Google Chrome soon followed and V8 dominated the JS perf story.
Python doesn't have such fierce competition of implementations. And besides, it has the "escape hatch" of being able to implement performance-critical code paths as C extensions, which is what heavy-lifting libraries like numpy do.
Python have many competitions, but the language lack some sort of spec and the only reference is CPython.
Node.js uses the V8 engine for JavaScript which isn't just an interpreter - it includes a JIT compiler.
I think when GVR mentions "There's machine code generation in our future" that he is talking about a JIT
Performance has always been a lower-tier priority for cPython and other, faster, implementations (like PyPy) have not seen much mainstream adoption.
Because no FAANG has ever seen CPython performance as a central element of an effort central to the future of the firm, and thrown money at it accordingly.
In a way, it seems like Mark Shannon found someone to take him up on his offer on a plan for speeding up Python.
https://en.wikipedia.org/wiki/Mark_Shannon_(actor)
That mark shannon:
https://github.com/markshannon
He tried to do hotpy in 2011, and trigger the idea of FAT byte code which I believed inspired the FAT python attempt of Victor Stinner.
Now stinner is working on Hpy, dropbox on pyston, instagram on cinder, and pyjion just got a release.
Looks like Python is going to get faster one way or another.
It is always announcements, talks, conferences and if something emerges it is a bit weird like the pattern matching.
Meanwhile the Erlang people quietly produced a JIT without any advertisements.
Because almost everything you've seen as 'working code' started its life as an announcement.
And because to coordinate and discuss future work, there would need to be some announcements.
And because some announcements (based on the persons, e.g. here GvR is involved) or the funding (e.g. here MS is involved) or the specificity (e.g. here 3.10 timeframe is discussed) are more important than others.
>Meanwhile the Erlang people quietly produced a JIT without any advertisements.
Good for them. That's maybe because much fewer care for Erlang (and thus for the advertisements) related to Python (which has a much larger dev base), so the advertisements of the former are posted fewer times and discussed by fewer people.
Er, no, they didn’t, they made plenty of announcements before the release, most of which even made their way to HN.
When you like a tech, knowing people are brewing improved perfs on it is kinky. On Python, the motto has always been "it's fast enough", "if you want perfs, don't use python", "C extensions will solve this", "we don't want to make the main implementation complicated", "python dynamism and GIL make it a hard problem", etc.
So in the python world, it's particularly big news, especially given that previous attempts (gilectomy, unladen swallow, first pyston...) all died.
[1] https://cffi.readthedocs.io/en/latest/index.html [2] https://doc.pypy.org/en/latest/extending.html#cffi [3] https://numba.readthedocs.io/en/stable/reference/pysupported...
- without breaking anyone's code (did that for the print function etc and delayed py3 adoption for a decade but not for the most user requested feature which is speed)
- No large PRs (how a 5x speedup can take place with small patches that no one figured out yet?)
- a small team (not enough money, less risky if they tried to adopt other pypy-esque projects that are more advanced speed wise, a more comprehensive plan that would invite donations, I would certainly give. For this presentation I don't know)
To back up that fact: Python 3.10 will remove long-deprecated features, see issue tracker: https://bugs.python.org/issue41165 and What's new, the Removed section: https://docs.python.org/3.10/whatsnew/3.10.html#removed
The Python 3 debacle is a beautifully worked example of why being backwards compatible is so important, and I can 100% sympathize with them not wanting to go through that again.
Among interpreted languages python is/was one of the faster ones.
NodeJS has similar speed, and in some cases is faster. I don't know any other interpreted language though.
People are also complaining about GIL, but ironically NodeJS is single threaded.
CPython got big because of its relatively decent C-API and glue capabilities. 25% does not make a difference, decent C extensions have speedups in the order of 10-100 times (yes, times, not percent).
If I had a dollar for every time someone proposed a Python speedup ...
Microsoft is reactivating their JIT project for Python as well.
Their talk tomorrow:
"Talk: Restarting Pyjion, a general purpose JIT for Python – is it worth it?"
Well, that's just the thing. Many have tried, many have succeeded, but their work hasn't been upstreamed so adoption is almost nonexistent. This is different. It's finally a mainline project. That's noteworthy, and long overdue given the plurality of proofs-of-concept.
So hopefully the combination of those two can make it work.
So, I take this as a good sign that progress will continue.
It's often the case for end-user applications, but I find that most languages/runtimes tend to get better with time (and work of course !). There's a similar trend with the PHP runtime.
3 packages will be installed:
expat-2.3.0_1
gdbm-1.19_1
python-2.7.18_3
3 packages will be installed:
expat-2.3.0_1
gdbm-1.19_1
python3-3.9.4_1
https://docs.bazel.build/versions/master/skylark/language.ht...
https://github.com/faster-cpython/cpython
Looks like they've also got a repo with some tools for profiling bytecode:
If there's really a 50% general speed boost sitting around in "normal" bytecode optimization work (and having read a decent amount of CPython I believe there could be), that's a criminal amount of energy over the past decade instead wasted dealing with what the type of a codepoint sequence should be named.
PyPy is already a drop-in replacement for CPython with JIT and using a fraction of the memory.
https://dev.nextthought.com/blog/2018/08/cpython-vs-pypy-mem...
(relevant graphic: https://ibb.co/yV6bN9H )
Thanks, Guido and team!