C:\jrubywork\shootout\bench\binarytrees>set JAVA_HOME=C:\j2sdk1.5.0_06
C:\jrubywork\shootout\bench\binarytrees>jruby binarytrees.ruby 11
stretch tree of depth 12 check: -1
4096 trees of depth 4 check: -4096
1024 trees of depth 6 check: -1024
256 trees of depth 8 check: -256
64 trees of depth 10 check: -64
16 trees of depth 12 check: -16
long lived tree of depth 11 check: -1
31.094
C:\jrubywork\shootout\bench\binarytrees>set JAVA_HOME=C:\jdk1.6.0
C:\jrubywork\shootout\bench\binarytrees>jruby binarytrees.ruby 11
stretch tree of depth 12 check: -1
4096 trees of depth 4 check: -4096
1024 trees of depth 6 check: -1024
256 trees of depth 8 check: -256
64 trees of depth 10 check: -64
16 trees of depth 12 check: -16
long lived tree of depth 11 check: -1
26.406
On 4/6/06, Kelly Nawrocke <
[EMAIL PROTECTED]> wrote:
Well sun's fix for that is making low-contention locks fast and by grouping together multiple calls to the same object in one syncrhonized block (instead of multiple). i guess in mustang they will be able to remove synchronization if the compiler can prove that the Object in question is local to a thread... so i guess i would say, don't worry about it ;)
kellyOn 4/6/06, Charles O Nutter <[EMAIL PROTECTED]> wrote:It's a minor thing. I wish there was an unsynchronized Stack impl in core Java, but alas...On 4/6/06, Marc Hadley < [EMAIL PROTECTED]> wrote:On Apr 5, 2006, at 8:14 PM, Charles O Nutter wrote:
>
> - I'll be replacing Vector and Stack with ArrayList and
> UnsynchronizedStack; we don't ever have more than one thread
> accessing the given vars, and moving to unsynchronized collections
> has given us a speed boost in many other areas.
OK, I used Stack to keep the code as simple possible since I figured
this wasn't core code likely to be executed a lot but I'll bear that
in mind in future.
Marc.
>
> - The System.setOut stuff is definitely problematic, especially
> considering we'd like this to be able to work across not only
> multiple threads but across multiple JRuby VMs in the same JVM
> process. The solution will probably involve providing a JRuby
> runtime or JRuby thread-specific means of getting the "current
> stdout", and making our change there. I don't have a fix at the
> moment. The current working directory changes made recently are a
> similar solution, since Java only has one CWD (" user.dir"
> property) which we can't change willy-nilly. Long story short: your
> change may stick for now with a big FIXME on it.
>
> It's a good patch, and certainly cleaner and more complete than my
> original hack. I'll see about cleaning it up and committing it.
>
> Hopefully this will become a moot point someday if RCR 328 is
> included in core Ruby. It would be far more preferable to implement
> a Kernel#run_script for running scripts in a platform-specific way
> than to have tricks like this in JRuby.
>
> RCR 328: (appears to be down at the moment) http://www.rcrchive.net/
> rcr/show/328
>
> On 4/5/06, Charles O Nutter < [EMAIL PROTECTED]> wrote:
> I saw it was a NetBeans patch, so I did what I'd been intending to
> do for a while: make JRuby work as a project in NetBeans too. I
> just committed project.xml, so it should be working correctly. I'm
> pretty new to NetBeans, however, so if you (Marc) or someone else
> more familiar could have a look, I'd appreciate it.
>
> I should be able to apply and explore the patch now.
>
>
> On 4/5/06, Charles O Nutter < [EMAIL PROTECTED] > wrote:
> Ahh, one other detail: please use unified diff for your patches. It
> came through ok this time, so I should be able to apply it anyway.
>
>
> On 4/5/06, Marc Hadley < [EMAIL PROTECTED]> wrote: I tracked down
> the shell wildcard problem with my original patch and
> also tidied things up a bit and fixed a couple of additional bugs I
> ran into during testing. With this patch Kernel#system and
> Kernel#backquote now pass all the rubicon tests.
>
> One change I made that could have future repercussions is to
> temporarily redirect stdout to a buffer (see line 815 in the patched
> file) while executing a second ruby script in-process (this is
> required since you need to capture the output of the script executed
> via Kernel#backtick). This works fine for a single threaded script
> but might cause problems if multiple threads start executing
> additional scripts concurrently. There doesn't appear to be an easy
> fix to this but as I'm new to the code I might have missed something.
>
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
>
>
>
>
>
>
>
>
>
>
> --
> Charles Oliver Nutter @ headius.blogspot.com
> JRuby Developer @ jruby.sourceforge.net
> Application Architect @ www.ventera.com
>
>
>
> --
> Charles Oliver Nutter @ headius.blogspot.com
> JRuby Developer @ jruby.sourceforge.net
> Application Architect @ www.ventera.com
>
>
>
> --
> Charles Oliver Nutter @ headius.blogspot.com
> JRuby Developer @ jruby.sourceforge.net
> Application Architect @ www.ventera.com
---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jruby-devel mailing list
Jruby-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jruby-devel
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
