28 ms·

What Blocks Ruby and Python from Getting to JavaScript V8 Speed?

314 points by luu 12y ago

Dirlewanger 12y ago
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 12y ago
  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?
  - adamnemecek 12y ago
    I'm guessing that people like Lars Bak are hard to come by. I remember reading somewhere that Google opened the Aarhus office mostly because he didn't want to move to Mountain View (I might be misremembering so don't quote me on that).
    - munificent 12y ago
      That's correct. Well, more precise would be he didn't want to move back to Silicon Valley.
  - MBlume 12y ago
    Tragedy of the Commons
  - makmanalp 12y ago
    It would be very cool to start a crowdfund-esque campaign that also encourages corporate sponsors to build a fund to hire fulltime developers and create an agenda devoted to performance.
  - comex 12y ago
    In theory this sounds like the kind of problem snowdrift.coop was created to address, if that ever gets off the ground.
  - thinkbohemian 12y ago
    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 12y ago
      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 12y ago
        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.
  - chrisseaton 12y ago
    RedHat also pays two people full time to work on JRuby, and Oracle Labs pays two people full time (including me) and a PhD student, and more soon.
- thinkbohemian 12y ago
  We sponsor Matz, Nobu, and Koichi. Of them Koichi works pretty much full time on speed. He implemented partial generational GC in Ruby 2.1 and incremental GC in 2.2. He also implemented faster keyword arguments https://bugs.ruby-lang.org/issues/10440 https://bugs.ruby-lang.org/issues/10440. There's actually been a bunch of great performance increases in the past few years in addition to the GC. Optimized method cache invalidation by the late James Golick, frozen string pool for hash keys by tmm1, using vfork instead of fork, etc, copy on write GC. There's also new features, like Ruby's ability to GC symbols that let developers use symbols in more places and spend less time converting back and forth between strings. So yes, money is a factor. Having employees work on it full time helps. Despite only having 3 full time employees Ruby has made some pretty impressive improvements recently.
  - aaronbrethorst 12y ago
    > late James Golick Holy shit, how did I miss this? edit: more details here: https://news.ycombinator.com/item?id=8804624 https://news.ycombinator.com/item?id=8804624 That's really sad...good guy
  - MrBra 12y ago
    Also I believe this will help a lot: http://rbkit.codemancers.com/ http://rbkit.codemancers.com/
  - rurban 12y ago
    But basic knowledge of fast VMs would also help. Maybe get an engineer from a good school? E.g. a decent GC would help ruby a lot, i.e. Cheney Copying Collector with thread support. Ruby is used on devices with lots of RAM and big cache lines. Or optimized data structures (nan-tagging, better tagging) and slimmed down ops. I need 32bit per op plus 2 args. Check out how much more ops fit into your cache line then. The ruby hash table implementation also sucks. Write a good one. Study the literature. It's basic engineering, you don't need to be a genius, really. And embrace types, either optional or inferenced. Optimize on type information.
- cheald 12y ago
  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.
  - kchoudhu 12y ago
    It's not unfair to say that python doesn't do multithreading either.
    - cheald 12y ago
      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.
      - kchoudhu 12y ago
- deleted 12y ago
  [deleted]
nhebb 12y ago
It sounds like Lars Bak needs to write a book on VM design.
- munificent 12y ago
  A lot of those guys know enough to write several books. Unfortunately, most of them don't seem to enjoy writing things for humans to read as much as they enjoy hacking on VMs. :(
- scott_karana 12y ago
  Even if he never does, we're lucky to have the source to many of his VMs available :)
  - discreteevent 12y ago
    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.
- beagle3 12y ago
  I would pay three times as much for a book by Mike Pall. With all due respect to Lars Bak (and I have utmost respect), Mike Pall has done a lot more with about 1% of the resources.
- dmoney 12y ago
  Why do we need so many different VMs anyway? Is it it just history and politics? Are, e.g. Python and Ruby so different that, if implementing from scratch today it would make sense for each of them to have its own VM? What about the CLR vs the JVM: are their respective functions so different that it would make sense for both of them to exist if not for the need for Oracle and Microsoft to maintain mutual incompatibility?
DevFactor 12y ago
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 12y ago
  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 12y ago
    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.
  - matthewmacleod 12y ago
    It's not a surprise with attitudes like that! Ruby is popular because it's powerful and expressive in a way that many other environments are not. 'Power' isn't everything - ability to easily use it is equally important. Hell, it's a direct spiritual descendent of Smalltalk to a greater degree than any other popular language! The performance of Ruby caused by the extensiveness of its dynamism had definitely been one of the downsides of the language, and the fact that newer languages place more emphasis on that while learning from Ruby is great - it's how the field evolves!
  - vezzy-fnord 12y ago
    Given you mentioned Smalltalk, you might be interested in this LtU post: http://lambda-the-ultimate.org/node/2606 http://lambda-the-ultimate.org/node/2606
- 12y ago
andrewchambers 12y ago
Keep an eye on this new python implementation: https://github.com/dropbox/pyston https://github.com/dropbox/pyston
munificent 12y ago
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.
hellbanner 12y ago
When can we run Ruby & Python code in the browser?
- pmontra 12y ago
  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 12y ago
    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.
- nicarus1984 12y ago
  Brython: http://www.brython.info http://www.brython.info
  - hellbanner 12y ago
    Thanks, that's more of what I was looking for.
nostrademons 12y ago
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 12y ago
  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?
  - aardvark179 12y ago
    The code backing things like Numpy and Scipy is not small, has been well optimised over many years, and would be extremely difficult to reimplement at speed even with a faster Python. The freedom high level languages give tends to prevent many low level optimisations that are really useful for big maths and data routines. For the language I work on we were able to write macros and functions to allow our C libraries to continue to work when we changed our VM, but we've spent considerable effort optimising things so the C has to reach back into objects as little as possible, and we could only do this because recompilation and refactoring was okay.
Symmetry 12y ago
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 12y ago
  Because LUA is much simpler, already porting LUJit to LUA5.3 is revealing hard as far as I understood
  - ufo 12y ago
    LuaJIT "forked" from Lua during the 5.1 days. There are still some features from 5.1 that Mike (intentionally) didn't port to LuaJIT.
  - yoklov 12y ago
    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 12y ago
      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 12y ago
        Ah, the note at the top of http://luajit.org/sponsors.html http://luajit.org/sponsors.html had made me think he was not.
- mythz 12y ago
  Because Mike Pall is a genius and likes working on LuaJIT so doesn't take much to sponsor him to work on it: http://luajit.org/sponsors.html http://luajit.org/sponsors.html
darkarmani 12y ago
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 12y ago
  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.
bkeroack 12y ago
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 12y ago
  Not all JavaScript runs in the browser
  - _delirium 12y ago
    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 12y ago
      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 12y ago
        and Windows Script Host (wscript/cscript).
agounaris 12y ago
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 12y ago
  I'm not sure how the comparison is relevant seeing as Sublime Text is written in C++. What am I missing?
  - aikah 12y ago
    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.
- TheAceOfHearts 12y ago
  JS is considerably faster than both Ruby and Python, at least from benchmarks I've seen.
nkurz 12y ago
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?
- digikata 12y ago
  I think SO is starting the get the same problem that Wikipedia has been wrestling with - editor/moderator cliques. It may be a classic bureaucracy issue - on one hand they raise the quality bar by providing a higher level of consistency. On the other hand, they may drift from what might be considered reasonable from the point of view of more and more people outside the circle...
  - nerfhammer 12y ago
    The theory of universal deletionism states that sites with extensive volunteer moderators will invariably tend towards bureaucracy and deletionism regardless of what regular users want as mods get bored and want to feel important You should see how excited the moderators get when they decide there's a new rule against some new kind of question
  - sp332 12y ago
    SO was supposed to mitigate this effect by making people earn their mod rights. So you only get to call other people's questions off-topic if you have a track record of contributing to the site content yourself.
- Liru 12y ago
  I would say it's the latter. A majority of questions that I've found on SO that helped me solve a problem or answer a question have been marked as non-constructive. I don't know why people would do that from a logical perspective, but I can see how having the ability to moderate discussion would make one overzealous with this sort of thing.
emmelaich 12y ago
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.
deleted 12y ago
[deleted]
spullara 12y ago
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.
TheCondor 12y ago
Pypy is slower than v8?
- masklinn 12y ago
  Yes.
overgard 12y ago
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 12y ago
  ...if you can afford the memory requirements.
  - overgard 12y ago
    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 12y ago
      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).
