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

Ruby 2.6.0-preview2 released with JIT

ruby-lang.org

Post reply on HN
Print view View original

101–110 of 136 posts

Re: Ruby 2.6.0-preview2 released with JIT

#101

Post by pjmlp »

onli wrote: post #99
alberth wrote: post #85

Earlier quoted context omitted.

Why not? Graal is EPL, GPLv2, LGPL licensed. https://news.ycombinator.com/item?id=16862130

Because Oracle is Oracle, the most evil company in tech, the one most blatantly greedy. Look at what they pulled with Google. Oracle would wait till the tech usage grows and then use patents and API copyrights or whatever else they invent out of thin air to go after the players using its tech. The free license of Graal does not protect you from that, GPL2 specifically not. See https://www.gnu.org/licenses/rms-why-gpl…

Google abused Sun, took advantage that they were in a critical financial situation not able to sue, and when they crashed, did not move a finger to rescue the company assets.

Now Android has Google's own J++, limiting what kind of Java libraries are portable to the platform.

At the same time, some OEMs are adopting Android instead of Embedded Java, thus increasing the fragmentation about what Java libraries are actually portable.

Google just though they could let Sun close doors and get away with how they created their own J++.

Re: Ruby 2.6.0-preview2 released with JIT

#102

Post by pjmlp »

eslaught wrote: post #84
anarazel wrote: post #53

Earlier quoted context omitted.

> The main place where LLVM bites you is compatibility. There simply is none. This is a constaint drain on your resources and a lot of projects can't afford to keep up. There is even a project on LLVM's own home page which is was on 3.4 for a long time and has just recently upgraded to 3.8 [2]. Yea, it's annoying. For PostgreSQL I've decided to focus on the C API wherever possible exactly out of that reason. A bit mo…

I wonder if there will ever be a de facto API wrapper for LLVM. As it is, I'm aware of smaller efforts here and there, but other than SPIR-V [1] I'm not sure any are big enough to have long-term survivability potential. And even with SPIR-V I'm not sure if the momentum is really there or not. [1]: https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf

I think Apple's bitcode for iOS deployment is also more stable than the actual LLVM bitcode.

Re: Ruby 2.6.0-preview2 released with JIT

#104

Post by ksec »

codinghorror wrote: post #89
jashmatthews wrote: post #28

Earlier quoted context omitted.

Sinatra + Sequel is already very competitive in web performance with Go + Gin[1]. It's the Rails convenience stuff which slows things down massively. MJIT could probably bring Rails in line with Sinatra though. Between Ruby 1.8 and 2.5, performance has improved around 13x in tight loops[2]. The Rails performance issue has been massively overblown since 1.9 was released. Ruby 1.8 was a tree walking interpreter, so the…

> It's the Rails convenience stuff which slows things down massively. Yeah no kidding.. https://samsaffron.com/archive/2018/06/01/an-analysis-of-mem...

Or Specifically Active Record. Are we going to get Turbo Record soon? :)

Re: Ruby 2.6.0-preview2 released with JIT

#105

Post by ksec »

meesterdude wrote: post #35
jashmatthews wrote: post #28

Earlier quoted context omitted.

Sinatra + Sequel is already very competitive in web performance with Go + Gin[1]. It's the Rails convenience stuff which slows things down massively. MJIT could probably bring Rails in line with Sinatra though. Between Ruby 1.8 and 2.5, performance has improved around 13x in tight loops[2]. The Rails performance issue has been massively overblown since 1.9 was released. Ruby 1.8 was a tree walking interpreter, so the…

I would have never thought a ruby stack would come anywhere close to Go performance. The path to optimization used to mean abstracting the really crazy parts into a Go microservice for things that just needed absurd responsivity; but it's clear now that a slim ruby stack could also be very effective - and without needing to learn a new language. Worthwhile to at least explore before going Go. Nor did i know that twit…

>Nor did i know that twitter jumped out of rails before ruby got performant. Which means the argument that twitter outgrew rails isn't so correct anymore.

Twitter, even back in those days would have still outgrown today's Rails. It was Ruby that has gotten a lot faster. Not necessarily Rails.

