I am colourblind and have problems with your choice of red and green for graphs.
Not that it shouldn't be fixed, but have you tried http://www.ryobi-sol.co.jp/visolve/en/ ?
PyPy.js: Now faster than CPython
21–30 of 80 posts
Re: PyPy.js: Now faster than CPython
#22Python in the browser so far is a big disappointment. I still find it a lot easier to just split frontend and backend development. In the future, PyPy.js might become a viable alternative for big browser applications.
Re: PyPy.js: Now faster than CPython
#23I 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 u…
I still don't get the point of using Go instead of PyPy or Cython.
Re: PyPy.js: Now faster than CPython
#24Am 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…
Yes, it is baity and the article clearly admits to it. But it also clearly has PyPy and CPython in the title which is important. I don't read as "suck it python users" but as "great news, python users: if your code runs okay in CPython today, you could be running it in the browser with decent performance soon!". If anything it's a "suck it JS, we can now run real languages in the browser!"
Re: PyPy.js: Now faster than CPython
#25Earlier quoted context omitted.
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 u…
I still don't get the point of using Go instead of PyPy or Cython.
Cython is really impressive, but it produces incredibly huge C files, which then compile into enormous binaries. So it's not terribly suitable when code size matters.
Re: PyPy.js: Now faster than CPython
#26Does this work at all in Safari? Is Safari's crappy performance of native->js ever going to catch up to FF and Chrome?
Yes, Safari has been working on an LLVM-based JIT called FTL. It now outperforms v8 on almost all asm.js benchmarks,
http://arewefastyet.com/#machine=12&view=breakdown&suite=asm...
That's not in release versions of Safari yet, it was just enabled on trunk. But it will make Safari very competitive once more.
Re: PyPy.js: Now faster than CPython
#27Am 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…
I don't think the article is saying:
"pypy.js is really fast, why not use it instead of CPython?".
It's saying:
"Consider using pypy.js on the client, it's comparable in performance to native CPython; you consider that fast enough."
Re: PyPy.js: Now faster than CPython
#28I get 157K/sec in the terminal and 309K/sec in Chrome. As the article says, Chrome's performance shows wide variation, even after JIT warmup. It's ranging from 50K/sec to 320K/sec. Bizarre.
JITs are great but can be unpredictable, that's probably the cause. As mentioned in the article, JITs vs AOT have upsides and downsides.
Re: PyPy.js: Now faster than CPython
#29Earlier quoted context omitted.
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 u…
I still don't get the point of using Go instead of PyPy or Cython.
Clean and efficient concurrency primitives, greater memory efficiency, and the ability to finely control memory layout, combined with just enough "high level" in the language to write complex systems. For that, you give up some (but not too much) of the rapidity of dynamic typing, and you don't have the marvelous ecosystem of libraries Python has built up. (yet)
Re: PyPy.js: Now faster than CPython
#30Does this work at all in Safari? Is Safari's crappy performance of native->js ever going to catch up to FF and Chrome?
Yes, Safari has been working on an LLVM-based JIT called FTL. It now outperforms v8 on almost all asm.js benchmarks, http://arewefastyet.com/#machine=12&view=breakdown&suite=asm... That's not in release versions of Safari yet, it was just enabled on trunk. But it will make Safari very competitive once more.
What if LLVM based JITs with NaCL style security were available in all browsers except IE? (I'm just assuming Microsoft will drag their heels.) Then an LLVM IR based bytecode could become a standard bytecode for browsers.