PyPy.js: Now faster than CPython
rfk.id.au
PyPy.js: Now faster than CPython
1–10 of 80 posts
Re: PyPy.js: Now faster than CPython
#2Re: PyPy.js: Now faster than CPython
#3Re: PyPy.js: Now faster than CPython
#4On a side note: To the PyPy.js authors/devs, great job! Looking forward to playing around with this.
Re: PyPy.js: Now faster than CPython
#5The 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 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.
Re: PyPy.js: Now faster than CPython
#6Am I the only one that considers the title of this very "bait"-y? I mean, if you go on and read the article, it clearly shows that native PyPy is leaps and bounds faster than the JS version. So in essence, it re-iterates what most of us already know... That the PyPy implementation is much faster than the standard CPython one. It's just now we get to "prove" it in JS as well, as if it's some "suck it, python users" fl…
OK OK, I couldn't resist that title but it probably goes a bit far. Let me try for
a little more nuance:
PyPy.js: Now faster than CPython, on a single carefully-tuned benchmark,
after JIT warmup.Re: PyPy.js: Now faster than CPython
#7As the article says, Chrome's performance shows wide variation, even after JIT warmup. It's ranging from 50K/sec to 320K/sec. Bizarre.
Re: PyPy.js: Now faster than CPython
#8So 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…
Re: PyPy.js: Now faster than CPython
#9So 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…
Lots of people use Python for tasks that are not CPU-bound. Scalable web-whatever and scientific computing aren't the whole world.
Re: PyPy.js: Now faster than CPython
#10I 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.
Looking back Python 3 came too late, didn't offer much in terms of an incentive to justify switching to it, divided the community and in the process also left other things people worry about by the wayside -- performance, packaging, better concurrency handling (no not via Tulip or Twisted).
I think, like you point out, many before they decided to sink the time into upgrading to Python 3 to get better unicode support for example, would also take the time to evaluate and go with something else altogether -- Go for example.