Priorities for JRuby 1.3

Discussion in 'Ruby' started by Charles Oliver Nutter, Feb 28, 2009.

  1. 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
     
    Charles Oliver Nutter, Feb 28, 2009
    #1
    1. Advertising

  2. Charles Oliver Nutter

    James Britt Guest

    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
     
    James Britt, Feb 28, 2009
    #2
    1. Advertising

  3. On Sat, Feb 28, 2009 at 2:39 PM, James Britt <> 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.
     
    M. Edward (Ed) Borasky, Mar 1, 2009
    #3
  4. Charles Oliver Nutter

    James Britt Guest

    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
     
    James Britt, Mar 1, 2009
    #4
  5. 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
     
    Charles Oliver Nutter, Mar 1, 2009
    #5
  6. M. Edward (Ed) Borasky wrote:
    > On Sat, Feb 28, 2009 at 2:39 PM, James Britt <> 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
     
    Charles Oliver Nutter, Mar 1, 2009
    #6
  7. Charles Oliver Nutter

    Robert Dober Guest

    On Sat, Feb 28, 2009 at 11:39 PM, James Britt <> 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)
     
    Robert Dober, Mar 1, 2009
    #7
  8. On Sat, Feb 28, 2009 at 10:16 PM, Charles Oliver Nutter
    <> 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
     
    Rados³aw Bu³at, Mar 1, 2009
    #8
  9. Charles Oliver Nutter

    Ken Bloom Guest

    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/
     
    Ken Bloom, Mar 1, 2009
    #9
  10. Charles Oliver Nutter

    John Wells Guest

    [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 <
    > 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
     
    John Wells, Mar 1, 2009
    #10
  11. Radosław Bułat wrote:
    > On Sat, Feb 28, 2009 at 10:16 PM, Charles Oliver Nutter
    > <> 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 Nutter, Mar 1, 2009
    #11
  12. Ken Bloom wrote:
    > 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


    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 Nutter, Mar 1, 2009
    #12
  13. John Wells 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
     
    Charles Oliver Nutter, Mar 1, 2009
    #13
  14. Hi,

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


    * 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.
    --
    Posted via http://www.ruby-forum.com/.
     
    Chauk-Mean Proum, Mar 2, 2009
    #14
  15. Charles Oliver Nutter

    Thomas Enebo Guest

    Chauk-Mean Proum wrote:
    > Hi,
    >
    > 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.
    >>
    >>

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

    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 Enebo, Mar 2, 2009
    #15
  16. Charles Oliver Nutter

    Thomas Enebo Guest

    John Wells wrote:
    > On Sat, Feb 28, 2009 at 4:16 PM, Charles Oliver Nutter <
    > > 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
    >
    >

    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
     
    Thomas Enebo, Mar 2, 2009
    #16
  17. Thomas Enebo 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.
    --
    Posted via http://www.ruby-forum.com/.
     
    Chauk-Mean Proum, Mar 2, 2009
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Slim Baltagi
    Replies:
    0
    Views:
    429
    Slim Baltagi
    Dec 15, 2007
  2. Ronald Fischer
    Replies:
    2
    Views:
    233
    Scott Miller
    May 16, 2007
  3. Charles Oliver Nutter

    [JRuby] JRuby perf questions answered

    Charles Oliver Nutter, Oct 31, 2007, in forum: Ruby
    Replies:
    7
    Views:
    196
    Kevin Williams
    Nov 1, 2007
  4. Martin Krauskopf

    [ANN] [JRuby] Fast Debugger for JRuby

    Martin Krauskopf, Nov 11, 2007, in forum: Ruby
    Replies:
    0
    Views:
    155
    Martin Krauskopf
    Nov 11, 2007
  5. Replies:
    0
    Views:
    179
Loading...

Share This Page