JRuby 1.1 Roadmap

[Charles Oliver Nutter-2]

Here's the proposed 1.1 roadmap Tom, Nick and I came up with this
afternoon. Add remove as you see fit, we'll try to iron it out.

   - compiler complete
   - AOT compilation working with jrubyc
   - stdlib all precompiled
   - gem install precompilation
   - virtual filesystem-inside-JVM (maybe) or hacked rubygems that can
run out of an archive
   - performance improvement to be quantified...java integration,
execution, memory reduction
   - yarv bytecode execution and compilation (maybe)
   - AST sharing as an option (sharing across runtimes)...need to
explore AOT compilation and its (positive?) effect on memory too
   - real threading brutalization, testably multithread-safe core
classes (maybe, needs heavy testing on many-core systems)
   - Java API rubification, perhaps with require 'javax.swing' and so on
   - RubyConf for release

I accept responsibility for the compiler stuff, and I'm confident I can
have it all done by then. The big remaining items are tough, but there's
two months.

All told, it should be a pretty wicked release.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Ken McDonald]

I think even half of that would more than justify a .1 release. Very
impressive!

Something I've been wondering about recently, that is definitely related
to a couple of the points below; any guesses as to what sorts of
speedups we can see in the future, and where these speedups will happen?
I'm implementing a text component at the moment, and it is (a little
bit) slow, in the sense that reflowing the window contents as the window
is resized, is rather draggy. (Of course, there could be fundamental
problems in my code as well.)

I'm a bit reluctant to worry undertake a lot of performance work right
now, though, because I simply don't know what might happen with
performance in the future. If you cared to throw out some guesstimates
as to what might improve, by how much, and what things are likely to be
bottlenecks because they're difficult to change, it'd be much appreciated.


Thanks,
Ken

Charles Oliver Nutter wrote:

> Here's the proposed 1.1 roadmap Tom, Nick and I came up with this
> afternoon. Add remove as you see fit, we'll try to iron it out.
>
>   - compiler complete
>   - AOT compilation working with jrubyc
>   - stdlib all precompiled
>   - gem install precompilation
>   - virtual filesystem-inside-JVM (maybe) or hacked rubygems that can
> run out of an archive
>   - performance improvement to be quantified...java integration,
> execution, memory reduction
>   - yarv bytecode execution and compilation (maybe)
>   - AST sharing as an option (sharing across runtimes)...need to
> explore AOT compilation and its (positive?) effect on memory too
>   - real threading brutalization, testably multithread-safe core
> classes (maybe, needs heavy testing on many-core systems)
>   - Java API rubification, perhaps with require 'javax.swing' and so on
>   - RubyConf for release
>
> I accept responsibility for the compiler stuff, and I'm confident I
> can have it all done by then. The big remaining items are tough, but
> there's two months.
>
> All told, it should be a pretty wicked release.
>
> - Charlie
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Kenneth McDonald wrote:

> I think even half of that would more than justify a .1 release. Very
> impressive!
>
> Something I've been wondering about recently, that is definitely related
> to a couple of the points below; any guesses as to what sorts of
> speedups we can see in the future, and where these speedups will happen?
> I'm implementing a text component at the moment, and it is (a little
> bit) slow, in the sense that reflowing the window contents as the window
> is resized, is rather draggy. (Of course, there could be fundamental
> problems in my code as well.)
>
> I'm a bit reluctant to worry undertake a lot of performance work right
> now, though, because I simply don't know what might happen with
> performance in the future. If you cared to throw out some guesstimates
> as to what might improve, by how much, and what things are likely to be
> bottlenecks because they're difficult to change, it'd be much appreciated.

A conservative estimate is that the compiler improves execution
performance by 50% (i.e. it doubles performance). In many cases, the
improvement is more drastic, in the neighborhood of 3-5 times improvement.

JRuby 1.0 compiled relatively little code, and many pieces of idiomatic
Ruby were simply skipped. For example: multiple block arguments, various
types of method arguments, multiple assignment, splats, most flow
control, for loops, class definitions, and many more. Only the simplest
methods compiled, and often the biggest performance bottlenecks remained
interpreted.

I would expect that with the compiler complete, performance of all
applications will improve substantially. We'll start to get more
concrete numbers for full-app performance as we approach the 1.1
release, but you can also try out the compiler on trunk today; it's
safe, stable, and working now. See my previous threads for information
about what doesn't compile.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Charles Oliver Nutter wrote:

> Here's the proposed 1.1 roadmap Tom, Nick and I came up with this
> afternoon. Add remove as you see fit, we'll try to iron it out.
>
>   - compiler complete
>   - AOT compilation working with jrubyc
>   - stdlib all precompiled
>   - gem install precompilation
>   - virtual filesystem-inside-JVM (maybe) or hacked rubygems that can
> run out of an archive
>   - performance improvement to be quantified...java integration,
> execution, memory reduction
>   - yarv bytecode execution and compilation (maybe)
>   - AST sharing as an option (sharing across runtimes)...need to explore
> AOT compilation and its (positive?) effect on memory too
>   - real threading brutalization, testably multithread-safe core classes
> (maybe, needs heavy testing on many-core systems)
>   - Java API rubification, perhaps with require 'javax.swing' and so on
>   - RubyConf for release

I think we need to add thread pooling to the list. Rails spins up a
thread for every request, probably due to the timeout library. That's
hella overhead for us when they're native threads.

- Get thread pooling working 100%

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email