
What Blocks Ruby and Python from Getting to JavaScript V8 Speed? - luu
http://stackoverflow.com/questions/5168718/what-blocks-ruby-python-to-get-javascript-v8-speed
======
nostrademons
The other major issue is backwards compatibility. Ruby and Python have large
API surfaces on both the C API and scripting language sides, with many
libraries making use of obscure language features. If any single one of those
features doesn't work, the library won't. Witness how tough the Python3
migration has been.

I talked with the Unladen Swallow guys sometime after the project was
canceled. They said that the main issue was not getting Python to run fast on
LLVM, where they said they had some really encouraging results. Instead, it
was:

1\. Bugs in LLVM which they had to spend a lot of engineering effort working
around. This is probably much less of an issue now, with Clang, XCode, Julia,
and Rust all being used in production with a good deal of success.

2\. Compatibility with the C API. This was considered a "non-negotiable" for
Unladen Swallow's design, and one major reason they started by forking CPython
rather than building from scratch on LLVM. The problem is, the C API makes a
lot of assumptions about how objects are laid out in memory, how they are
memory-managed, how they are accessed, etc. If you must support defining &
calling methods from C, there's a lot less freedom to, say, stick a trampoline
in the method preamble or a PIC at the call site or switch to using a tagged
representation of pointers and ints. That means that the VM has to fall back
on the interpreter (and possibly waste cycles converting & marshalling data)
for a lot of things that are supposed to be fast, which kills many of the
real-world performance gains.

V8 had the luxury of defining its own C interface. I've often wondered whether
a Python that gives up C extension compatibility could get similar speed gains
- I even ran the idea by a former Python core team member who worked on my
team at Google, and he said there was no theoretical reason why not. But then,
Python without C extension compatibility would be Python without Numpy, Scipy,
scikit-learn, PIL/Pillow, JSON, StringIO, and many other critical packages. At
that point you might as well start over with a new language.

~~~
moe
_Python without C extension compatibility would be Python without Numpy,
Scipy, scikit-learn, PIL /Pillow, JSON, StringIO_

Would we really miss them if Python was then fast enough to do these things
natively?

~~~
nostrademons
Somebody has to actually write the new functionality, and then many more
people have to _learn_ the new functionality.

Anyway, this thought experiment has basically been done. "Ditch the backwards
compatibility, start with a new language, make it fast by design, and rewrite
all the packages that make it super popular." It's called Julia. And it's
popular among some people, but for a lot of others, the maturity of the Python
ecosystem still makes it a lot more attractive despite the performance &
multi-language issues.

~~~
cossatot
I believe that Julia still uses a lot of C/FORTRAN packages that numpy relies
on, like BLAS, so they're not really re-written in Julia (at least yet?).

~~~
CyberDildonics
I think he meant re-do the bindings. A lot of Julia is written in itself, but
not things like that. Large libraries benefit from Julia's extremely simple C
calling mechanisms.

------
nkurz

      Put on hold as too broad by rene, davidism, vaultah, Sam, iCodez 2 hours ago
    
      There are either too many possible answers, or good answers 
      would be too long for this format. Please add details to 
      narrow the answer set or to isolate an issue that can be 
      answered in a few paragraphs.
    
      If this question can be reworded to fit the rules in the 
      help center, please edit the question or leave a comment.
    

Meta: It's interesting that 5 users thought that it would benefit the SO
community to put this question on hold, while 100+ thought it was an
interesting question. In one way, SO does keep the noise down pretty well, but
this doesn't feel to me like noise. Does avoiding questions like these
actually make SO a better place? Is there a reworded version of this question
that would actually elicit better responses? Or is this just the joy of
playing the enforcer?

~~~
mirkules
I'm not a moderator, but I agree that the question is not really constructive
in the scope of what stack overflow is supposed to do: answer questions to
specific problems. The question itself is interesting as are the answers, and
the whole discussion around it is great, but it doesn't belong on that site.