Re: Ruby 2.6.0-preview2 released with JIT

#106

Post by ksec »

onli wrote: post #79
alberth wrote: post #2

What’s the current sentiment as for what will ultimately lead to the best performance of executing Ruby? From my uneducated perspective, seems like Graal VM could become the de facto Ruby deployment stack. https://github.com/oracle/truffleruby

I doubt that there are that many people that would allow Oracle tech to enter into a beloved language like Ruby, or the ecosystem.

Java, or OpenJDK is fully open sourced and GPL. I asked multiple times what are the risk in using it. And no one ever had an answer for it.

If the communities doesn't like where things are going, they could fork the whole thing and call it something else, like Coffee.

Re: Ruby 2.6.0-preview2 released with JIT

#107

Post by jashmatthews »

foldr wrote: post #98
jashmatthews wrote: post #78

Earlier quoted context omitted.

> Right, but historically there are lots of instances of projects that abandoned JITs because they didn't get a performance improvement. JIT compilation reduces instruction dispatch overhead, but it also, unless accompanied by sophisticated profiling techniques, adds the overhead of JIT compilation time, which can easily swamp the improvements. Yes. > Lua JIT is one of the most sophisticated dynamic language JITs out…

>The initial results of MJIT for simply removing the instruction dispatch overhead and doing some basic optimizations are a 30-230% performance increase on a small but real-world benchmark. No type specialization and specular optimization required So, this amounts to a small improvement for some types of code. Indeed, it is "easy" to get that by "just" using some basic JIT techniques. The trick is to get consistently…

> The trick is to get consistently better performance across the board.

This will come with the rest of the opimizations Takashi has planned for Ruby 2.6. Ruby-Ruby method inlining, which is almost finished, is a huge one for improving Rails performance. IMHO there's no real point talking about Rails until it's working in some form.

> >I've just committed the initial JIT compiler for Ruby. It's not still so fast yet (especially it's performing badly with Rails for now), but we have much time to improve it until Ruby 2.6 (or 3.0) release.

It turned out this wasn't even testing MJIT with Rails because https://twitter.com/samsaffron/status/963219086833434624

Re: Ruby 2.6.0-preview2 released with JIT

#108

Post by jashmatthews »

ksec wrote: post #105
meesterdude wrote: post #35

Earlier quoted context omitted.

I would have never thought a ruby stack would come anywhere close to Go performance. The path to optimization used to mean abstracting the really crazy parts into a Go microservice for things that just needed absurd responsivity; but it's clear now that a slim ruby stack could also be very effective - and without needing to learn a new language. Worthwhile to at least explore before going Go. Nor did i know that twit…

>Nor did i know that twitter jumped out of rails before ruby got performant. Which means the argument that twitter outgrew rails isn't so correct anymore. Twitter, even back in those days would have still outgrown today's Rails. It was Ruby that has gotten a lot faster. Not necessarily Rails.

From what I understand, the biggest issue was their product required fast fan out messaging. Tumblr, for example, is still huge but can get away with 1000 lines of PHP for their feed: https://news.ycombinator.com/item?id=17154403

Re: Ruby 2.6.0-preview2 released with JIT

#109

Post by shellac »

chrisseaton wrote: post #97
jashmatthews wrote: post #96

Earlier quoted context omitted.

True! I just checked again and Topaz is indeed almost twice as fast as CRuby on optcarrot. I think I got it mixed up with the non-JIT Rubinius numbers. It'a shame Topaz was never really "finished".

One of the main Topaz developers now works on the Python equivalent of TruffleRuby.

You mean a python implementation on truffle? Or ruby on something truffle-like on RPython?

Re: Ruby 2.6.0-preview2 released with JIT

#110

Post by cpuguy83 »

pjungwir wrote: post #15

Congratulations Ruby team! I'm excited to hear about the performance improvements. It seems like JIT could be a huge win since calling a method requires checking all kinds of possibilities that are almost always not used, but might be. I would love to keep all the power & fun of Ruby without worrying so much about performance. Speaking of optimizing method calls: now that it's been a few years, I wonder what Ruby fol…

Have you tried jruby?
Post reply on HN