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.
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?
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
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?
···
On Sat, Feb 28, 2009 at 10:16 PM, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
* Ruby execution performance (how fast do you want it?)
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.
···
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.
But there's others that we may need to prioritize:
* 1.8.7 support
--
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology. http://www.iit.edu/~kbloom1/
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
···
On Sat, Feb 28, 2009 at 4:16 PM, Charles Oliver Nutter < charles.nutter@sun.com> wrote:
* More Java integration refactoring (esp. subclassing)
* "Compiler #2" to produce normal Java classes from Ruby
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.
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.
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.
···
On Sat, Feb 28, 2009 at 11:39 PM, James Britt <james.britt@gmail.com> wrote:
Charles Oliver Nutter wrote:
* Ruby execution performance (how fast do you want it?)
Silly question. REALLY fast.
--
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)
* 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
···
On Sat, Feb 28, 2009 at 10:16 PM, Charles Oliver Nutter > <charles.nutter@sun.com> 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.
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...
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.
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.
On Sat, Feb 28, 2009 at 4:16 PM, Charles Oliver Nutter < > charles.nutter@sun.com> 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...
* 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.
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
···
On Sat, Feb 28, 2009 at 2:39 PM, James Britt <james.britt@gmail.com> 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.
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.
REALLY fast.