chaoky 12y ago
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.
- est 12y ago
  The difference is that SBCL compiler targets x86, Python runtime targets C.
  - chaoky 12y ago
    SBCL targets x86, alpha, ARM, x86-64, and PPC in fact. Python doesn't actually target C, it targets a bytecode VM that's interpreted by C. which obviously is much easier to do. (there are many CL implmentations that use this approach as well eg ECL CLISP...) It just doesn't seem like Ruby or Python has the sophistication/resources yet to move their main implementations to native code, aggressively optimized compilers (yet). Which is unfortunate considering CL, Dylan and small talk got there first 30 years ago.
- Solarsail 12y ago
  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 12y ago
gcb0 12y ago
short answer: features.
ponytech 12y ago
This question is from 2011 (missing in the link title). Does things have changed since then ?
andybak 12y ago
http://www.cdotson.com/2014/08/nodejs-vs-python-vs-pypy-a-simple-performance-comparison/ http://www.cdotson.com/2014/08/nodejs-vs-python-vs-pypy-a-si...
bshimmin 12y ago
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"!
KaiserPro 12y ago
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 12y ago
  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-are-slow https://speakerdeck.com/alex/why-python-ruby-and-javascript-...
  - seunosewa 12y ago
    Aren't things that are harder to optimize generally slower for precisely that reason?
