Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Priorities for JRuby 1.3

Reply
Thread Tools

Priorities for JRuby 1.3

 
 
Charles Oliver Nutter
Guest
Posts: n/a
 
      02-28-2009
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

 
Reply With Quote
 
 
 
 
James Britt
Guest
Posts: n/a
 
      02-28-2009
Charles Oliver Nutter 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 Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

 
Reply With Quote
 
 
 
 
M. Edward (Ed) Borasky
Guest
Posts: n/a
 
      03-01-2009
On Sat, Feb 28, 2009 at 2:39 PM, James Britt <(E-Mail Removed)> wrote:
> Charles Oliver Nutter 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. =C2=A0REALLY 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.
--=20
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.

 
Reply With Quote
 
James Britt
Guest
Posts: n/a
 
      03-01-2009
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 Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

 
Reply With Quote
 
Charles Oliver Nutter
Guest
Posts: n/a
 
      03-01-2009
James Britt 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

 
Reply With Quote
 
Charles Oliver Nutter
Guest
Posts: n/a
 
      03-01-2009
M. Edward (Ed) Borasky wrote:
> On Sat, Feb 28, 2009 at 2:39 PM, James Britt <(E-Mail Removed)> wrote:
>> Charles Oliver Nutter 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

 
Reply With Quote
 
Robert Dober
Guest
Posts: n/a
 
      03-01-2009
On Sat, Feb 28, 2009 at 11:39 PM, James Britt <(E-Mail Removed)> wrote=
:
> Charles Oliver Nutter wrote:


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

>
> Silly question. =A0REALLY 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.
--=20
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

 
Reply With Quote
 
Radosław Bułat
Guest
Posts: n/a
 
      03-01-2009
On Sat, Feb 28, 2009 at 10:16 PM, Charles Oliver Nutter
<(E-Mail Removed)> 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?


--=20
Pozdrawiam

Rados=B3aw Bu=B3at
http://radarek.jogger.pl - m=F3j blog

 
Reply With Quote
 
Ken Bloom
Guest
Posts: n/a
 
      03-01-2009
On Sat, 28 Feb 2009 16:16:44 -0500, Charles Oliver Nutter 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.
>
> 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


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.



--
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/
 
Reply With Quote
 
John Wells
Guest
Posts: n/a
 
      03-01-2009
[Note: parts of this message were removed to make it a legal post.]

On Sat, Feb 28, 2009 at 4:16 PM, Charles Oliver Nutter <
http://www.velocityreviews.com/forums/(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
JRubyHub.com: The hub to all JRuby and JRuby on Rails (JRoR)resources... sbaltagi@gmail.com Ruby 0 12-15-2007 07:28 PM
JRubyHub.com: The hub to all JRuby and JRuby on Rails (JRoR)resources... Slim Baltagi Java 0 12-15-2007 07:26 PM
[ANN] [JRuby] Fast Debugger for JRuby Martin Krauskopf Ruby 0 11-11-2007 10:47 PM
[JRuby] JRuby perf questions answered Charles Oliver Nutter Ruby 7 11-01-2007 05:11 AM
Any JRUBY programmers out there? Problems specifying RUBYLIB with jruby. Ronald Fischer Ruby 2 05-16-2007 09:34 PM



Advertisments