Live data from Hacker News

PyPy.js: Now faster than CPython

rfk.id.au

1–10 of 80 posts

Re: PyPy.js: Now faster than CPython

#2
I 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.

Re: PyPy.js: Now faster than CPython

#4
Am 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" flaunt.

On 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

#5
So 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 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

#6
post #4

Am 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…

According to the author, it is deliberately bait-y:

    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

#8

So 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

#9
post #8

So 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.

Even scalable web-whatever is often IO-bound... of my several apps in production, there's only one where CPU is a serious concern, and I run that one on PyPy. cPython is fine for the others.

Re: PyPy.js: Now faster than CPython

#10
post #2

I 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.

Sadly I agree.

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.

Post reply on HN