walshemj 12y ago
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 12y ago
  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.
amelius 12y ago
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 12y ago
  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.

314 points by luu 12y ago

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 12y ago
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?
- adamnemecek 12y ago
  I'm guessing that people like Lars Bak are hard to come by. I remember reading somewhere that Google opened the Aarhus office mostly because he didn't want to move to Mountain View (I might be misremembering so don't quote me on that).
  - munificent 12y ago
    That's correct. Well, more precise would be he didn't want to move back to Silicon Valley.
- MBlume 12y ago
  Tragedy of the Commons
- makmanalp 12y ago
  It would be very cool to start a crowdfund-esque campaign that also encourages corporate sponsors to build a fund to hire fulltime developers and create an agenda devoted to performance.
- comex 12y ago
  In theory this sounds like the kind of problem snowdrift.coop was created to address, if that ever gets off the ground.
- thinkbohemian 12y ago
  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 12y ago
    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 12y ago
      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.
- chrisseaton 12y ago
  RedHat also pays two people full time to work on JRuby, and Oracle Labs pays two people full time (including me) and a PhD student, and more soon.
thinkbohemian 12y ago
We sponsor Matz, Nobu, and Koichi. Of them Koichi works pretty much full time on speed. He implemented partial generational GC in Ruby 2.1 and incremental GC in 2.2. He also implemented faster keyword arguments https://bugs.ruby-lang.org/issues/10440 https://bugs.ruby-lang.org/issues/10440. There's actually been a bunch of great performance increases in the past few years in addition to the GC. Optimized method cache invalidation by the late James Golick, frozen string pool for hash keys by tmm1, using vfork instead of fork, etc, copy on write GC. There's also new features, like Ruby's ability to GC symbols that let developers use symbols in more places and spend less time converting back and forth between strings. So yes, money is a factor. Having employees work on it full time helps. Despite only having 3 full time employees Ruby has made some pretty impressive improvements recently.
- aaronbrethorst 12y ago
  > late James Golick Holy shit, how did I miss this? edit: more details here: https://news.ycombinator.com/item?id=8804624 https://news.ycombinator.com/item?id=8804624 That's really sad...good guy
- MrBra 12y ago
  Also I believe this will help a lot: http://rbkit.codemancers.com/ http://rbkit.codemancers.com/
- rurban 12y ago
  But basic knowledge of fast VMs would also help. Maybe get an engineer from a good school? E.g. a decent GC would help ruby a lot, i.e. Cheney Copying Collector with thread support. Ruby is used on devices with lots of RAM and big cache lines. Or optimized data structures (nan-tagging, better tagging) and slimmed down ops. I need 32bit per op plus 2 args. Check out how much more ops fit into your cache line then. The ruby hash table implementation also sucks. Write a good one. Study the literature. It's basic engineering, you don't need to be a genius, really. And embrace types, either optional or inferenced. Optimize on type information.
cheald 12y ago
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.
- kchoudhu 12y ago
  It's not unfair to say that python doesn't do multithreading either.
  - cheald 12y ago
    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.
    - kchoudhu 12y ago
deleted 12y ago
[deleted]

nhebb 12y ago

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

munificent 12y ago
A lot of those guys know enough to write several books. Unfortunately, most of them don't seem to enjoy writing things for humans to read as much as they enjoy hacking on VMs. :(
scott_karana 12y ago
Even if he never does, we're lucky to have the source to many of his VMs available :)
- discreteevent 12y ago
  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.
beagle3 12y ago
I would pay three times as much for a book by Mike Pall. With all due respect to Lars Bak (and I have utmost respect), Mike Pall has done a lot more with about 1% of the resources.
dmoney 12y ago
Why do we need so many different VMs anyway? Is it it just history and politics? Are, e.g. Python and Ruby so different that, if implementing from scratch today it would make sense for each of them to have its own VM? What about the CLR vs the JVM: are their respective functions so different that it would make sense for both of them to exist if not for the need for Oracle and Microsoft to maintain mutual incompatibility?

DevFactor 12y ago

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 12y ago
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 12y ago
  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.
- matthewmacleod 12y ago
  It's not a surprise with attitudes like that! Ruby is popular because it's powerful and expressive in a way that many other environments are not. 'Power' isn't everything - ability to easily use it is equally important. Hell, it's a direct spiritual descendent of Smalltalk to a greater degree than any other popular language! The performance of Ruby caused by the extensiveness of its dynamism had definitely been one of the downsides of the language, and the fact that newer languages place more emphasis on that while learning from Ruby is great - it's how the field evolves!
- vezzy-fnord 12y ago
  Given you mentioned Smalltalk, you might be interested in this LtU post: http://lambda-the-ultimate.org/node/2606 http://lambda-the-ultimate.org/node/2606
12y ago

andrewchambers 12y ago

Keep an eye on this new python implementation: https://github.com/dropbox/pyston https://github.com/dropbox/pyston

munificent 12y ago

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.

hellbanner 12y ago

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

pmontra 12y ago
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 12y ago
  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.
nicarus1984 12y ago
Brython: http://www.brython.info http://www.brython.info
- hellbanner 12y ago
  Thanks, that's more of what I was looking for.

nostrademons 12y ago

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 12y ago
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?
- aardvark179 12y ago
  The code backing things like Numpy and Scipy is not small, has been well optimised over many years, and would be extremely difficult to reimplement at speed even with a faster Python. The freedom high level languages give tends to prevent many low level optimisations that are really useful for big maths and data routines. For the language I work on we were able to write macros and functions to allow our C libraries to continue to work when we changed our VM, but we've spent considerable effort optimising things so the C has to reach back into objects as little as possible, and we could only do this because recompilation and refactoring was okay.

Symmetry 12y ago

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 12y ago
Because LUA is much simpler, already porting LUJit to LUA5.3 is revealing hard as far as I understood
- ufo 12y ago
  LuaJIT "forked" from Lua during the 5.1 days. There are still some features from 5.1 that Mike (intentionally) didn't port to LuaJIT.
- yoklov 12y ago
  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 12y ago
    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 12y ago
      Ah, the note at the top of http://luajit.org/sponsors.html http://luajit.org/sponsors.html had made me think he was not.
mythz 12y ago
Because Mike Pall is a genius and likes working on LuaJIT so doesn't take much to sponsor him to work on it: http://luajit.org/sponsors.html http://luajit.org/sponsors.html

darkarmani 12y ago

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 12y ago
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.

bkeroack 12y ago

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 12y ago
Not all JavaScript runs in the browser
- _delirium 12y ago
  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 12y ago
    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 12y ago
      and Windows Script Host (wscript/cscript).

agounaris 12y ago

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 12y ago
I'm not sure how the comparison is relevant seeing as Sublime Text is written in C++. What am I missing?
- aikah 12y ago
  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.
TheAceOfHearts 12y ago
JS is considerably faster than both Ruby and Python, at least from benchmarks I've seen.

nkurz 12y ago

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?

digikata 12y ago
I think SO is starting the get the same problem that Wikipedia has been wrestling with - editor/moderator cliques. It may be a classic bureaucracy issue - on one hand they raise the quality bar by providing a higher level of consistency. On the other hand, they may drift from what might be considered reasonable from the point of view of more and more people outside the circle...
- nerfhammer 12y ago
  The theory of universal deletionism states that sites with extensive volunteer moderators will invariably tend towards bureaucracy and deletionism regardless of what regular users want as mods get bored and want to feel important You should see how excited the moderators get when they decide there's a new rule against some new kind of question
- sp332 12y ago
  SO was supposed to mitigate this effect by making people earn their mod rights. So you only get to call other people's questions off-topic if you have a track record of contributing to the site content yourself.
Liru 12y ago
I would say it's the latter. A majority of questions that I've found on SO that helped me solve a problem or answer a question have been marked as non-constructive. I don't know why people would do that from a logical perspective, but I can see how having the ability to moderate discussion would make one overzealous with this sort of thing.

emmelaich 12y ago

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.

deleted 12y ago

[deleted]

spullara 12y ago

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.

TheCondor 12y ago

Pypy is slower than v8?

masklinn 12y ago
Yes.

overgard 12y ago

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 12y ago
...if you can afford the memory requirements.
- overgard 12y ago
  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 12y ago
    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).

