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

91–100 of 136 posts

Re: Ruby 2.6.0-preview2 released with JIT

#91

Post by transfire »

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…

As the creator of Ruby Facets, refinements were high on the todo list. Unfortunately the syntax of refinements led to an ugly problem... I would have to support two identical code bases to support both usages (monkey patching and refinement), the only difference being boilerplate code. I could find no way around it. That seemed ludicrous to me, and so I never bothered to add refinement support. Hence, from my perspective, refinements went over like a led balloon.

Re: Ruby 2.6.0-preview2 released with JIT

#92

Post by saagarjha »

dwheeler wrote: post #82
saagarjha wrote: post #34

Earlier quoted context omitted.

There are presumably better ways to get assembly out of code than generating C and passing it through a compiler frontend.

That is an unproven assumption. It's faster to hand-generate machine code straight from an interpreter than to invoke a C compiler. But that is not the only issue. As with everything else, this is a trade-off, and I'm eager to see how it works out. I can see some positive reasons to do this: 1. The Ruby developers get highly-optimized machine code, with relatively little effort on their part. Many, many man-years hav…

> The Ruby developers get highly-optimized machine code, with relatively little effort on their part. Many, many man-years have been spent to make C compilers generate highly optimal code.

Not for machine generated code. C compilers work well on human generated code, and not as well as Ruby -> C "translations".

Re: Ruby 2.6.0-preview2 released with JIT

#93

Post by kazinator »

dfox wrote: post #62
floatboth wrote: post #26

Earlier quoted context omitted.

Which Smalltalk?

Smalltalk/X can fileout packages as C projects that are then compiled by C compiler. But AFAIK this was never meant to be used as JIT and is primarily an deployment mechanism and non-ancient versions use in-process code generator implemented in Smalltalk as JIT backend. There are Common Lisp implementations that support similar mechanism of generating C code (ECL, Kyoto CL...), but I don't think any of then compiles…

KCL generates .c files and compiles those to .o object files. I played with this year ago (via the descendant GCL: GNU Common Lisp). The load function handles object files, like COFF or whatever. It's reminiscent of the Linux kernel modules.

See here, starting on P. 36: http://www.softwarepreservation.org/projects/LISP/kcl/doc/kc...

When KCL compiles a lambda expression, it generates a C file called "gazonk.lsp" and compiles that.

(The above paper report is a little confusing; in some places it claims that an object file has a .o suffix, but then with regard to this gazonk implicit name, it claims that the fasl file is gazonk.fasl.)

Re: Ruby 2.6.0-preview2 released with JIT

#94

Post by wasd »

transfire wrote: post #91
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…

As the creator of Ruby Facets, refinements were high on the todo list. Unfortunately the syntax of refinements led to an ugly problem... I would have to support two identical code bases to support both usages (monkey patching and refinement), the only difference being boilerplate code. I could find no way around it. That seemed ludicrous to me, and so I never bothered to add refinement support. Hence, from my perspec…

I've never heard of Ruby Facets but it looks interesting. Just as a heads up, the api document links on http://rubyworks.github.io/facets/learn.html don't work.

Re: Ruby 2.6.0-preview2 released with JIT

#95

Post by chrisseaton »

jashmatthews wrote: post #78
foldr wrote: post #70

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. Lua JIT is one of the most sophisticated dynamic language JITs out there, s…

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

> It works even worse at optimizing Ruby code via Topaz.

Topaz was easily the fastest Ruby JIT before TruffleRuby, beating the JRuby and Rubinius JITs. It was very impressive.

Re: Ruby 2.6.0-preview2 released with JIT

#96

Post by jashmatthews »

chrisseaton wrote: post #95
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…

> It works even worse at optimizing Ruby code via Topaz. Topaz was easily the fastest Ruby JIT before TruffleRuby, beating the JRuby and Rubinius JITs. It was very impressive.

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

Re: Ruby 2.6.0-preview2 released with JIT

#97

Post by chrisseaton »

jashmatthews wrote: post #96
chrisseaton wrote: post #95

Earlier quoted context omitted.

> It works even worse at optimizing Ruby code via Topaz. Topaz was easily the fastest Ruby JIT before TruffleRuby, beating the JRuby and Rubinius JITs. It was very impressive.

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.

Re: Ruby 2.6.0-preview2 released with JIT

#98

Post by foldr »

jashmatthews wrote: post #78
foldr wrote: post #70

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. Lua JIT is one of the most sophisticated dynamic language JITs out there, s…

> 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 better performance across the board. Relevant tweet at https://medium.com/@k0kubun/the-method-jit-compiler-for-ruby...:

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

Re: Ruby 2.6.0-preview2 released with JIT

#99

Post by onli »

alberth wrote: post #85
onli wrote: post #79

Earlier quoted context omitted.

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

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-gplv3.en.html.

Re: Ruby 2.6.0-preview2 released with JIT

#100

Post by lispm »

dfox wrote: post #62
floatboth wrote: post #26

Earlier quoted context omitted.

Which Smalltalk?

Smalltalk/X can fileout packages as C projects that are then compiled by C compiler. But AFAIK this was never meant to be used as JIT and is primarily an deployment mechanism and non-ancient versions use in-process code generator implemented in Smalltalk as JIT backend. There are Common Lisp implementations that support similar mechanism of generating C code (ECL, Kyoto CL...), but I don't think any of then compiles…

Example with GCL: compile individual function to C, compile it with C to a .o (for example on my 32bit ARM it is a elf32-littlearm file) file and then load it:

    >(defun foo (a) (* a 42)) 

    FOO

    >(compile 'foo)

    Compiling /tmp/gazonk_24158_0.lsp.
    End of Pass 1.  
    End of Pass 2.  
    OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
    Finished compiling /tmp/gazonk_24158_0.lsp.
    Loading /tmp/gazonk_24158_0.o
    start address -T 0x888488 Finished loading /tmp/gazonk_24158_0.o
    #
    NIL
    NIL
Post reply on HN