I'm not so sure it's all about money. Ruby and Python are significantly more complex languages than Javascript. By contrast, LuaJIT can absolutely wreck V8 performance-wise, but Lua is a substantially less complex language.
v8 doesn't really do multithreading, for example, so it's able to take a lot of shortcuts that save a lot of time. v8 doesn't have built-in Bignum support, and doesn't support non-UTF-16 character encodings, so there is a lot of work that it doesn't have to do, where more full-featured languages have to make sanity checks and do conversions under the hood frequently. Ruby's metaprogramming constructs are extremely powerful, but their rulesets are fairly complex, so the VM has a lot of bookkeeping to do to ensure that everything works well. I don't know Python's internals that well, but I do know that Ruby spends a lot of time making sure that all those things play nicely together without the programmer having to exert much effort, and that does incur a performance penalty.
v8 is an absolutely excellent piece of engineering, but it's a tool that occupies a slightly different problem space than the Ruby and Python VMs do. That's not to say that Ruby and Python don't have gains they can and should make, but that it's not as simple as pouring money in one end and watching performance come out.
If you can provide modern numbers, I'd appreciate it!
Maybe my information is out of date, but I just now picked a random benchmark (the fasta one from the language shootout) and ran it against v8-3.14.5.10 and luajit-2.0.3 (Fedora 21, latest available via yum), and luajit came out quite a bit ahead. I grant that it's a really naive benchmark setup and shouldn't be taken seriously, but my investment here is pretty minimal :)
$ time luajit-2.0.3 fasta.lua 25000000 > /dev/null
luajit-2.0.3 fasta.lua 25000000 > /dev/null 8.60s user 0.01s system 100% cpu 8.613 total
$ time d8 --nodebugger fasta.js > /dev/null -- 25000000
d8 --nodebugger fasta.js -- 25000000 > /dev/null 12.80s user 0.51s system 100% cpu 13.209 total
Heck, even with these data 12.80s vs 8.60s is not "wreck".
Those are in the same order of magnitude even! Not even 2x the speed. Hardly makes a difference in picking one or the other, all other things being the same.
Now, compare V8 or LuaJit with Python or Ruby -- that would be "wrecking it".
You've missed my point; LuaJIT can be quite a bit faster than v8, despite the amount of money being invested in it being a tiny fraction of what's put into v8. Therefore, we can conclude that v8's speed is not simply a function of money, but that there may be other variables involved, such as "complexity of language".
I'm not attacking v8 here. I'm simply pointing out that there are VMs for interpreted languages which run faster than v8, which isn't to say "v8 is bad", but rather "different languages inherently have different performance profiles".
That "another microbenchmark" seems to have some unnecessary overhead vs the Lua one? I don't like it. The Language shootout is better: let anybody implement the task anyway he likes, so long the results are the same, and compare that.
It supports it as a language construct, even though the GIL gets in the way of actual parallelism. As far as I'm aware, EMCAScript doesn't provide any concept of threading within the language itself. You can get it by spinning up multiple separate VMs in separate threads and passing messages back and forth (which is what web workers are), but that's a function of how the VM is presented in the context of a larger application, not a feature of the language itself. Jython and JRuby don't have GILs and are able to achieve full parallelism using the same language constructs that CPython and MRI use.
I don't think you can even achieve that kind of concurrency (multiple seperate VMs in seperate threads running in parallel) with Python, though. As I understand it the GIL really is global - it's shared across every single VM in every thread within the current process, at least in the CPython 2.x series, and that's not easy to fix because it's protecting global shared state.
If they're running separate VMs then your threads aren't really threaded in any meaningful sense; you could equally well run those VMs in separate processes (shared-memory communication between distinct processes is not completely trivial but it's very much doable).
Last I looked, you are correct, but Python isn't designed as an embeddable language, either. Multiple VMs usually isn't something you'd have any desire to do specifically because you can achieve multithreading from within the language itself.
If you need multiple, separate VMs (ie, to drive multiple isolated scripting engines in a game), then v8 isolates or Lua contexts will do you just fine, but that's a different use case than most places where you'd want to use concurrent Python.
Python totally is designed as an embeddable language; that's why there's a giant section called "Embedding Python in Another Application" in the reference manual:
It's just that at the time Python was created, multithreading was not something you generally did in a C program. The POSIX thread standard didn't come out until 1996. Python was started in 1989, first released in 1991, and reached 1.0 in 1994. Common rules of thumb for dealing with multithreaded programs (eg. "Avoid global or static data") didn't really become popularized until the 2000s, and many programmers in less well-informed circles still don't know them.
v8 doesn't really do multithreading, for example, so it's able to take a lot of shortcuts that save a lot of time. v8 doesn't have built-in Bignum support, and doesn't support non-UTF-16 character encodings, so there is a lot of work that it doesn't have to do, where more full-featured languages have to make sanity checks and do conversions under the hood frequently. Ruby's metaprogramming constructs are extremely powerful, but their rulesets are fairly complex, so the VM has a lot of bookkeeping to do to ensure that everything works well. I don't know Python's internals that well, but I do know that Ruby spends a lot of time making sure that all those things play nicely together without the programmer having to exert much effort, and that does incur a performance penalty.
v8 is an absolutely excellent piece of engineering, but it's a tool that occupies a slightly different problem space than the Ruby and Python VMs do. That's not to say that Ruby and Python don't have gains they can and should make, but that it's not as simple as pouring money in one end and watching performance come out.