chaoky 12y ago

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.

est 12y ago
The difference is that SBCL compiler targets x86, Python runtime targets C.
- chaoky 12y ago
  SBCL targets x86, alpha, ARM, x86-64, and PPC in fact. Python doesn't actually target C, it targets a bytecode VM that's interpreted by C. which obviously is much easier to do. (there are many CL implmentations that use this approach as well eg ECL CLISP...) It just doesn't seem like Ruby or Python has the sophistication/resources yet to move their main implementations to native code, aggressively optimized compilers (yet). Which is unfortunate considering CL, Dylan and small talk got there first 30 years ago.
Solarsail 12y ago
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 12y ago

gcb0 12y ago

short answer: features.

ponytech 12y ago

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

andybak 12y ago

http://www.cdotson.com/2014/08/nodejs-vs-python-vs-pypy-a-simple-performance-comparison/ http://www.cdotson.com/2014/08/nodejs-vs-python-vs-pypy-a-si...

bshimmin 12y ago

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"!

KaiserPro 12y ago

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 12y ago
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-are-slow https://speakerdeck.com/alex/why-python-ruby-and-javascript-...
- seunosewa 12y ago
  Aren't things that are harder to optimize generally slower for precisely that reason?

walshemj 12y ago

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 12y ago
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.

amelius 12y ago

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 12y ago
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.