Forum: Ruby Priorities for JRuby 1.3

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Charles Oliver N. (Guest)
on 2009-02-28 23:18
(Received via mailing list)
With JRuby 1.2 almost out the door, we should talk a bit about where to
go with JRuby 1.3. There's always more work to do, but in this case
there's a few directions we could probably go.

Some obvious items will continue to see work:

* 1.9 libraries, interp, compiler, parser
* 1.8.6 bugs

But there's others that we may need to prioritize:

* 1.8.7 support
* Ruby execution performance (how fast do you want it?)
* Specific library performance (YAML, IO, Java)
* More Java integration refactoring (esp. subclassing)
* "Compiler #2" to produce normal Java classes from Ruby
* Improvements to AOT compilation (all-at-once, eliminate runtime
codegen)

And there's a number of internal chores to work on too:

* Start generating most of the call path, to reduce duplicate code
* Specific-arity optimizations for block yield (could be big)
* Compiler cleanup and refactoring
* Modularization of core classes that aren't valid on applet, Android,
secured envs, etc; also may allow shipping smaller runtimes
* More startup perf work; I have a few ideas

As always, there's way more tasks than the few of us committing to JRuby
can work on, so I think we need to hear from users what's important. Any
of these? Other items?

- Charlie
James B. (Guest)
on 2009-03-01 00:41
(Received via mailing list)
Charles Oliver N. wrote:

>
> But there's others that we may need to prioritize:
>
> * 1.8.7 support

Skip it.

> * Ruby execution performance (how fast do you want it?)

Silly question. :)  REALLY fast.


> * Specific library performance (YAML, IO, Java)
> * More Java integration refactoring (esp. subclassing)
> * "Compiler #2" to produce normal Java classes from Ruby

That could be quite interesting.


> * Modularization of core classes that aren't valid on applet, Android,
> secured envs, etc; also may allow shipping smaller runtimes

Yes to more Android support (so to speak).


--
James B.

www.jamesbritt.com           - Playing with Better Toys
www.ruby-doc.org             - Ruby Help & Documentation
www.rubystuff.com            - The Ruby Store for Ruby Stuff
M. Edward (Ed) Borasky (Guest)
on 2009-03-01 06:03
(Received via mailing list)
On Sat, Feb 28, 2009 at 2:39 PM, James B. <removed_email_address@domain.invalid>
wrote:
> Charles Oliver N. wrote:
>
>>
>> But there's others that we may need to prioritize:
>>
>> * 1.8.7 support
>
> Skip it.

+100

>> * Ruby execution performance (how fast do you want it?)
>
> Silly question. :)  REALLY fast.

See my posts on the Ruby Benchmark Suite list for that. But yeah ...
subject to the usual computer science tradeoffs between memory and
processor usage, as fast as you can get it for the core interpreter.

>> * Specific library performance (YAML, IO, Java)
>> * More Java integration refactoring (esp. subclassing)
>> * "Compiler #2" to produce normal Java classes from Ruby
>
> That could be quite interesting.

Well ... how about tuning the core engine for Rails / Merb and RSpec,
rather than singling out some lower-level libraries?

>
>> * Modularization of core classes that aren't valid on applet, Android,
>> secured envs, etc; also may allow shipping smaller runtimes
>
> Yes to more Android support (so to speak).

There was a bit of applause here last week when I told the local
Tweeple about the Android port. And it put the final nail in the
coffin of every other "smart phone" I'd consider buying, although I
probably wouldn't buy an Android either. I'm not really interested in
a phone I can / have to program, when I can get a really nice headset
and Skype for my laptop. :)
--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.
James B. (Guest)
on 2009-03-01 10:13
(Received via mailing list)
M. Edward (Ed) Borasky wrote:

>>> * Specific library performance (YAML, IO, Java)
>>> * More Java integration refactoring (esp. subclassing)
>>> * "Compiler #2" to produce normal Java classes from Ruby
>> That could be quite interesting.
>
> Well ... how about tuning the core engine for Rails / Merb and RSpec,

That's insane.

There's lots going on in Rubyland, and tuning the core engine for any
set of apps is evil.


--
James B.

www.jamesbritt.com           - Playing with Better Toys
www.ruby-doc.org             - Ruby Help & Documentation
www.rubystuff.com            - The Ruby Store for Ruby Stuff
Charles Oliver N. (Guest)
on 2009-03-01 11:37
(Received via mailing list)
James B. wrote:
>> Well ... how about tuning the core engine for Rails / Merb and RSpec,
>
> That's insane.
>
> There's lots going on in Rubyland, and tuning the core engine for any
> set of apps is evil.

My answer to tuning for either Rails or Merb is basically that it means
tuning *everything* anyway. The reason JRuby has only recently started
to post convincingly better numbers on Rails/Merb is because they're not
Ruby execution-bound, they're solidly library-bound. So it's not how
fast we can execute code, it's how optimized String or Array or Hash
are. And that takes a lot longer.

