I started playing with Lukas Stadler's coroutine patch for MLVM, and
so far it's pretty cool. I posted the email below to the MLVM list,
describing my experience and showing some numbers for a patched
Enumerator#next compared to Ruby 1.9. I'm hoping to get this cleaned
up and included in JRuby 1.6, so that if you run on an MLVM build with
coroutine support, it will go the fast route instead.
Let me know what you think and if you have any questions.
---------- Forwarded message ----------
From: Charles Oliver Nutter <head...@headius.com>
Date: Mon, Jun 14, 2010 at 2:38 PM
Subject: Re: hg: mlvm/mlvm/jdk: added tests and CoroutineLocals
To: Da Vinci Machine Project <mlvm-...@openjdk.java.net>
I managed to get a simple patch written to partially convert Ruby's
Enumerator#next (a cursor over arbitrarily-complex iteration logic;
implemented with Threads in standard JRuby) to use coro with the help
of Stephen's build. It seems to work very well, even though I don't
have all the appropriate logic here (like raising an error on
end-of-iteration calls to next).
Here's the numbers for it compared to Ruby 1.9 (Ruby 1.8 uses
substantially slower logic for this...orders of magnitude slower than
either JRuby or Ruby 1.9):
# JRuby with threaded enumerator
~/projects/jruby ➔ ../jruby-1.4.0/bin/jruby -e "5.times { ary =
(1..1_000_000).to_a.to_enum; t = Time.now; 1_000_000.times { ary.next
}; puts Time.now - t }"
2.815
2.326
2.195
3.119
2.999
# Ruby 1.9.2, recent build
~/projects/jruby ➔ ruby1.9 -e "5.times { ary =
(1..1_000_000).to_a.to_enum; t = Time.now; 1_000_000.times { ary.next
}; puts Time.now - t }"1.63799
1.61982
1.622199
1.61865
1.634846
# JRuby with native coroutines in JVM
~/projects/jruby ➔ jruby -e "5.times { ary =
(1..1_000_000).to_a.to_enum; t = Time.now; 1_000_000.times { ary.next
}; puts Time.now - t }"
0.506
0.342
0.176
0.178
0.18
I've also done some runs logging the final result, and it is indeed
iterating. There have been a few glitches though.
* if I add "p n if n % 100_000 == 0" to the loop, it appears to crash.
I can provide the crash artifacts if you like.
* If the coroutine is never explicitly terminated it seems to delay
shutting down the JVM. In this naive implementation the final element
"eached" over will get ret'ed from the coroutine, pausing the each
loop one last time. Until the last + 1 call to next, it will not know
the iteration has walked all elements and will not exit. This seems to
delay JVM shutdown.
All told it was almost scary how easy it was to get this to work, even
if my patch is fairly primitive. I've provided it here:
http://gist.github.com/437762
- Charlie
On Wed, Jun 9, 2010 at 2:04 AM, Charles Oliver Nutter
<head...@headius.com> wrote:
> Oh man, now I need Lukas's patch and I can wow the whole Ruby world :)
>
> Lukas: Don't worry if it's ugly, I can clean it up :)
>
> On Tue, Jun 8, 2010 at 8:10 PM, Stephen Bannasch
> <stephen.banna...@deanbrook.org> wrote:
>> At 2:36 PM +0200 6/8/10, Lukas Stadler wrote:
>>>I had to change a few bits here and there, and it now works on my Mac
>>>(at least in 32 bit).
>>
>> It compiles cleanly on my 64-bit Mac (Intel Core 2 Duo, 10.5.8).
>>
>> How do I run the coroutine tests?
>>
>> Updated build here for Charlie:
>>
>> http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-2010_06_08.tar.gz
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-...@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
