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

JRuby 9000 released

blog.jruby.org

Post reply on HN
Print view View original

101–110 of 119 posts

Re: JRuby 9000 released

#101

Post by pmontra »

pmontra wrote: post #20
gary4gar wrote: post #5

is it faster than MRI?

What I read is that it's faster for long running applications (example: web apps) because the JIT can optimize the code. It should be slower for anything else, example: tests (very unfortunately). I don't know what the edit-reload-check workflow could be with JRuby and how well it can integrate with editors (few Rubyist use IDEs, http://www.sitepoint.com/ides-rubyists-use/ ). Anyway, I'm doing a bundle install with j…

I've been doing some progresses but there are a few (almost) show stoppers.

One is that startup is really slow.

rails c takes 25 second to give a prompt vs 10 on with Ruby 2.2.2 and almost 0 after spring has started. It's not something that a developer likes to work with.

Second one: still immature. The PostgreSQL adapter warns

NOTE: ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC, please help us finish 4.2 support - check http://bit.ly/jruby-42 for starters

Not something I want in production.

Third one, now I'm stuck with the JDBC adapter not connecting to my developement PostgreSQL over a unix domain socket. Maybe it can't (perhaps JDBC does only TCP/IP) and I have to reconfigure PostgreSQL to accept connection to 127.0.0.1:5432. That means any other application I'm working with won't work anymore and I should reconfigure them.

Summing up all together I'm not particularly eager to keep testing JRuby. Maybe somebody will solve those problems. I'll give another try to it next July.

Re: JRuby 9000 released

#102

Post by cheald »

pmontra wrote: post #101
pmontra wrote: post #20

Earlier quoted context omitted.

What I read is that it's faster for long running applications (example: web apps) because the JIT can optimize the code. It should be slower for anything else, example: tests (very unfortunately). I don't know what the edit-reload-check workflow could be with JRuby and how well it can integrate with editors (few Rubyist use IDEs, http://www.sitepoint.com/ides-rubyists-use/ ). Anyway, I'm doing a bundle install with j…

I've been doing some progresses but there are a few (almost) show stoppers. One is that startup is really slow. rails c takes 25 second to give a prompt vs 10 on with Ruby 2.2.2 and almost 0 after spring has started. It's not something that a developer likes to work with. Second one: still immature. The PostgreSQL adapter warns NOTE: ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC, please help us finish 4.2…

It sounds like most of your issues are with JDBC/AR-JDBC rather than JRuby itself though, no?

The startup time is annoying, though, especially in the context of TDD. I do know it's an area of active research, though. You should try launching with JRUBY_OPTS="--dev" and see if that helps, though.

Re: JRuby 9000 released

#103

Post by pmontra »

cheald wrote: post #102
pmontra wrote: post #101

Earlier quoted context omitted.

I've been doing some progresses but there are a few (almost) show stoppers. One is that startup is really slow. rails c takes 25 second to give a prompt vs 10 on with Ruby 2.2.2 and almost 0 after spring has started. It's not something that a developer likes to work with. Second one: still immature. The PostgreSQL adapter warns NOTE: ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC, please help us finish 4.2…

It sounds like most of your issues are with JDBC/AR-JDBC rather than JRuby itself though, no? The startup time is annoying, though, especially in the context of TDD. I do know it's an area of active research, though. You should try launching with JRUBY_OPTS="--dev" and see if that helps, though.

JRUBY_OPTS="--dev" lowered the startup time to 12 second, basically on par with MRI. Thanks! I googled you suggestion and I found https://github.com/jruby/jruby/wiki/Improving-startup-time I'll try a few suggestions that look like doing with spring does (Theine and Drip).

My other problems are with JDBC but if database drivers don't support Ruby's largest use case (Rails with ActiveRecord) probably JRuby will be negatively impacted. This is about the "ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC". The other one (unix domain socket) is a minor issue but any small nuisance loses developers along the way.

Re: JRuby 9000 released

#104

Post by juliangregorian »

headius wrote: post #72
juliangregorian wrote: post #31

Earlier quoted context omitted.

If you need system-level bindings: no. If you use threading: yes.

What do you mean? JRuby can make system calls as fast as MRI, generally. We don't support their C extension API, but we support and maintain an FFI library to programmatically call C from Ruby.

Ok, then why do none of the C app servers work in JRuby?

Re: JRuby 9000 released

#105

Post by Freaky »

thescrewdriver wrote: post #99
jrochkind1 wrote: post #81

Earlier quoted context omitted.

Huh, I use `$1` all the time, and see it all the time. Probably because the alternative with an explicit match object ends up being relatively a lot more code and a lot harder to read, really. If avoiding `$1` has been often recommended for a while... I think it's a recommendation more often ignored than followed.

I've never seen $1 used in production code.

Try grepping your lib directory sometime. In fact, let me do it for you, on a relatively clean install:

time, benchmark, irb, pry, rubygems, resolv, erb, rake, open-uri, debug, rack, cgi/util, optparse, getoptlong, bundler, activesupport, actionpack, activemodel, erubis, slim, haml, sass, sequel, roda, nokogiri, rugged, faraday, mime-types, thor, test-unit, tzinfo, mail, ffi

Re: JRuby 9000 released

#106

Post by Freaky »

headius wrote: post #91
fny wrote: post #19

Earlier quoted context omitted.

The real advantage comes from the fact that JRuby isn't enslaved to a GIL like MRI, so you get JVM threads out of the box. Even with the JIT, JRuby (at least 1.7) isn't appreciably faster than MRI when running a single-threaded app: http://www.isrubyfastyet.com/

These benchmarks are very small and do not run long enough for the JIT to really kick in. Many of them are also so synthetic as to be meaningless.

50,000 requests aren't enough for the JIT to warm up?

Re: JRuby 9000 released

#107

Post by mike_hearn »

headius wrote: post #88
jrochkind1 wrote: post #82

Earlier quoted context omitted.

It's unclear how much benefit invokedynamic actually provides at present, I recall seeing benchmarks not showing much. I think the big JRuby advantage is actually that by and large code written for MRI Just Works on JRuby. The exceptions are relatively few, and usually easily worked around, or if not quickly bug fixed. Despite this thread, I haven't had significant troubles with ActiveRecord-ODBC, although in Rails 4…

Invokedynamic's benefits have been a bit of a mixed bag, but id does make the JVM see through dynamic call sites and optimize them like it does statically-typed call sites. That generally improves performance for JRuby, but there are cases where simply inlining the code together doesn't lead to a measurable increase.

Given that both you and Chris are posting to this thread, I was kind of surprised to learn that you're planning to focus on a non-Truffle compiler/optimisation engine in future. Isn't Truffle meant to give huge speedups? It sounds like you might eventually get JRuby 9000 to be faster than MRI but that a rewrite of the current code didn't do it yet.

Is there some kind of vision or plan for how Graal/Truffle fits into the JRuby roadmap?

Re: JRuby 9000 released

#108

Post by cheald »

pmontra wrote: post #103
cheald wrote: post #102

Earlier quoted context omitted.

It sounds like most of your issues are with JDBC/AR-JDBC rather than JRuby itself though, no? The startup time is annoying, though, especially in the context of TDD. I do know it's an area of active research, though. You should try launching with JRUBY_OPTS="--dev" and see if that helps, though.

JRUBY_OPTS="--dev" lowered the startup time to 12 second, basically on par with MRI. Thanks! I googled you suggestion and I found https://github.com/jruby/jruby/wiki/Improving-startup-time I'll try a few suggestions that look like doing with spring does (Theine and Drip). My other problems are with JDBC but if database drivers don't support Ruby's largest use case (Rails with ActiveRecord) probably JRuby will be nega…

FWIW, I've never had any luck with Theine or Drip. But --dev is good stuff - it basically turns off the JIT and invokedynamic, which are great for long-running processes but not that useful for shorter script runs or consoles. JRuby defaults to "good for long-running processes" mode, which is great for production but less useful when running short-lived tasks.

Yeah, certainly understood WRT JDBC. But, as nirvdrum pointed out elsewhere in the thread, you might look at Sequel rather than AR if you do want to do JRuby stuff and AR-JDBC is holding you back - it's well-supported and I know lots of folks use it well.

The domain sockets thing is unfortunate, but AFAIK, they just aren't supported by JDBC.

Re: JRuby 9000 released

#109

Post by cheald »

juliangregorian wrote: post #104
headius wrote: post #72

Earlier quoted context omitted.

What do you mean? JRuby can make system calls as fast as MRI, generally. We don't support their C extension API, but we support and maintain an FFI library to programmatically call C from Ruby.

Ok, then why do none of the C app servers work in JRuby?

Because the C extension API isn't supported. Or to put it another way, you can call C libraries from JRuby, but you can't write C that calls JRuby. If you want to do that, you would replace it with a Java extension, instead. It's possible to offer "native extensions" for both MRI and JRuby from a gem by providing both via C and Java extensions, though.

Re: JRuby 9000 released

#110

Post by chrisseaton »

mike_hearn wrote: post #107
headius wrote: post #88

Earlier quoted context omitted.

Invokedynamic's benefits have been a bit of a mixed bag, but id does make the JVM see through dynamic call sites and optimize them like it does statically-typed call sites. That generally improves performance for JRuby, but there are cases where simply inlining the code together doesn't lead to a measurable increase.

Given that both you and Chris are posting to this thread, I was kind of surprised to learn that you're planning to focus on a non-Truffle compiler/optimisation engine in future. Isn't Truffle meant to give huge speedups? It sounds like you might eventually get JRuby 9000 to be faster than MRI but that a rewrite of the current code didn't do it yet. Is there some kind of vision or plan for how Graal/Truffle fits into…

Truffle is a research project. It is not a short-term goal to replace the current IR-based runtime in JRuby, and Truffle isn't really part of the 9k release (it's there but I wouldn't recommend trying to use it).

We are working towards being fully compliant and we're getting there fast - I think with four full-time people and more in support we are now the largest employer of Ruby implementors anywhere. But since we aren't ready yet, stopping work on IR isn't an option even if we wanted to do so and we all need Charlie and Tom to continue their excellent work on the IR.

In my personal view, Truffle will be good enough to replace JRuby runtime at some point in the next couple of years, but we aren't advocating for this now and if it did happen it would be because the JRuby community and leadership make that decision for themselves.

I think we might come up with some kind of roadmap, or at least stated plan, at JRubyConf next week.

Post reply on HN