I asked about execution performance because it's actually "easy" now for
me to make Ruby execution as fast as anyone wants (I've got prototype
code that's only a couple times slower than Java), but it has less and
less impact on application performance. When Ruby execution perf is only
10% of an app's run time, improving it 100-fold doesn't change a thing.

- Charlie
Charles Oliver N. (Guest)
on 2009-03-01 11:38
(Received via mailing list)
M. Edward (Ed) Borasky wrote:
> On Sat, Feb 28, 2009 at 2:39 PM, James B. <removed_email_address@domain.invalid> wrote:
>> Charles Oliver N. wrote:
>>> * 1.8.7 support
>> Skip it.
>
> +100

That's been our general impression too...but I'll keep asking until
people start wanting it. So far, there's been nearly zero demand.

>>> * Ruby execution performance (how fast do you want it?)
>> Silly question. :)  REALLY fast.
>
> See my posts on the Ruby Benchmark Suite list for that. But yeah ...
> subject to the usual computer science tradeoffs between memory and
> processor usage, as fast as you can get it for the core interpreter.

I guess my actual question was "to what extent should we focus on Ruby
execution performance over other things?" given that we could endlessly
optimize execution for less and less gain. There's only so many hours in
the day...what portion of them should focus on execution perf and what
portion on tighter, cleaner integration with Java libraries?

> There was a bit of applause here last week when I told the local
> Tweeple about the Android port. And it put the final nail in the
> coffin of every other "smart phone" I'd consider buying, although I
> probably wouldn't buy an Android either. I'm not really interested in
> a phone I can / have to program, when I can get a really nice headset
> and Skype for my laptop. :)

I'm very excited about both the Android and CDC work, since it shows
that the core of JRuby can really scale to lots of different use cases.
I'm probably going to take a step back from both areas and let them
"simmer" in the community a bit while we close out 1.2 and ramp up 1.3,
but I've got big plans for both.

I've got a G1 on the way...now I just need to scam a Blu-Ray dev kit to
start working on "Bluby" with JRuby as the logic for apps.

- Charlie
Robert D. (Guest)
on 2009-03-01 11:54
(Received via mailing list)
On Sat, Feb 28, 2009 at 11:39 PM, James B. 
<removed_email_address@domain.invalid>
wrote:
> Charles Oliver N. wrote:

>> * Ruby execution performance (how fast do you want it?)
>
> Silly question. :)  REALLY fast.
I am sure you can do better than that, maybe  r i d i c o l o u s  s p e
e d?

R.
Radosław B. (Guest)
on 2009-03-01 14:37
(Received via mailing list)
On Sat, Feb 28, 2009 at 10:16 PM, Charles Oliver N.
<removed_email_address@domain.invalid> wrote:
> * Ruby execution performance (how fast do you want it?)

JRuby is very fast in micro benchmark but it doesn't run so well rails
(at least last time I checked it). Maybe you can investigate more what
hangs jruby in rails from running at the same level as jruby vs MRI
1.8 in micro benchmark?


--
Pozdrawiam

Rados³aw Bu³at
http://radarek.jogger.pl - mój blog
Ken B. (Guest)
on 2009-03-01 21:10
(Received via mailing list)
On Sat, 28 Feb 2009 16:16:44 -0500, Charles Oliver N. wrote:

> * 1.8.7 support
I use Debian, who included 1.8.7 in their recent stable release, so most
of my code is being targeted to 1.8.7 these days. While I understand
(and
agree with) philosophically the argument against making 1.8.7 to begin
with, once it's out and once it's the default on my platform, then
that's
what I'm targeting.

If you're doing 1.9 libraries anyway, then I imagine it's relatively
easy
to create a 1.8.7 compatibility mode by shaking up the list of what
methods are included in what classes under what circumstances. Right? If
so, then do it. (I imagine it wouldn't kill the 1.8.6 compatibility
mode,
right?)

If it's really hard, and I'm the only voice talking, then maybe it's not
worth your effort. I'm not using JRuby a whole lot now as it is.

* "Compiler #2" to produce normal Java classes from Ruby

This would be really cool. I had been using Groovy for this purpose some
time ago, but ran away because it was slow (a problem that has since
been
mostly solved) and has confusing semantics (a problem that may never be
fixed, since GPath seems to be their major selling point)

* Improvements to AOT compilation (all-at-once, eliminate runtime
codegen)

I'm not sure what you have in mind here.
John W. (Guest)
on 2009-03-01 22:12
(Received via mailing list)
On Sat, Feb 28, 2009 at 4:16 PM, Charles Oliver N. <
removed_email_address@domain.invalid> wrote:

