Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Projects That Are Making Fast Ruby a Reality

sitepoint.com

Post reply on HN
Print view View original

21–30 of 49 posts

Re: Projects That Are Making Fast Ruby a Reality

#21

Post by kemiller »

jaredcwhite wrote: post #8

OK folks, help me out here. I'm not trying to troll, this is a genuine question. In the not-so-distant-past, one of the reasons why a good number of developers/projects announced they were moving away from Ruby and using other languages/compilers was due to Ruby's slow performance—and not just that Ruby was slow, but that Ruby was slow due to the actual nature of the language. In other words, Ruby was destined to alw…

I am still pretty skeptical. We've had very promising implementations of 80-90% of the language, which faltered once they got to the less tractable parts of the language. Not saying it can't be done, but definitely saying I'll believe it when I see it live on a few legacy production sites.

Re: Projects That Are Making Fast Ruby a Reality

#22

Post by ludamad »

chinhodado wrote: post #17
shanemhansen wrote: post #13

Earlier quoted context omitted.

I think the short answer is making a dynamic language really fast is really hard. You can do it, but historically you've needed to be Sun or Google to pull it off. Sun made java fast. Google made javascript pretty fast. So ruby either needed to piggy back on someone else's work (jvm or whatever) or get some next-level-smart vm developers. Even then, people have written about how ruby presents some serious challenges.

Why is Java a dynamic language? Isn't Java statically typed?

Dynamically typed languages essentially have something like Java's Object type as the type of everything. Using wide types like that and interfaces in Java, you easily have dynamic traits in your code.

Re: Projects That Are Making Fast Ruby a Reality

#23

Post by frandroid »

shanemhansen wrote: post #13
jaredcwhite wrote: post #8

OK folks, help me out here. I'm not trying to troll, this is a genuine question. In the not-so-distant-past, one of the reasons why a good number of developers/projects announced they were moving away from Ruby and using other languages/compilers was due to Ruby's slow performance—and not just that Ruby was slow, but that Ruby was slow due to the actual nature of the language. In other words, Ruby was destined to alw…

I think the short answer is making a dynamic language really fast is really hard. You can do it, but historically you've needed to be Sun or Google to pull it off. Sun made java fast. Google made javascript pretty fast. So ruby either needed to piggy back on someone else's work (jvm or whatever) or get some next-level-smart vm developers. Even then, people have written about how ruby presents some serious challenges.

> Google made javascript pretty fast.

A small outsourced team in Denmark did, actually. Sure, they were hired by Google, but that kind of belies your argument that only a large corp can do this, no?

Re: Projects That Are Making Fast Ruby a Reality

#24

Post by pmarreck »

jaredcwhite wrote: post #8

OK folks, help me out here. I'm not trying to troll, this is a genuine question. In the not-so-distant-past, one of the reasons why a good number of developers/projects announced they were moving away from Ruby and using other languages/compilers was due to Ruby's slow performance—and not just that Ruby was slow, but that Ruby was slow due to the actual nature of the language. In other words, Ruby was destined to alw…