Why is python not as fast as JavaScript is a completely different question
than "An internal error occurred during updating maven project". The later
seeks a solution to a problem while the former only encourages discussion but
is impossible to solve (because it's not a solvable question).

So, I feel this question was appropriately tagged, or perhaps even not
aggressively enough.

~~~
ProAm
> the scope of what stack overflow is supposed to do: answer questions to
> specific problems

Honestly people should read the manual then. That will give you the specific
answer to your question. Stackoverflow wanted to replace other
message/discussion boards in regards to programming. It's veered away from
that purpose and IMHO has become cumbersome to use. If you have to worry more
about how you word your question than the question itself is it worth asking
there?

~~~
riffraff
> If you have to worry more about how you word your question than the question
> itself is it worth asking there?

well, you are supposed to ask a question after you have researched the
solution, so the extra worry wouldn't actually be relevant.

~~~
ProAm
The manual answers all questions related to programming.

------
chaoky
The public domain CMUCL/SBCL line of compilers (as well as most commercial
common lisps) are notorious for being the fastest dynamic/interactive systems
since the 1990's. Most dynamic languages are still nowhere near the speed of
the assembly code produced by most common lisp compilers while still retaining
the impressive dynamic & incremental aspect of the language (although every
year they are closing in). In the end, it comes down to how much effort was
put into these compilers, rather than the language itself. For years DARPA
spent loads of money on a highly trained team of compiler experts to work on
CMUCL (later SBCL) led by Scott Fahlman. I doubt Ruby and Python will be able
to attain JS speed until more effort goes into on these systems, which so far
are still defined by a canonical, byte-code interpreted implementation.

~~~
Solarsail
Isn't finding what function to call at a particular function call much easier
in Lisp (or Julia) than it is in Python/Ruby/JS? The vast numbers of CL and
Scheme compilers are relatively easy to write, exactly because the languages
leave (somewhat) less to decide / change at runtime than Python/Ruby/JS.

Edit: PL's aren't physics.

~~~
chaoky
Definitely not. It's almost hard to think of what Lisp doesn't let you change
at runtime, since the compiler is always there. Common Lisp is in fact much
more dynamic at run time than python/ruby/smalltalk. I would say that Python
and Ruby are the more limited ones. You can recompile functions whenever in
CL, you can even compile functions that call undefined functions at runtime.
Lisp is known for its extreme late binding and reflection, with almost
everything redefine-able on the fly (except functions declared inline, you
need to recompile to callers afterwards. but only if you declare them inline).
Even in defining classes, Common Lisp will redefine a class and update all the
_old_ instances of the class as well. As far as I know, Ruby and Python do not
automatically update old instances. Ruby, like Common Lisp, does allow you to
add new methods at runtime without redefining the entire class, and as far as
I know python does not.

> The vast numbers of CL and Scheme compilers are relatively easy to write,
> exactly because the languages leave (somewhat) less to decide / change at
> runtime than Python/Ruby/JS.

I would say it's a mistake to conflate Scheme and Common Lisp. Scheme isn't
even defined well enough to say something implementation independently about
whether the environments should decide things at runtime or not. But Common
Lisp as a language has special/dynamically scoped variables and runtime
definable macros which make it much more difficult to write a compiler for it.
I would say that Common Lisp has way more things to decide at runtime than
python or ruby. Maybe they're about the same in terms of difficulty of writing
a compiler for, if only because lisp has no parsing/lexing pass. Again, in the
end, it's mostly not a language issue. It's how much money and how many
compiler experts work on your implementation.

------
Symmetry
If the difference in speed comes down to money, as the first two answers
suggest, then why is LuaJIT even faster than V8? I'm pretty sure PyPy has had
far more money invested in it than LuaJIT has.

~~~
mseri
Because LUA is much simpler, already porting LUJit to LUA5.3 is revealing hard
as far as I understood

~~~
yoklov
My understanding is that LuaJIT isn't really under active development anymore.

It does seem like it would be hard to add the 5.3 features to LuaJIT without
compromising on efficiency, but given how clever Mike Pall is, I'd suspect it
can be done.

~~~
justincormack
It is under active development. There is the start of an arm64 port recently
for example. Mike did take a break to do other stuff for a bit it seems, but
its not stopped.

~~~
yoklov
Ah, the note at the top of
[http://luajit.org/sponsors.html](http://luajit.org/sponsors.html) had made me
think he was not.

------
bkeroack
When Ruby or Python is too slow you can switch to something else. When
JavaScript is too slow you have to either pay someone to make your code faster
or pay someone to make the browser faster.

~~~
iamvfl
Not all JavaScript runs in the browser

~~~
_delirium
It mostly did before V8 was created. A few people ran JS outside the browser
using Mozilla's Rhino, but it wasn't very common. Nodejs probably was the
first widely adopted platform for non-browser JS, and it was built on V8 after
V8 already existed. So I believe historically server-side JS did not drive JS
performance.

~~~
SixSigma
It should be mentioned that Microsoft has had server side Javascript (well,
Jscript) running on IIS since 1997. I used to write data driven websites in
it.

[http://en.wikipedia.org/wiki/JScript](http://en.wikipedia.org/wiki/JScript)

~~~
ksherlock
and Windows Script Host (wscript/cscript).

------
spullara
IMHO, a few things:

1) Python & Ruby have lots of dependencies on the C FFI — PyPy is great, but
not replacing CPython because of this.

2) A huge amount of effort is going into v8. Perhaps that level of effort will
catch up to the effort put into the JVM.

3) Using esoteric, hard to optimize features in Python and Ruby is apparently
a sign of cleverness. And those features are used in the major frameworks like
RoR.

