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

41–49 of 49 posts

Re: Projects That Are Making Fast Ruby a Reality

#41

Post by ksec »

mbreedlove wrote: post #16

Ruby+Truffle+Graal support was removed from rbenv (ruby-build, actually) on Jan. 1st. Apparently, "the new builds are click-through licensed" and will be based off "Oracle's JDK rather than Open JDK." I can't wait for Oracle to die. commit: https://github.com/rbenv/ruby-build/commit/ca0e1474fcf3e2025... pull request: https://github.com/rbenv/ruby-build/pull/864

You can still get the build with OpenJDK yourself i think, the reason they use Oracle JDK is that no body has access to it, bu having a build with Oracle JDK helps with this issue.

Re: Projects That Are Making Fast Ruby a Reality

#42

Post by ksec »

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…

Ruby is slow, but enough for many things. Rails is slow, dog slow. And no one in Rails team care much.

While it is slightly unfair, most within the Ruby on Rails Community do not care about speed at all.

PHP has Facebook, Java has Sun and other Enterprise, JS has Google V8, as well as Mozilla / Apple providing competition, Lua has Mike Pall. Basically all these Dynamic Langauges has had million of dollars / man hours working on it for a long time.

In Ruby? If it wasn't for ko1 YARV Ruby is still very slow here.

So why all of a sudden we have two solution here that offer a magnitude of speed increase? My guess is that it created an interest within the Academic, VM Research Community, if they have to prove their VM ( OMR / Graal ) to work, they will have to choose one of the hardest, yet to optimized language to work on. I guess that is why both effort happens to be on Ruby.

Re: Projects That Are Making Fast Ruby a Reality

#43

Post by mike_hearn »

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?

The dynamic its of Java are not its type system, they're things like late dynamic linking.

Re: Projects That Are Making Fast Ruby a Reality

#44

Post by mike_hearn »

mbreedlove wrote: post #16

Ruby+Truffle+Graal support was removed from rbenv (ruby-build, actually) on Jan. 1st. Apparently, "the new builds are click-through licensed" and will be based off "Oracle's JDK rather than Open JDK." I can't wait for Oracle to die. commit: https://github.com/rbenv/ruby-build/commit/ca0e1474fcf3e2025... pull request: https://github.com/rbenv/ruby-build/pull/864

That's ridiculous. Firstly, all the Graal/Truffle/Ruby work is open source. The fact that they prefer not to maintain lots of different builds and their build infrastructure produces a mixed open/proprietary binary doesn't change the fact that you can get all the work for free.

Secondly, Oracle funded all of this work! Don't you think that's a little ungrateful? How relevant do you think faster Ruby even is to Oracle's core business? Less relevant than fast JS is to Google certainly, and yet, not only have they been funding a large cutting-edge research effort for years ... they gave the results away as open source too.

Sometimes I think people have lost perspective. I remember programming for Windows in the 1990s, when you were expected to pay for even basic things like treeview widgets or networking libraries. Now you get full blown JIT compilers for dynamic languages for nothing and people complain :(

Re: Projects That Are Making Fast Ruby a Reality

#45

Post by mike_hearn »

ch4s3 wrote: post #15
eonwe wrote: post #6

Earlier quoted context omitted.

In some cases they could perhaps do the same thing that's done with Ruby: interpret the C-extensions. It's not as crazy as it may seem and JRuby benefits hugely from it: http://chrisseaton.com/rubytruffle/cext/

I'm pretty sure they aim to interpret the c, but I don't want to speak for Chris.

They don't just interpret the C, they JIT compile it.

Re: Projects That Are Making Fast Ruby a Reality

#46

Post by mike_hearn »

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.

JVM hello world can be about 50 milliseconds. The issue is the Graal/JRuby overhead. Bear in mind that Graal is a JIT compiler that is itself written in Java. So it has to compile itself before it gets fast at compiling anything else!

There is an AOT mode being worked on that should solve that, but it's not open source.

Re: Projects That Are Making Fast Ruby a Reality

#47

Post by jerf »

igouy wrote: post #40
jerf wrote: post #28

Earlier quoted context omitted.

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

The bizarre part to me is putting the right hand side of the graph up first. If the left side was first, I wouldn't have commented.

Re: Projects That Are Making Fast Ruby a Reality

#48

Post by MrBra »

VeejayRampay wrote: post #3
MrBra wrote: post #2

some discussion: https://www.reddit.com/r/ruby/comments/42xxsp/flammarion_the...

While the Reddit discussion you linked to is interesting, I'm not sure how relevant it is to the article.

Oops sorry you are right, I was supposed to post that inside the Flammarion post that I made just before this one at https://news.ycombinator.com/item?id=11064890, got a bit confused :)

Re: Projects That Are Making Fast Ruby a Reality

#49

Post by igouy »

jerf wrote: post #47
igouy wrote: post #40

Earlier quoted context omitted.

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

The bizarre part to me is putting the right hand side of the graph up first. If the left side was first, I wouldn't have commented.

Is there a right hand side and left hand side here? --

http://benchmarksgame.alioth.debian.org/u32/which-programs-a...

Post reply on HN