What blocks Ruby, Python to get Javascript V8 speed?

Question

Are there any Ruby / Python features that are blocking implementation of optimizations (e.g. inline caching) V8 engine has?

Python is co-developed by Google guys so it shouldn't be blocked by software patents.

Or this is rather matter of resources put into the V8 project by Google.

Solution 1

What blocks Ruby, Python to get Javascript V8 speed?

Nothing.

Well, okay: money. (And time, people, resources, but if you have money, you can buy those.)

V8 has a team of brilliant, highly-specialized, highly-experienced (and thus highly-paid) engineers working on it, that have decades of experience (I'm talking individually – collectively it's more like centuries) in creating high-performance execution engines for dynamic OO languages. They are basically the same people who also created the Sun HotSpot JVM (among many others).

Lars Bak, the lead developer, has been literally working on VMs for 25 years (and all of those VMs have lead up to V8), which is basically his entire (professional) life. Some of the people writing Ruby VMs aren't even 25 years old.

Are there any Ruby / Python features that are blocking implementation of optimizations (e.g. inline caching) V8 engine has?

Given that at least IronRuby, JRuby, MagLev, MacRuby and Rubinius have either monomorphic (IronRuby) or polymorphic inline caching, the answer is obviously no.

Modern Ruby implementations already do a great deal of optimizations. For example, for certain operations, Rubinius's Hash class is faster than YARV's. Now, this doesn't sound terribly exciting until you realize that Rubinius's Hash class is implemented in 100% pure Ruby, while YARV's is implemented in 100% hand-optimized C.

So, at least in some cases, Rubinius can generate better code than GCC!

Or this is rather matter of resources put into the V8 project by Google.

Yes. Not just Google. The lineage of V8's source code is 25 years old now. The people who are working on V8 also created the Self VM (to this day one of the fastest dynamic OO language execution engines ever created), the Animorphic Smalltalk VM (to this day one of the fastest Smalltalk execution engines ever created), the HotSpot JVM (the fastest JVM ever created, probably the fastest VM period) and OOVM (one of the most efficient Smalltalk VMs ever created).

In fact, Lars Bak, the lead developer of V8, worked on every single one of those, plus a few others.

Solution 2

There's a lot more impetus to highly optimize JavaScript interpretors which is why we see so many resources being put into them between Mozilla, Google, and Microsoft. JavaScript has to be downloaded, parsed, compiled, and run in real time while a (usually impatient) human being is waiting for it, it has to run WHILE a person is interacting with it, and it's doing this in an uncontrolled client-end environment that could be a computer, a phone, or a toaster. It HAS to be efficient in order to run under these conditions effectively.

Python and Ruby are run in an environment controlled by the developer/deployer. A beefy server or desktop system generally where the limiting factor will be things like memory or disk I/O and not execution time. Or where non-engine optimizations like caching can be utilized. For these languages it probably does make more sense to focus on language and library feature set over speed optimization.

The side benefit of this is that we have two great high performance open source JavaScript engines that can and are being re-purposed for all manner of applications such as Node.js.

Solution 3

