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

31–40 of 49 posts

Re: Projects That Are Making Fast Ruby a Reality

#31

Post by asolove »

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?

For sure, a small team can do the work. The question is: who will pay them to? Your five smart compiler friends could maybe get contract work making specific hotspots a bit faster for some specific medium-sized company.

But who is going to finance them rebuilding the whole approach from scratch over several years, in a way that benefits a whole platform rather than just their company, and shelter the team from short-term priorities and reorgs?

That takes a big company that has an enormous economic stake in the entire platform.

Re: Projects That Are Making Fast Ruby a Reality

#32

Post by reissbaker »

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…

> if Ruby can actually be a relatively fast language...

I think that "if" still is a pretty big if. If Truffle/Graal ships and is able to run Rails at a 30x perf improvement, that would be huge. Right now there's still some work left there, and the original article notes that they haven't been able to replicate the claimed perf gains. What's also tricky is that while there can often be "performance sweet spots" [1] in dynamic languages, it's very easy to accidentally fall out of them and make most of your app slow even if theoretically it's possible for it to run faster.

The TechEmpower benchmarks [2] are pretty damning when it comes to Ruby's current performance relative to other languages. For some projects, eventually it's easier to switch to a different language that's already fast rather than investing into speeding up a slow one.

[1] http://mrale.ph/blog/2011/11/05/the-trap-of-the-performance-... [2] https://www.techempower.com/benchmarks/

Re: Projects That Are Making Fast Ruby a Reality

#33

Post by ch4s3 »

whistlerbrk wrote: post #29
lettergram wrote: post #27

Earlier quoted context omitted.

> 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.

That's a great read even if you aren't a Rubyist, especially the discussion of monkey patching.

Re: Projects That Are Making Fast Ruby a Reality

#34

Post by omaranto »

ch4s3 wrote: post #26
singularity2001 wrote: post #9

wow, 11 sec to run hello world: ``` ~$ time ruby -X+T -e 'puts Truffle.graal?' real 0m3.843s user 0m11.867s ```

That is the JVM startup time. If you allow the vm to warm up and and JIT to kick in, you'll see significant gains.

The JVM startup time is very small nowadays (seriously, write a Hello World! class in Java to test it if you don't believe me). The culprit is probably JRuby's startup time (and maybe the Truffle + Graal version of JRuby is even slower to startup than regular JRuby).

Re: Projects That Are Making Fast Ruby a Reality

#35

Post by omaranto »

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

And Mike Pall made Lua pretty damn fast.

Re: Projects That Are Making Fast Ruby a Reality

#36

Post by ch4s3 »

omaranto wrote: post #34
ch4s3 wrote: post #26

Earlier quoted context omitted.

That is the JVM startup time. If you allow the vm to warm up and and JIT to kick in, you'll see significant gains.

The JVM startup time is very small nowadays (seriously, write a Hello World! class in Java to test it if you don't believe me). The culprit is probably JRuby's startup time (and maybe the Truffle + Graal version of JRuby is even slower to startup than regular JRuby).

Yeah, I'm oversimplifying. However, compared to MRI, the JVM starts up quite slowly. Pile on JRuby et al and you end up with an even slower time to go. I think the JRuby people have been very focused on feature parity, interop, and bug fixes so I'm not sure they've prioritized startup time. For now, I'm happy with that, I don't restart my app that often, basically only on deploys.

Re: Projects That Are Making Fast Ruby a Reality

#37

Post by heavenlyhash »

jerf wrote: post #28
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.

"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 i…

I'd offer one riff further on all that: indeed, core languages do continue to influence speed on a scale that implementation details can only batter at the edges of.

In Ruby's case, ObjectSpace is worth taking a peek at for an example: http://ruby-doc.org/core-2.3.0/ObjectSpace.html We have here a method that counts all objects, by type, in the entire heap. How, exactly, could one propose to parallelize that? Not Easily. Does that leak synchronization needs -- and thus performance implications -- into every layer of GC, scheduling, class/module definition loading, and so on? Yup.

Doesn't matter how much you approach the pinnacle of excellence in JIT. Some definitions of operational parameters are just going to be expensive. Other languages that simply don't allow such operations are at a permanent advantage. There is no such thing as engineering without tradeoffs.

Re: Projects That Are Making Fast Ruby a Reality

#38

Post by Eridrus »

nly wrote: post #18
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.

> Sun made java fast. Arguably one of the most prevalent Java platforms these days, Android, doesn't JIT... it compiles AoT. Java is actually a great example of languages with static type systems being easier to optimize, whereas the JVM is the new hotness for everything dynamic.

The mobile environment really benefits AoT though; you care about CPU usage more due to battery life and you really care about startup performance because slow starts make your platform seem sluggish.

Java's main usage (outside of Android) atm is on the server-side, and startup time isn't a huge deal there and you care about cost more than actual perf.

Re: Projects That Are Making Fast Ruby a Reality

#39

Post by jordanthoms »

omaranto wrote: post #34
ch4s3 wrote: post #26

Earlier quoted context omitted.

That is the JVM startup time. If you allow the vm to warm up and and JIT to kick in, you'll see significant gains.

The JVM startup time is very small nowadays (seriously, write a Hello World! class in Java to test it if you don't believe me). The culprit is probably JRuby's startup time (and maybe the Truffle + Graal version of JRuby is even slower to startup than regular JRuby).

Startup is slow right now, but there is a project underway at Oracle Labs which will reduce it to a similar level as MRI.

Re: Projects That Are Making Fast Ruby a Reality

#40

Post by igouy »

jerf wrote: post #28
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.

"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 i…

>> Bizarrely, they've broken out into two graphs, with the slower languages getting graphed first. How wide is your phone? :-)

(It's just to confuse people who insist on saying this language is first, this language is second … as though rank order was useful information.)

Post reply on HN