4) Incompatibility between other engines. Right now though you have to be
backwards compatible with the web, it is acceptable to implement a small
subset of the new features. People wouldn't be happy with several versions of
Java / Python / Ruby all implementing some of the new features but not all of
them.

But really, besides a highly optimized regex engine, v8 is still kind of slow.
Just happens to be the fastest of the slow.

------
overgard
For context: this question was asked in '11\. PyPy is _really really fast_
now. I'm not sure exactly how it stacks up against v8, but it definitely holds
its own. It's roughly 7 times faster than cpython.

~~~
ris
...if you can afford the memory requirements.

~~~
overgard
True, but you could say the same thing about almost any JIT
compiler/interpreter for a garbage collected language. It's not like java is
known for it's memory efficiency. I'm not too knowledgeable about the memory
efficiency of v8, I imagine they pay attention since it's in a browser, but
I'm going to guess compared to a simple interpreter it's probably not great.

~~~
ris
That is of course true, but pypy does have an unusually large memory burden
(and the developers do know about it - it's just not top priority at the
moment).

------
andrewchambers
Keep an eye on this new python implementation:

[https://github.com/dropbox/pyston](https://github.com/dropbox/pyston)

------
munificent
I think the top answer is pretty spot-on.

Also, JavaScript has a much smaller API surface area. In addition to
optimizing core code execution, a decent amount of work goes into optimizing
the core libraries and built-in types: RegExps, string operations,
collections, hashes, etc.

In JavaScript, that set of stuff is pretty small. In Ruby and Python, it's
enormous.

------
emmelaich
V8 needs to be as fast as possible because the running time is dominated by
processing.

Python only needs to be fast enough because the running time of a typical
program is largely affected by i/o time.

------
ponytech
This question is from 2011 (missing in the link title). Does things have
changed since then ?

------
darkarmani
What is V8 speed? Without actually quantifying anything this is all just bull
shitting. For all I know V8 is slower and they are asking why python and ruby
aren't as slow as V8.

Secondly, if we assume the question is saying that V8 is faster, is it faster
than vectorized numpy functions? Without specifics in mind, this question is
just to start a language war.

~~~
MBCook
I disagree. The history of browsers of the past couple of years shown the
JavaScript has sped up tremendously compared to older browsers.

While python and ruby may be getting faster they're not seeing those order of
magnitude speedups that we've seen in JavaScript.

------
KaiserPro
Its more deep grained that "the VM is slow" The default python interpreter is
really quite fast, but biggest performance problem with python is that
_everything_ is an object.

Don't believe me? look here: [https://jakevdp.github.io/blog/2014/05/09/why-
python-is-slow...](https://jakevdp.github.io/blog/2014/05/09/why-python-is-
slow/)

perl is not much older, but in a majority of tasks its faster than python,
even c-API python. (it even threads!)

Yes it could be engineered around, I assume thats what pypy is doing (although
STM is is going to limit performance in a threaded environment)

Javascript was designed to be an embedded language, so it was had to be quick
to initialize, and have a simple object model.

Python was designed to be an easy object oriented language.

~~~
sanxiyn
That's not why Python is slow. That's why Python is harder to optimize.

Being harder to optimize is not being slow. This is an important distinction.
If you want to know what that means and the real reason why Python is slow, go
read this instead: [https://speakerdeck.com/alex/why-python-ruby-and-
javascript-...](https://speakerdeck.com/alex/why-python-ruby-and-javascript-
are-slow)

~~~
seunosewa
Aren't things that are harder to optimize generally slower for precisely that
reason?

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

What an amazing "obviously"!

------
nhebb
It sounds like Lars Bak needs to write a book on VM design.

~~~
scott_karana
Even if he never does, we're lucky to have the source to many of his VMs
available :)

~~~
discreteevent
Would the dart VM be the place to start? It's the newest and I saw a
presentation somewhere where it looked like part of what motivated them to
create it was having to deal with so many edge cases in JavaScript. I imagine
the source of V8 is probably not going to be that easy to pick up.

------
Dirlewanger
In short: money, money, and money.

Ruby has what, a handful (if that?) of people at Heroku who work on Ruby some
of the time? Not sure if Matz does full-time or not.

~~~
jiggy2011
It does seem strange to me that so few people are paid to work full time on
ruby etc (core tech) when you consider the massive total benefit from making
ruby a few % faster or better. Why is the funding not there?

~~~
thinkbohemian
I think there are a few issues. The first is funding. If you are an
engineering manager and trying to ship product, you don't want a 25% faster
Ruby VM in 10 years, you want someone to benchmark and optimize existing code
in existing products 25% today. I agree that it's a good pay off, cost versus
benefit...however the benefit is spread around hundreds and thousands of
companies. Google gains marketshare for chrome when V8 gets faster, there's
very few companies that get significant advantage explicitly from making Ruby
faster for everyone. If you're paying to make Ruby faster, it's also getting
faster for your competitors too (if they use Ruby).

