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

11–20 of 136 posts

Re: Ruby 2.6.0-preview2 released with JIT

#11

Post by Twirrim »

pavanky wrote: post #6
blattimwind wrote: post #4

> Unlike ordinary JIT compilers for other languages, Ruby’s JIT compiler does JIT compilation in a unique way, which prints C code to a disk and spawns common C compiler process to generate native cod e. Oh dear god.

Why aren't they using LLVM :-/

llvm isn't always available, doesn't support as many architectures and doesn't always give the best performance.

The *nix philosophy has long been towards trying to provide choice wherever possible, so that people can use the tool that best meets their needs.

Re: Ruby 2.6.0-preview2 released with JIT

#13

Post by tbodt »

blattimwind wrote: post #4

> Unlike ordinary JIT compilers for other languages, Ruby’s JIT compiler does JIT compilation in a unique way, which prints C code to a disk and spawns common C compiler process to generate native cod e. Oh dear god.

What's the advantage over using LLVM's built-in JIT, or PyPy's JIT, or generating machine code directly, or anything else that doesn't have the overhead of spawning processes for compiling and linking? One of the goals listed is minimizing the JIT compilation time.

Re: Ruby 2.6.0-preview2 released with JIT

#14

Post by handbanana »

blattimwind wrote: post #4

> Unlike ordinary JIT compilers for other languages, Ruby’s JIT compiler does JIT compilation in a unique way, which prints C code to a disk and spawns common C compiler process to generate native cod e. Oh dear god.

I don't see why this is bad. Many compilers generate C

Re: Ruby 2.6.0-preview2 released with JIT

#15

Post by pjungwir »

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 folks think about refinements. Are you using them? Are they helpful? Horrible?

I remember reading from the JRuby folks that refinements would make Ruby method calls slower---and not just refined calls, but all method calls [1], although it sounds like that changed some before they were released [2]. It seems like people stopped talking about this after they came out, so I'm wondering if refinements are still a challenge when optimizing Ruby? I guess MRI JIT will face the same challenges as the Java implementation?

[1] http://blog.headius.com/2012/11/refining-ruby.html

[2] https://github.com/jruby/jruby/issues/1062

Re: Ruby 2.6.0-preview2 released with JIT

#17

Post by kryptiskt »

handbanana wrote: post #14
blattimwind wrote: post #4

> Unlike ordinary JIT compilers for other languages, Ruby’s JIT compiler does JIT compilation in a unique way, which prints C code to a disk and spawns common C compiler process to generate native cod e. Oh dear god.

I don't see why this is bad. Many compilers generate C

Not at runtime.

Re: Ruby 2.6.0-preview2 released with JIT

#18

Post by ethagnawl »

blattimwind wrote: post #4

> Unlike ordinary JIT compilers for other languages, Ruby’s JIT compiler does JIT compilation in a unique way, which prints C code to a disk and spawns common C compiler process to generate native cod e. Oh dear god.

> Oh dear god.

Care to elaborate?

Re: Ruby 2.6.0-preview2 released with JIT

#19

Post by pmontra »

tbodt wrote: post #13
blattimwind wrote: post #4

> Unlike ordinary JIT compilers for other languages, Ruby’s JIT compiler does JIT compilation in a unique way, which prints C code to a disk and spawns common C compiler process to generate native cod e. Oh dear god.

What's the advantage over using LLVM's built-in JIT, or PyPy's JIT, or generating machine code directly, or anything else that doesn't have the overhead of spawning processes for compiling and linking? One of the goals listed is minimizing the JIT compilation time.

They want to check the generated code and let people check it

> The main purpose of this JIT release is to provide a chance to check if it works for your platform and to find out security risks before the 2.6 release

Post reply on HN