> * More Java integration refactoring (esp. subclassing)
> * "Compiler #2" to produce normal Java classes from Ruby
>

My vote is for these two...better Java integration would mean my company
could take our current three language environment (java, ruby and
groovy) to
two...

John
Charles Oliver N. (Guest)
on 2009-03-01 22:15
(Received via mailing list)
Radosław Bułat wrote:
> On Sat, Feb 28, 2009 at 10:16 PM, Charles Oliver N.
> <removed_email_address@domain.invalid> wrote:
>> * Ruby execution performance (how fast do you want it?)
>
> JRuby is very fast in micro benchmark but it doesn't run so well rails
> (at least last time I checked it). Maybe you can investigate more what
> hangs jruby in rails from running at the same level as jruby vs MRI
> 1.8 in micro benchmark?

I'm hopeful that we've solved that. There are lingering issues that keep
AR from being faster than MRI (a major one is the lack of unix sockets
for JDBC, which does help keep MRI ahead), but for some internal
benchmarks we've run we're finally looking like 10-20% faster for most
things. And of course as applications get more complex and have more
user code, we pull away due to faster core classes and execution speed.

But of course we're interested in user stories to know where to focus
Rails-related perf work in the future.

- Charlie
Charles Oliver N. (Guest)
on 2009-03-01 22:21
(Received via mailing list)
Ken B. wrote:
> right?)
>
> If it's really hard, and I'm the only voice talking, then maybe it's not

Well, here's the deal. You're right that a lot of the work *may* already
be there, and maybe just needs to be rewired. The biggest thing that
keeps me personally from wanting to support 1.8.7 is a lack of RubySpecs
for the new and modified features. Anyone interested in 1.8.7 support in
JRuby should register their vote by contributing 1.8.7 feature specs.

> * "Compiler #2" to produce normal Java classes from Ruby
>
> This would be really cool. I had been using Groovy for this purpose some
> time ago, but ran away because it was slow (a problem that has since been
> mostly solved) and has confusing semantics (a problem that may never be
> fixed, since GPath seems to be their major selling point)

Yeah, I have a general idea how it will work in my head, and it's always
been doable. I had to open my big mouth and offer it as a 1.3
feature...just about everyone has asked for it now.

> * Improvements to AOT compilation (all-at-once, eliminate runtime codegen)
>
> I'm not sure what you have in mind here.

Currently when you AOT compile Ruby code, there's still some code
generated at runtime. This means you can't AOT compile to put on a
mobile device or in an unsigned applet, and you're force to interpret in
those cases. This work would make AOT compilation more "complete", doing
that additional bit of code generation at the same time.

- Charlie
Charles Oliver N. (Guest)
on 2009-03-01 22:22
(Received via mailing list)
John W. wrote:
> My vote is for these two...better Java integration would mean my company
> could take our current three language environment (java, ruby and groovy) to
> two...

Well, that's certainly motivation for us :)

- Charlie
Chauk-Mean P. (Guest)
on 2009-03-02 15:01
Hi,

Charles Oliver N. wrote:
> With JRuby 1.2 almost out the door, we should talk a bit about where to
> go with JRuby 1.3. There's always more work to do, but in this case
> there's a few directions we could probably go.
>

* More Java integration with Ruby style :

http://jira.codehaus.org/browse/JRUBY-3443

* And what about win32ole support in JRuby ?

I really miss this support in order to automate Windows application.
I currently use MRI for this task.

Cheers.

Chauk-Mean.
Thomas E. (Guest)
on 2009-03-02 23:10
(Received via mailing list)
Chauk-Mean P. wrote:
> * More Java integration with Ruby style :
> Chauk-Mean.
>
I made something which uses the Jacob library which seems to be mildly
compatible with win32ole (I had a script I had written against win32ole
and it continued to work with JRuby).   I will do a quick stab at
landing something really really preliminary for JRuby 1.3.   We can
figure out what is missing at that point and probably start trying to
support this library in more earnest.

-Tom
Thomas E. (Guest)
on 2009-03-02 23:24
(Received via mailing list)
John W. wrote:
> could take our current three language environment (java, ruby and groovy) to
> two...
>
> John
>
>
Can I ask which specific features of Java integration are holding you
back?    For example, are you missing annotation support?  We have
talked about compiler #2 for a long time, now but it would be cool to
get better real-world use-cases...

-Tom
Chauk-Mean P. (Guest)
on 2009-03-03 01:01
Thomas E. wrote:

> I made something which uses the Jacob library which seems to be mildly
> compatible with win32ole (I had a script I had written against win32ole
> and it continued to work with JRuby).   I will do a quick stab at
> landing something really really preliminary for JRuby 1.3.   We can
> figure out what is missing at that point and probably start trying to
> support this library in more earnest.
>

That's a very good news.

Cheers.

Chauk-Mean.
This topic is locked and can not be replied to.