Hacker News Reader

Comment by jordanthoms | Hacker News Reader

I just wish someone would find it in their economic interest to do for Ruby what V8 did for Javascript. Doesn't seem like there is any fundamental reason for Ruby to run slower - it's just a matter of putting the (substantial) resources in to make it happen. JRuby might be the solution to this though, if they can catch up with MRI's functionality and stay on par.

View on HN

> Doesn't seem like there is any fundamental reason for Ruby to run slower.

I think that all the metaprogramming magic that Ruby allows is at odds with speed. That is not to say that it's impossible to make it fast, but it's probably tricky.

> I think that all the metaprogramming magic that Ruby allows is at odds with speed.

I don't think so, Java and C# also have metaprogramming (reflection, class loading, bytecode manipulation) and they are still plenty fast.

Ruby's liability is that it's dynamically typed, and this puts a hard limit on how fast it can be (and also on how toolable it can be, but that's a separate discussion).

I mean metaprogramming support is kind of a spectrum and neither Java nor C# support it to the same degree as Ruby. For one thing and for another, C# and Java have large corporations supporting those languages which try very hard to make the runtimes fast so it's not a fair comparison.

Then compare it with compilers for dynamic languages like Lisp, Scheme, Dylan, Smalltalk...

I said tricky, not impossible but I will, even though I'm not sure I'm really qualified to talk about these languages for one thing and for another, I think that these sort of comparisons are pretty pointless to begin with. Also I'm not sure where you are exactly going with your comment.

Lisp + Scheme: I mean if nothing else, people have been trying to make them fast for the last more than half of century. Plus AFAIK most Lisp meta-programming code is generated during compile time through macros not during run-time.

Dylan: I don't really know anything about Dylan but it seems to have come out of Apple and CMU, so there's that. Plus it seems to be just a Lisp dialect.

Smalltalk: You consider Smalltalk fast? Lol.

>Smalltalk: You consider Smalltalk fast? Lol.

Well, any Smalltalk JIT beat the standard Ruby implementation hands down, what can I say?!

Reflection in Java is in fact slow. The difference is that in ruby that stuff is pervasive, in Java you rarely use reflection.

Reflection is also very slow in C#

Not it is not. A lot of basic metadata is cached and quickly accessible.

How much metaprogramming is normally going on behind the scenes in a typical Ruby/Rails app vs Java or C# though?

If you do a lot of reflection in Java then you'll end up with some pretty crummy performance, but the average Java program doesn't have much.

It's not just the actual metaprogramming, i.e. define_method is slow. It's also the runtime implications of metaprogramming being possible, i.e. needing to dispatch each and every method call dynamically just in case someone called define_method. Java can turn every method call into a function pointer at compile time.

Metaprogramming is code using define_method (optionally closing over local variables), instance_eval, and stuff of that nature. Even with bytecode manipulation they would be very difficult to emulate in Java/C++ and would be quite slow.

That said, JavaScript is not far off of Ruby's monkeying capabilities and yet pretty darned fast.

>I think that all the metaprogramming magic that Ruby allows is at odds with speed

Well, Javascript allows almost as much metaprogramming (and with ES6 proxies and such, exactly as much).

a.) Unless, you use eval profusely, it really does not. I'm not sure how much metaprogramming power proxies really give you.

b.) It also has Google pumping a LOT of resources into making it fast.

That doesn't seem right. Can you give an example? I use lots of js metaprogramming, but it mostly involves wrapping and passing functions, mixing in methods and dynamic getters etc. I don't think I've ever actually had to use eval, or anything eval-like.

OTOH, grep for instance_eval and class_eval in rails source.

Right, you should never ever use eval but I don't think that a lot of the things that are commonly done in Ruby could be achieved in JS without eval. And what you are talking about is not exactly meta-programming.

> OTOH, grep for instance_eval and class_eval in rails source.

I mean what's your point. Yes, I realize that both are used profusely, which is one of the things that this discussion is about.

> And what you are talking about is not exactly meta-programming.

I didn't describe metaprogramming, just how I usually see common metaprogramming "magic" implemented in javascript. The only reason you'd really need eval in js metaprogramming is if for some semantic reason it was nicer to accept a String of javascript somewhere. Afaik eval doesn't "get" you anything in javascript (it doesn't "unlock" private closures scope or anything, and context-injection is available using #call or #apply) and I almost never see it used, unless I am forgetting something (totally possible, I've been up all night)

> I mean what's your point. Yes, I realize that both are used profusely

My point is I don't see eval used profusely in javascript, which contradicts your assertion in a).