A good part of it has to do with community. Python and Ruby for the most part have no corporate backing. No one gets paid to work on Python and Ruby full-time (and they especially don't get paid to work on CPython or MRI the whole time). V8, on the other hand, is backed by the most powerful IT company in the world.

Furthermore, V8 can be faster because the only thing that matters to the V8 people is the interpreter -- they have no standard library to work on, no concerns about language design. They just write the interpreter. That's it.

It has nothing to do with intellectual property law. Nor is Python co-developed by Google guys (its creator works there along with a few other committers, but they don't get paid to work on Python).

Another obstacle to Python speed is Python 3. Its adoption seems to be the main concern of the language developers -- to the point that they have frozen development of new language features until other implementations catch up.

On to the technical details, I don't know much about Ruby, but Python has a number of places where optimizations could be used (and Unladen Swallow, a Google project, started to implement these before biting the dust). Here are some of the optimizations that they planned. I could see Python gaining V8 speed in the future if a JIT a la PyPy gets implemented for CPython, but that does not seem likely for the coming years (the focus right now is Python 3 adoption, not a JIT).

Many also feel that Ruby and Python could benefit immensely from removing their respective global interpreter locks.

You also have to understand that Python and Ruby are both much heavier languages than JS -- they provide far more in the way of standard library, language features, and structure. The class system of object-orientation alone adds a great deal of weight (in a good way, I think). I almost think of Javascript as a language designed to be embedded, like Lua (and in many ways, they are similar). Ruby and Python have a much richer set of features, and that expressiveness is usually going to come at the cost of speed.

Solution 4

Performance doesn't seem to be a major focus of the core Python developers, who seem to feel that "fast enough" is good enough, and that features that help programmers be more productive are more important than features that help computers run code faster.

Indeed, however, there was a (now abandoned) Google project, unladen-swallow, to produce a faster Python interpreter compatible with the standard interpreter. PyPy is another project that intends to produce a faster Python. There is also Psyco, the forerunner of PyPy, which can provide performance boosts to many Python scripts without changing out the whole interpreter, and Cython, which lets you write high-performance C libraries for Python using something very much like Python syntax.

Solution 5

Misleading question. V8 is a JIT (a just in time compiler) implementation of JavaScript and in its most popular non-browser implementation Node.js it is constructed around an event loop. CPython is not a JIT & not evented. But these exist in Python most commonly in the PyPy project - a CPython 2.7 (and soon to be 3.0+) compatible JIT. And there are loads of evented server libraries like Tornado for example. Real world tests exist between PyPy running Tornado vs Node.js and the performance differences are slight.

View more solutions

Comments

[ncoghlan]

Introspection and operator overloading are probably big ones, but I don't know JS well enough to give you a real answer. The PyPy project is likely Python's best chance to reach JS kind of speeds.

[fijal]

Do you have any examples where PyPy is slower than V8 except for computer language shootout which is complete bollocks (just look how differently stuff is implemented in different languages there). Or is it just google's reality distortion field?

[Michael Dillon]

V8 isn't quite up to par with Python. Wait until V8 has to implement the 1.8 Javascript spec to make a better comparison. And at that point I am sure that someone will attempt to implement PyPy on top of the V8 engine in place of Javascript.

[jcoffland]

Why are you so sure V8 is faster than Python or Ruby? At what?

[Mark Essel]

it's worth writing your own simple test algorithms, start with a sort (merge is good) and comparing for yourself pypy and js/v8. I'd be curious of some benchmarks. Think I did this for c++ and pypy a while back github.com/victusfate/py-util/blob/master/README.md

[Hejazzman]

V8 is absolutely faster than Python/Ruby. Do any kind of benchmark you want, from simple microbenchmark to a comprehensive real world application written idiomatically in both environments. It's an order of magnitude faster for most language-native operations (ie. stuff that doesn't get delegated to C code in Python).

[Phyo Arkar Lwin]

pls provide a benchmark, i am interested in this. I think pypy will be on-par with V8 , if not faster. If anyone going to benchmark this i will make a bounty.

[xj9]

V8 is a JIT complier while CPython is a non-optimizing byte code interpreter that is intended to be a simple reference implementation. PyPy is probably the only Python implementation that is reasonably comparable to V8.

[Hejazzman]

PyPy is not the Python people use. We're talking CPython here.

[Andrea]

@V3ss0n: see my answer for a simple benchmark of K-means

[Konstantine Rybnikov]

@NikosVentouras that's not true. PyPy team had done an incredible compatibility-oriented work and it is a very campatible python replacement. The reason people don't use it is because most of their apps are IO-bounded and have no performance problems (or are short-living one-time scripts, which are bad for JIT).

[fijal]

"PyPy is not the Python people use" - you can use the same thing to say "v8 is not a JS people use when using internet explorer". Technically correct, but lacking in substance. If for "what's blocking" the answer is "because they use the wrong VM", then here you have your answer

[sarveshseri]

For those interested in benchmarks... - Here are some general benchmarks which are really optimized per language basis. These benchmarks have been produced for and used/cited in various papers in programming language research - benchmarksgame.alioth.debian.org

[cardiff space man]

Technically Javascript is probably HARDER than Python to optimize, because the way names are resolved differs. If a technique like inline caching was important, Python would probably get to use the same cached value more of the time

[fijal]

the language shootout benchmarks are NOT optimized per implementation. When we tried to optimize them e.g. for pypy, the optimizations got accepted randomly and then pypy got kicked out of the shootout, they're also a bad representation

[jd.]

Actually the moratorium on new features has been lifted since the recent release of Python 3.2.

[Rafe Kettler]

@jd but it'll be at least a year if not more until 3.3.

[oligan]

+1, but wouldn't a freeze on new language features mean more time to spend on optimization?

[Rafe Kettler]

@Andrew if only. The focus is on bringing Jython, IronPython, and PyPy up to speed, waiting for libraries to convert to Python 3, and evangelizing Python 3.

[WDRust]

Can we have some reference literature on "Given that at least IronRuby, JRuby, MagLev, MacRuby and Rubinius have either monomorphic (IronRuby) or polymorphic inline caching, the answer is obviously no." please?

[Benjamin Gruenbaum]

"The class system of object-orientation alone adds a great deal of weight" - Modern JavaScript VMs like V8 have classes, they're just implicit. Just like in Python you don't have to explicitly type a variable in JavaScript you don't have to explicitly type a class. The VM is clever enough to go through your code and extract classes.

[Luke]

As I understand it, V8 is a JIT compiler rather than an interpreter... I'm pretty sure there is a distinction between the two. Maybe not... I don't know.

[Salman von Abbas]

SpiderMonkey has comparable performance so, how did Mozilla did it then? They've very limited money..

[Lukas Bünger]

+1 for mentioning Tornado. While it goes at comparable speed to Node.js, its gen.engine module together with Python generators and the yield statement (since 2.5!!! can redefine your asynchronous coding.

[Matthieu M.]

@SalmanPK: it's not their first VM, and there are smart people working at Mozilla too.

[Finn Årup Nielsen]

"No one gets paid to work on Python" This is not quite right. Lead developer Guido van Rossum was/is an employee of Google and Dropbox

[miguel]

Mozilla's Sunspider has been made faster than V8 in less than 2 years of effort. A lot of the developers involved were around 25 years old.

[kcbanner]

Care to cite any benchmarks?

[gosukiwi]

Everyone has limited money, Mozilla has a lot of competent people, like Brendan Eich

[miguel]

Historical benchmarks: arewefastyet.com/#machine=11

[Zeograd]

Since your post, pypy released a stable 3.x supported version (and keeps on improving support, of course) : morepypy.blogspot.fr/2014/06/pypy3-231-fulcrum.html

[Ian]

@SalmanPK, miguel: Mozilla created their JS VM at least in part by reverse engineering V8. blog.mozilla.org/dmandelin/2010/09/08/presenting-jagermonkey

[dbkk]

@Ian V8 is open source (BSD license), so no need to reverse engineer, just look at what they're doing.

[Günter Zöchbauer]

See also github.com/rahul080327/medusa

[Ehvince]

and at Dropbox Guido is paid to work half-time on Python. python.org/~guido I think it was the same at Google.