Does this work at all in Safari? Is Safari's crappy performance of native->js ever going to catch up to FF and Chrome?
PyPy.js: Now faster than CPython
11–20 of 80 posts
Re: PyPy.js: Now faster than CPython
#12So for how long will the python community pretend that performance isn't a problem? (Inb4 "all the intensive parts of my app are written in C", addendum: "my app isn't CPU bound", "we have libraries written in C" ) The interpreters (esp CPython) need some hardcore engineering (like how javascript got V8). Languages that have the same theoretical performance limits of Python are now blowing it out of the water. The st…
>>The stories about teams that were able to go down from N servers to 1 server by switching from Python to Go/Scala/node.js will hurt it in the long run.
concurrency designs and architecture play a greater role than the language , most of the times.
Bottle-necks are often in bad-sync patterns , data-structures or overall designs.
Language plays the role for semantic verification,formal models (for model-comparison...) ,type-system designs , proof systems etc .GIL is just one!
Can't compare language vs another.
After which the buck passes on to underlying implementation but cpython in our discussion is only thrown as a reference implementation and for production grade interpreters we might have to look outside like one by enthought.
However language's built-in patterns to help advertise concurrency is another question altogether.
Re: PyPy.js: Now faster than CPython
#13Does this work at all in Safari? Is Safari's crappy performance of native->js ever going to catch up to FF and Chrome?
test.pystone.main()
Chrome on desktop -- 200K/s
pypy on desktop -- 2000K/s
Re: PyPy.js: Now faster than CPython
#14So for how long will the python community pretend that performance isn't a problem? (Inb4 "all the intensive parts of my app are written in C", addendum: "my app isn't CPU bound", "we have libraries written in C" ) The interpreters (esp CPython) need some hardcore engineering (like how javascript got V8). Languages that have the same theoretical performance limits of Python are now blowing it out of the water. The st…
The large amount of excellent work being done on PyPy would seem to indicate that the Python community does not, in fact, pretend that performance isn't a problem.
Re: PyPy.js: Now faster than CPython
#15So for how long will the python community pretend that performance isn't a problem? (Inb4 "all the intensive parts of my app are written in C", addendum: "my app isn't CPU bound", "we have libraries written in C" ) The interpreters (esp CPython) need some hardcore engineering (like how javascript got V8). Languages that have the same theoretical performance limits of Python are now blowing it out of the water. The st…
> So for how long will the python community pretend that performance isn't a problem?
Which python community are you talking about? Cython, numba, numpy, pypy?
> The stories about teams that were able to go down from N servers to 1 server by switching from Python to Go/Scala/node.js will hurt it in the long run.
Have you followed anything that is going on or just link-bait articles? Nearly everyone that re-implements something in another language uses different paradigms during the re-implementation, because they've learned something from the original implementation. Besides, those articles normally don't discuss any of the opportunity cost of re-invention or the long-term maintenance costs. I'm not saying they can't improve those things, but until you have the TCO over a few years, it's not an accurate portrayal.
Re: PyPy.js: Now faster than CPython
#16I am colourblind and have problems with your choice of red and green for graphs.
Re: PyPy.js: Now faster than CPython
#17I felt it was a grave mistake for Python to direct the community effort into backwards incomparable Python 3, rather than on focusing on the speed (and better profiling instrumentation) of Python 2 (perhaps adding a standard JIT compiler). As a result, had our company started now, we would have written our Twisted server in C or Go instead of Python like we did.
Did you consider PyPy? It kinda works and it kinda focuses effort on being a faster replacement.
Re: PyPy.js: Now faster than CPython
#18So for how long will the python community pretend that performance isn't a problem? (Inb4 "all the intensive parts of my app are written in C", addendum: "my app isn't CPU bound", "we have libraries written in C" ) The interpreters (esp CPython) need some hardcore engineering (like how javascript got V8). Languages that have the same theoretical performance limits of Python are now blowing it out of the water. The st…
The large amount of excellent work being done on PyPy would seem to indicate that the Python community does not, in fact, pretend that performance isn't a problem.
I don't think it is denial per se, but rather mostly inertia. Python has been a victim of CPython's success, in the sense that there is now a huge body of work that is tied to the CPython API. This is a problem for IronPython and Jython, and continues to be a problem for PyPy (though they are making strides to solve it), and it will be a problem for newer projects like Pyston. Numba has sort of skirted the issue by integrating with CPython, but the jury is still out there.
Re: PyPy.js: Now faster than CPython
#19I felt it was a grave mistake for Python to direct the community effort into backwards incomparable Python 3, rather than on focusing on the speed (and better profiling instrumentation) of Python 2 (perhaps adding a standard JIT compiler). As a result, had our company started now, we would have written our Twisted server in C or Go instead of Python like we did.
I feel quite the other way round. They should have cleaned up their language before so many tools where developed on it.
Re: PyPy.js: Now faster than CPython
#20I felt it was a grave mistake for Python to direct the community effort into backwards incomparable Python 3, rather than on focusing on the speed (and better profiling instrumentation) of Python 2 (perhaps adding a standard JIT compiler). As a result, had our company started now, we would have written our Twisted server in C or Go instead of Python like we did.
Did you consider PyPy? It kinda works and it kinda focuses effort on being a faster replacement.
PyPy is good. I wish there was more moment and more _pull_ for it from the main Python team. I feel the big push for the last 3-4 years should have been for PyPy (or performance and tooling in general).
PyPy is good. I wish there was more moment and more _pull_ for it from the main Python team. I feel the big push for the last 3-4 years should have been for PyPy (or performance and tooling in general).
EDIT:
To expand, I remember feeling so excited during the PyCon-s in Chicago and then Atlanta. Unladen Swallow was making some progress but PyPy was fantastic, great speed improvements. Everyone looked in awe at you guys, and your presentations. We talked about STM and all the great things.
And then...Guido announced in a rather annoyed tone how PyPy will never be a part of main Python distro and that's that. "Stop dreaming folks". And that made me pretty disappointed.
Then the drumbeat for Python 3.0 started. Unicode, unicode, unicode... it got louder and louder.
The wall of shame for "incompatible" libraries that were not being ported to Python 3.0. Lots of how to migrate and to Python 3 talks. Lots of oh look at the great view iterators.
Things that would make me get off my seat and start porting to Python 3 would be: greenlet integration for low memory, concurrency green threads (gevent and eventlet). Great CPU speed improvement with included PyPy. Notice what is not on the list -- unicode, view iterators and renaming Queue module to queue. Sorry if I am being too sarcastic here, it is because I am bitter about it.
It is also important to realize that Python 2.0 is just very good that it becomes hard for Python 3.0 to beat it. There were not big hairy warts that just bothered me about it. So it isn't that Python 3.0 is bad, it is not, it is just not better enough Python 2.0.