When you work on any medium-to-large Rails project, and you want to run a quick unit test to test some new functionality for your new class that inherits from, say, something in ActiveSupport, and AS pulls in a bunch of gem code that is opaque to you, and your class names a module that wasn't loaded yet and so it gets dynamically loaded (warning: global mutable state has been altered, causing weird load-order bugs), and then THAT module triggers other loads of things it depends on, and one of those monkeypatches a bug in an old version of some gem which has actually since been fixed but is still being monkeypatched with old code and causes a corner-case bug that you haven't discovered yet (shameless self-plug: I actually wrote a gem to help manage that stuff: https://github.com/pmarreck/pachinko), and your unit test ends up taking, like, 30 seconds to just load your stack of dependencies... (I've actually seen 40 sec stack loads, in the wild, at past jobs)

... Ruby is still slow.

Sure, there are band-aids to assist with that stuff (Guard, Zeus, etc.), but you're still dealing with spaghetti-dependency, mutating-global-state, side-effecting hell.

Which is exactly why I now want to work with Elixir and Phoenix instead.

Note: It IS possible to write Ruby in such a way that almost none of this stuff actually comes to pass. But even if you do, you'll have to deal with an entire library of code that does not.

Re: Projects That Are Making Fast Ruby a Reality

#25

Post by ch4s3 »

jaredcwhite wrote: post #8

OK folks, help me out here. I'm not trying to troll, this is a genuine question. In the not-so-distant-past, one of the reasons why a good number of developers/projects announced they were moving away from Ruby and using other languages/compilers was due to Ruby's slow performance—and not just that Ruby was slow, but that Ruby was slow due to the actual nature of the language. In other words, Ruby was destined to alw…

>>Were the "Ruby will always be slow" people simply wrong? Well, yes. It was slow in the same way that python was slow. If you move all of the slow stuff to C or JIT it or whatever, it can be as fast as almost any language can be, with a few minor caveats.

MAth is tricky in pure Ruby for example, the spec does a check on integers to make sure they can ben contained in what we'll call Int, and don't need to be transformed into BigInt. Ruby does this check every time an integer changes, which is wildly expensive, but super convenient. Its really nice for small N, but you shouldn't add n-dimensional arrays this way.

Also, run time meta-programming is pretty slow, especially if you lean on #method_missing, that's hard to fix.

Those two things aside, there aren't any reasons that Ruby can't be made much faster, in fact for many use cases JRuby is presently very fast and with Java interop you can leverage Java libs.

Re: Projects That Are Making Fast Ruby a Reality

#27

Post by lettergram »

jaredcwhite wrote: post #8

OK folks, help me out here. I'm not trying to troll, this is a genuine question. In the not-so-distant-past, one of the reasons why a good number of developers/projects announced they were moving away from Ruby and using other languages/compilers was due to Ruby's slow performance—and not just that Ruby was slow, but that Ruby was slow due to the actual nature of the language. In other words, Ruby was destined to alw…

> Were the "Ruby will always be slow" people simply wrong?

Simple answer, yes. Not saying that Ruby is fast now, however Ruby doesn't necessarily always have to be slow. Just like any languages/framework/etc. It can be made faster, although the amount of work to get there may be substantial.

At the time ruby was really slow, and with no real progress and a waning number of groups working to improve it. Now, it appears people are making progress and working on it.

Re: Projects That Are Making Fast Ruby a Reality

#28

Post by jerf »

shanemhansen wrote: post #13
jaredcwhite wrote: post #8

OK folks, help me out here. I'm not trying to troll, this is a genuine question. In the not-so-distant-past, one of the reasons why a good number of developers/projects announced they were moving away from Ruby and using other languages/compilers was due to Ruby's slow performance—and not just that Ruby was slow, but that Ruby was slow due to the actual nature of the language. In other words, Ruby was destined to alw…

I think the short answer is making a dynamic language really fast is really hard. You can do it, but historically you've needed to be Sun or Google to pull it off. Sun made java fast. Google made javascript pretty fast. So ruby either needed to piggy back on someone else's work (jvm or whatever) or get some next-level-smart vm developers. Even then, people have written about how ruby presents some serious challenges.

"Sun made java fast. Google made javascript pretty fast."

But there's a lot of daylight between what you call "fast" and "pretty fast". For all the effort that has been poured into Javascript, it remains a slow language for general-purpose programming. That's why asm.js could speed up JS as much as it could; if JS was already "C fast" nobody would have needed or used asm.js. And nobody would talk about Web Assembly if JS was already that fast.

It is definitely true that the bytecode interpreters that pretty much all the dynamic languages started with were not the last words in speed, and things like JITs and such have sped them up a lot. When the dynamic interpreted languages were routinely 50x slower than C, there was room for improvement. But there seems to be a wall at around 10x slower than C for general-purpose programming [1] that the languages are having a hard time penetrating from what I can see: http://benchmarksgame.alioth.debian.org/u64q/which-programs-... (Bizarrely, they've broken out into two graphs, with the slower languages getting graphed first. It's actually one big graph, I think.)

Having heard people say for many, many years that "languages don't have speeds, only implementations do", I no longer believe that. After vast quantities of time and effort have been poured into the dynamic languages, they're still slow. Just not as slow as they used to be, and often with significantly larger memory footprints to get to "not as slow as they used to be".

NB: Pity LuaJIT is no longer on that site. If you design your "dynamic" language for speed, you can do a lot better. But I've not seen proof you can design a language for convenience and dynamicness and then come along 15+ years later and make it C-fast.

[1]: I have to qualify that, because any JIT worth its salt can optimize certain very advantageous code down to C speed. As the benchmark contains some of these tasks, you can see the dynamic languages with decent JITs reach their tails down to near C-speed in that graph. However, being able to optimize code that loops over integers and adds them up to C speed or even beyond if you automatically use SIMD doesn't mean that you're going to C performance in general.

Re: Projects That Are Making Fast Ruby a Reality

#29

Post by whistlerbrk »

lettergram wrote: post #27
jaredcwhite wrote: post #8

OK folks, help me out here. I'm not trying to troll, this is a genuine question. In the not-so-distant-past, one of the reasons why a good number of developers/projects announced they were moving away from Ruby and using other languages/compilers was due to Ruby's slow performance—and not just that Ruby was slow, but that Ruby was slow due to the actual nature of the language. In other words, Ruby was destined to alw…

> Were the "Ruby will always be slow" people simply wrong? Simple answer, yes. Not saying that Ruby is fast now, however Ruby doesn't necessarily always have to be slow. Just like any languages/framework/etc. It can be made faster, although the amount of work to get there may be substantial. At the time ruby was really slow, and with no real progress and a waning number of groups working to improve it. Now, it appear…

This is correct, I would highly highly recommend reading "Deoptimizing Ruby" available here, http://chrisseaton.com/rubytruffle/deoptimizing/ for more information on WHY making Ruby fast is hard and what the Truffle+Graal does to make it fast.

Re: Projects That Are Making Fast Ruby a Reality

#30

Post by stcredzero »

frandroid wrote: post #23
shanemhansen wrote: post #13

Earlier quoted context omitted.

I think the short answer is making a dynamic language really fast is really hard. You can do it, but historically you've needed to be Sun or Google to pull it off. Sun made java fast. Google made javascript pretty fast. So ruby either needed to piggy back on someone else's work (jvm or whatever) or get some next-level-smart vm developers. Even then, people have written about how ruby presents some serious challenges.

> Google made javascript pretty fast. A small outsourced team in Denmark did, actually. Sure, they were hired by Google, but that kind of belies your argument that only a large corp can do this, no?

Also, Sun making Java fast was due to Hotspot, which was inspired by work on Self, the successor to Smalltalk.
Post reply on HN