Edit: nvm, I stand corrected: (function(){var x = 1; eval('console.log(x)'); })() prints 1. Neat. But still, I do not see this often used, the callback + context passing approach is much more common.

EDIT: Formatting

For a while Phusion offered Ruby Enterprise Edition[1] which made improvements on the Ruby 1.8.7 interpreter including improvements such as:

> * A “copy-on-write friendly” garbage collector, capable of reducing Ruby on Rails applications’ memory usage by 33% on average.

> * The tcmalloc memory allocator, which lowers overall memory usage and boosts memory allocation speed. > * The ability to performance tune the garbage collector.

> * The MBARI patch set, for improved garbage collection efficiency.

> * Various analysis and debugging features.

They've since dropped support of it because:

> * A copy-on-write patch has recently been checked into Ruby 2.0.

> * Many of the patches in Ruby Enterprise Edition are simply not necessary in 1.9.

So it sounds like many of the improvements offered in Ruby Enterprise Edition 1.8.7 have been rolled into Ruby 2.0. Do you have any suggestions of what might be included in a Ruby Enterprise Edition 2.0?

[1] http://blog.phusion.nl/category/ruby-enterprise-edition/

Is there a Ruby Startup Edition? :)

I'm from Phusion.

There will be no Ruby Enterprise Edition 2.0. REE has been discontinued.

The original goal of REE was to incorporate our copy-on-write friendliness patches into Ruby, and to distribute it in a user-friendly form. Since then, its goal has been extended to include other useful patches as well. We've discontinued Ruby Enterprise Edition for the following reasons:

1. Ruby 2.0 incorporates (or obsoletes) all these improvements.

2. Ruby 1.8 is no longer supported even by its upstream authors.

3. We have limited resources and wanted to focus on Phusion Passenger. Since the discontinuation of REE we've made tremendous improvements in Passenger.

The plan was to hand over maintainership to another interested party. Unfortunately nobody volunteered. http://blog.phusion.nl/2012/02/21/ruby-enterprise-edition-1-...

Twitter was in a nice position to better Ruby in terms of performance, though they chickened out and escaped to Scala.

Even Twitter went public recently and posed to challenge big guys such as Google, Facebook, they've lost my respect as a technology company.

That's a bit of an oversimplification. Here is a more in depth explanation in the form of a video of a talk called 'Twitter: From Ruby on Rails to the JVM'[1] from O'Reilly Con by Twitter engineer Raffi Krikorian who leads the Applications Services group.

[1] http://www.youtube.com/watch?v=ohHdZXnsNi8

Didn't watch this video. But as far as I recalled back then, the guys at Twitter was complaining about the slowness of Rails and MRI, as Rails was not asynchronous and MRI was CPU-bound, so instead of fixing this root cause to apply the tricks from V8 to Javascript to improve Ruby，they chose the more "pragmatic" way to use Netty that is asynchronous and Scala that is way faster.

I don't accuse them of not saving the world, but Ruby and Rails lost a great opportunity to dominate the web community. If Rails were as performant as Node.js, I doubt lots of companies would change gears.

I think organization type plays a role here too. ROR is an excellent fit for startups where speed of iteration is paramount; but once an organization settles on a business model and functionality matures a bit, the code stops changing so rapidly and the ability to do rapid development is not important any longer. At the same time performance becomes increasingly critical due to costs of scale. Hence a switch to something like scala makes perfect sense.

> I don't accuse them of not saving the world, but Ruby and Rails lost a great opportunity to dominate the web community.

They didn't lose this opportunity because of Twitter, they lost it because the fact that Ruby is dynamically typed puts a hard limit on how fast it can be. Twitter tried very hard to make it scale before making the decision to switch to Java, and they just couldn't do it.

The task was just impossible, switching to Java was the only reasonable decision given their constraints.

Javascript is also a dynamically typed script language, which Google managed to make at least one order of magnitude faster with V8. It's likely same tricks can be applied to Ruby.

Google has a full-time team of some of the best compiler writers in the world wholly dedicated to tuning Javascript, and they have spent literally years to get it to perform how it does today, and it's still far from competing with the JVM, and will likely never be able to do basic things such as multithreading and proper type safety. Twitter was absolutely right in doing what they did.

https://www.paypal-engineering.com/2013/11/22/node-js-at-pay...

Seems that node.js outperforms the JVM for WebDev nowadays.

Otoh they don't use some top secret innovations but decades old techniques accessible to everyone.

And language benchmarks don't tell the whole story. In Java, idiomatic and typical code will be optimized very well whereas in Javascript such code runs easily at least an order of magnitude slower than its potential. Try to run some idiomatic JS through https://github.com/petkaantonov/nodeperf/ and see it explode :)

