[ruby-core:23887] Re: Merging recent Ruby threading improvements

On Tue, Jun 16, 2009 at 19:20, Joe Damato<[e-mail]> wrote:
> Hi ruby-core and CC'ed friends -
>
> As many of you know, Aman Gupta and I have been busy hacking on Ruby
> 1.8.{6,7} internals making some cool improvements with the threading
> implementation.

I've needed something like this many times in the past so it's great
to hear about merge work.

> Currently, we have a threading implementation that moves the thread stacks
> off of the process stack, reducing context switch cost significantly. More
> technical information about this, as well as links to patches that apply
> against Ruby 1.8.6 and 1.8.7 are available on my blog at:
> http://timetobleed.com/fixing-threads-in-ruby-18-a-2-10x-performance-boost/

This reminds me a lot of the code used in Io (the language) for
implementing coroutines. The stack jumping code was able to become
semi portable with effort and a few had highly optimized
implementations for more common targets. The primary issue is that it
does tie significantly into not only the system instruction set but
any ABI quirks that certain OS's might induce.

> There are a few important things to note about the code provided there:
>
> 1.) The patches only build on the x86 and x86_64 platforms, other platforms
> will likely fail to compile.

ucontext was something we tried to abuse for awhile which allows
avoiding assembly code if you can provide a map of the register dump.
It might at least lower the barrier for new implementations. Hand
optimized assembly is of course a bit faster but both easily beat the
current code paths.

Also, windows has kernel fibers which provide a very suitable
implementation for switchable process stacks that could be used on
that platform.

> 2.) The patches have only been tested on OSX and Linux on x86 and x86_64 -
> other OSs will need to be tested.
> 3.) Currently, continuations are broken with our patches.

These should be easy to fix if the stacks are copied again each time right?

>
> If Aman and I do the following items:
>
> 1.) Add #ifdefs to allow non x86 architectures to compile and use the old
> thread code paths
> 2.) Test on a few more architectures (we would need help from the community
> for this)
> 3.) Fix continuations
>
> Will our code be considered for merging to future Ruby 1.8.{6,7} releases?

I'd be happy to see this happen as well. Anyone else have thoughts on this?

> We ask this question because Aman and I hack on the Ruby interpreter for
> *fun* - and completing the list of tasks above is not as fun as working on a
> new GC implementation =]. We don't mind doing the work if we know before we
> do it that we'll have the support of the community and that there is a
> *reasonable* chance our code will get merged back in.
>
> We look forward to working with the Ruby community moving forward -
> Joe Damato and Aman Gupta
>

Thanks for the work guys,
Brian.