There are a bunch of core contributors that are very active. Several of their
companies allow them to spend time contributing (most of them are from Japan).
Another example is Aaron, he is on Ruby core and his company allows him some
time to contribute to open source, so this is sponsorship in a way. I while a
company stands to benefit from sponsoring a full time developer, they benefit
just as much if someone else sponsors a full time developer. Right now there's
not enough companies with either a business incentive, altruism, or interest.
Perhaps there are companies out there interested in sponsoring full time devs
who just don't know how (and to your point cannot find them) but I think that
would be the minority case.

~~~
jbergens
Oracle seems to spend some money on java and JRuby which is pretty fast and
will get even faster the coming years. Not sure how much if any they are
directly funding JRuby but they are funding the JVM which is used by JRuby.

~~~
cheald
Per Chris Seaton's comment in this thread:

> Oracle Labs pays two people full time (including me) [to work on JRuby] and
> a PhD student, and more soon.

------
amelius
It is a pity that V8 is so entangled with the language Javascript.

In my opinion, V8 would have been much more powerful if it was fully
parameterizable in all the types that it supports, etc. In that case Python
could simply be translated into V8 intermediate code (or javascript).

~~~
tracker1
The .Net DLR is like that, although I was disappointed when they dropped
Dynamic JScript... more so when they effectively dropped continued DLR support
altogether, it was a nice runtime. Maybe with Rosilyn some open support for
dynamic languages will come back.

Personally I've been working with JavaScript since the mid 90's, and node.js
since very early on. I like JS more than most as it's my favorite language,
for all its' warts. I do feel that for most work loads a modular dynamic
language implementation for a given task is a better idea than building a
compiled version. If you need more performance from something, or it's
something relatively obvious (A/V processing comes to mind) it's similar to a
premature optimization to go compiled first these days.

Kind of more than you are/were looking for.. but you may want to look into
IronRuby/IronPython ... it's a pretty nice way of working with the languages.

------
andybak
[http://www.cdotson.com/2014/08/nodejs-vs-python-vs-pypy-a-
si...](http://www.cdotson.com/2014/08/nodejs-vs-python-vs-pypy-a-simple-
performance-comparison/)

------
walshemj
For quite a few python use cases on the tech side you just recode your python
prototype in fortran (and use the full fat Intel compiler)

~~~
gnufx
I'm not sure what "full fat" means, but compared with current gfortran in my
experience, ifort is incorrect by default, surprisingly unreliable, and
typically generates similar speed code at the 10% level. My all-free software
build of a quantum chemistry program was reported to run faster than an all-
Intel libraries one on a cluster which has faster processors but is otherwise
very similar to ours.

If you just write in Fortran, you don't have to have to debug two versions.

------
gcb0
short answer: features.

------
TheCondor
Pypy is slower than v8?

~~~
masklinn
Yes.

------
hellbanner
When can we run Ruby & Python code in the browser?

~~~
pmontra
Ruby has Opal [http://opalrb.org/](http://opalrb.org/) a Ruby compiler to
JavaScript.

Or Decaf [http://trydecaf.org/](http://trydecaf.org/)

Or [http://rubyfiddle.com/](http://rubyfiddle.com/) if you want to be literal
about Ruby in the browser :-)

~~~
hellbanner
Thanks. Brython looks more like what I was looking for. Everyone's porting
code into Javascript but I think a better browser can be built with more
language support.

------
DevFactor
Crazy thing is, Ruby is already so much more powerful than Javascript.
Javascript is fast, easy to implement and relatively easy to learn - but it is
so limited.

As a programming language, Ruby really pushes the limits of what we are used
to.

~~~
pjmlp
Dylan and Lisp/Scheme are way more powerful than Ruby and compile to native
code.

Ruby pushes what?! I bet you never used a commercial Smalltalk system.

~~~
eropple
There are always touchy Lisp and Smalltalk fans who must vent their spleens at
the earliest opportunity, but barely a sliver of active developers today have
used a Smalltalk system and only marginally more, even with Clojure, have used
a Lisp in anger. So, when you are not actively trying to read the literal
worst into something, you will see that Ruby does in fact do quite a lot that
"we," in the general case, are not terribly used to. That's a major reason I
use it, for example, where performance isn't a big deal.

------
agounaris
have you guys actually tried anything else than serving web requests with
node...because for any other backend procedure node is not faster....and
definitely the code is not cleaner!

Check also atom vs sublime text as desktop applications...

~~~
city41
I'm not sure how the comparison is relevant seeing as Sublime Text is written
in C++. What am I missing?

~~~
aikah
Atom is written in js + chrome "engine" for the ui.

Javascript is fast enough,the problem is that Atom is basically using browser
rendering for the ui,which isn't as fast as using c++ widgets.