So even if Javascript can be shown in some benchmark to close on the JVM, the benchmarks are ignoring the fact that you cannot write Javascript carelessly to get anywhere near those speeds unlike with Java.

There are lots of dynamic languages with native compilers around, offering speeds that beat Ruby's canonical implementation.

Are you aware that Hotspot, Sun/Oracle's JIT compiler was actually developed for a Smalltalk dialect, Self?

LuaJIT shows dynamically typed languages can be fast. And even plain Lua is enormously faster than Ruby. Complexity costs, not necessarily being dynamic.

> Twitter was in a nice position to better Ruby in terms of performance, though they chickened out and escaped to Scala.

Actually, they escaped to the JVM, and if their job reqs are any indication, they hire massively for Java engineer positions and hardly at all for Scala ones.

I wouldn't call that chickening out, more common sense.

Rails is great for prototypes and toy apps, but once you start needing scale, it's simply not up to the task.

I work at Twitter. Actually we use very little Java while almost every service is written in Scala.

> Rails is great for toy apps

This gets said here a lot. What about GitHub and Shopify, and ...? Are those toy apps?

I'm curious too how much of each of these is still built on Rails, and how much has been tweaked, tuned and rewritten to be 'inspired' by Rails, but no longer Rails.

Good question. I would say it varies, but after all they are mostly likely not changing things dramatically, at least thats what you get from watching talks from both companies[1].

[1] http://www.slideshare.net/jduff/how-shopify-scales-rails-204...

I've browsed this discussion and I must miss something?

You seem to imply Ruby's/Rails' speed matter?

Usually, the DB is the limiting factor in most web applications, few should need to execute more than a few milliseconds of (even) Ruby per page load. That is why people use scripting languages, after all.

Shouldn't this slowdown be a problem in the ORM for this version? I'd look at access patterns for normal requests for the new Rails version and the old. How has the SQL changed?

Sure, Twitter is different since that probably is processor bound.

(Since RoR is a popular framework with lots of eyes, there shouldn't be something simple with e.g. configuring the web server, locking etc.)

GitHub is still on Rails 2.3 and has not upgraded partially due to performance concerns*

*From an episode of Ruby Rogues with Zach Holman

I guess if you wanted Scala programmers (and for the long-term, not just a 3 month contract) you would hire for Java programmers as a) there's a lot more of them so the talent pool is larger, b) teaching a Java guy/gal Scala isn't going to be difficult, and c) they may be cheaper to get (a pure guess)?

Twitter is probably the best technology company that has ever helped this community. They built bootstrap to help start of all your companies, and open sourced Mesos for when you get big. If rvm was saveable they would have not rewrote that mono app into services. A tuned JVM is a great compromise of performance and development flexibility.

They switched to the right tool for the job, with great success. They've contributed heaps of open source code to the community. (https://github.com/twitter)

But they didn't magically make Rails fast, so screw them?

This presumes the request time here is due to time in the CPU. Odds are what probably happened here is some underlying algorithmic or I/O change in Rails that would have slowed things down proportionally regardless of how slow the interpreter is.

One of the great problems that plagues MRI is the lack of real concurrency with its global interpreter lock and the single-threaded, single-generation, stop-the-world garbage collector. That is many years behind the state-of-the-art as far as runtimes go.

Dynamic webpages consisting of several widgets are quite amenable to parallelization by rendering subviews separately and just assembling them in the layout in a final step. With parallelism slow single-threaded performance can still yield reasonable response-times if you can throw multiple cores at the problem.

But even if you have parallelism, a slow single-threaded GC would halt all of those threads, again affecting your response times.

I don't know about V8, but mozilla's JS is suffering from similar issues. They're currently working on generational GC and it's promising to provide quite some speed-up. But the javascript runtime, just like ruby, was not designed with parallelism in mind, that's why we're seeing those webworkers which essentially spawn an isolated javascript environment. Simply because it's hard to tack on parallelism as an afterthought.

Similarly one of Ruby 2.1's major performance boosts stems from the generational GC.

There was a good talk by Charles Nutter at Baruco this year about JRuby. It looks to be pretty much there, and from the benchmarks performance looks a lot better than MRI.

http://www.youtube.com/watch?v=8ZEAwWLwmfQ

Last time I looked into it jruby itself was faster than MRI, especially if you take multithreading into account. But rails-on-jruby was a different story because some metaprogramming things that rails does are terrible for the JIT compilers.

Charles ominously called "dark matter" inside rails.

Reply on news.ycombinator.com