The JRuby community is pleased to announce the release of JRuby 1.1 RC 1

Homepage: http://www.jruby.org/
Download: http://dist.codehaus.org/jruby/

JRuby 1.1RC1 is the first release candidate of JRuby 1.1. JRuby 1.1
represents a concerted focus on speed and refinement. Ruby code can
completely compile in an Ahead Of Time (AOT) or Just In Time (JIT) mode;
yielding a faster Ruby! It also uses less memory than our previous
releases.

We need people to download JRuby 1.1RC1 and give us feedback. Test your
applications and us make JRuby 1.1 a great release.

Highlights:
- 143 issues resolved since JRuby 1.1b1
- Landing of Java port of Oniguruma (Joni)
- Most Posix methods supported (e.g. stat, kill, getuid)
- Latest Rubygems 1.0.1, RSpec 1.1.1, and Rake 0.8.1 gems
- Updated standard library to be Ruby 1.8.6 compatible

A huge round of thanks goes to Marcin Mielzynski for porting Oniguruma.
Porting Oniguruma to Java (resulting in a sub-project called Joni) was a
tremendous amount of work and it turned out great. We also want to
acknowledge Vladimir Sizikov for the large number of Rubyspecs failure
fixes
during this development cycle. He has been tenacious in getting patches to
us on a daily basis.

Issues fixed since 1.1 beta 1:

JRUBY-15 : Implement File::Stat.ino and File::Stat.dev
JRUBY-1052: Rubinius binding_spec failures
JRUBY-1058: Rubinius core/file_spec failures
JRUBY-1061: Rubinius core/kernel_spec failures
JRUBY-1226: JRuby does not work in Web Start because it does not set the
ProtectionDomain of Java proxy classes when it creates them
JRUBY-1366: Names when compiling scripts are mangld in some cases
JRUBY-1404: Unstable behavior with ARes in Rails 2.0 PRE1
JRUBY-1415: Proc#to_s should display the position info for the block
JRUBY-1438: Create JNA-based implementations of fstat/lstat
JRUBY-1453: All IO operations in JRuby need to mirror MRI's heavy use of
select for all operations
JRUBY-1458: ARGF.rewind blows up (and it shouldnt)
JRUBY-1461: require './NonExistantRequiredFile' causes
StringIndexOutOfBoundException instead of LoadError
JRUBY-1462: test_trace_func crashes interpreter
JRUBY-1464: java.lang.ArrayIndexOutOfBoundsException - Exception in
thread "Ruby Thread24338914"
JRUBY-1487: weakref.rb could (should?) be implemented in Java
JRUBY-1488: Add ant tasks for running JRuby, and for profiling and
debugging code within NetBeans
JRUBY-1497::undefined method for Thread:class. for compiled Jruby classes
JRUBY-1503: disabled objectspace causes failures in Net/HTTP
JRUBY-1506: Blocking Java calls don't work with timeout
JRUBY-1508: Dir#[] and Dir#glob incompatibilities
JRUBY-1515: Compiler is failing to compile files with nonstandard paths
JRUBY-1522: Retry argument evaluation incompatibility
JRUBY-1528: ant Javadoc error when using target create-apidocs
JRUBY-1541: The warinig message is not displayed when useless use of a
quote symbol.
JRUBY-1580: Pathname#unlink complains "<file> is not a directory"
JRUBY-1592: Math.Asinh is wrong with negative arguments
JRUBY-1620: File.link needs to be implemented
JRUBY-1621: rss/maker doesn't compile
JRUBY-1622: File.expand_path cannot resolve a relative change to a path
inside a jar
JRUBY-1636: JSON_PURE with the new Joni regex fails with array in a
Hash, I guess
JRUBY-1641: Cannot run unsigned in Web Start due to accessing system
properties
JRUBY-1660: JRuby is 10x slower than MRI on Time objects creation
JRUBY-1666: JRuby needs a test target that attempts to compile all
stdlib files, to confirm compiler is at least that complete and not
blowing up
JRUBY-1672: JRuby File.rename() behavior different from Ruby, causes log
rotation issue
JRUBY-1673: We need to KILL MethodCache.
JRUBY-1680: nailgun slows way down when
JRUBY-1683: attr_reader, attr_writer, and attr_accessor should have arity 0
JRUBY-1684: Numerous StringIO spec test failures
JRUBY-1689: Tempfile class random behavior and "Bad file descriptor
(Errno::EBADF)" exception
JRUBY-1695: JRuby in applet fails due Boolean.getProperty security
permission
JRUBY-1706: [PATCH] Bad format for "frozen" error messages
JRUBY-1715: Incompatible behavior for ||= in Hashes
JRUBY-1719: String#capitalize! handles frozen empty string incompatibly
JRUBY-1721: String#slice and #[] on tainted string might incorrectly
return untainted string
JRUBY-1722: String#<=> doesn't handle non-string arguments, but in MRI
it does
JRUBY-1723: String#initialize and String#replace on frozen strings
behave incompatibly with MRI
JRUBY-1726: String#inpect and String#dump behavior is different from Ruby
JRUBY-1730: String#slice! and String#[]= with negative ranges behave
differently than Ruby
JRUBY-1732: String#rindex works incorrectly with FixNum parameters
JRUBY-1733: String conversions with 0dNNN and 0oNNN formats are incorrect
JRUBY-1734: Memory leak in trap()
JRUBY-1737: String#% can't handle some string arguments with underscores
JRUBY-1738: Kernel.sprintf with argument of some non-standard type
doesn't invoke to_int on it
JRUBY-1740: Usage text says ObjectSpace is both enabled and disabled by
default
JRUBY-1741: joda-time does not marshal months correctly
JRUBY-1742: String#% with %s and %p handles tainted status of ar
JRUBY-1743: =begin and =end should not be case insensitive
JRUBY-1744: END { } in method should generate a warning and not an error
JRUBY-1745: String#slice! can't handle Float and non-standard numerics
as arguments
JRUBY-1746: Various String methods handle tainted flag incorrectly
JRUBY-1748: String#unpack with Z* pattern is incorrect
JRUBY-1750: String#succ! behaves differently from Ruby 1.8 which is also
different from MRI 1.9
JRUBY-1751: retroweaver tasks should use verify option
JRUBY-1752: String#* returns incorrect class when used with String
subclasses
JRUBY-1754: Regression in specified Time behavior with Joda Time changes
JRUBY-1757: String#dump and String#crypt handle string subclasses
incorrectly
JRUBY-1758: String#% incorrectly handles null bytes right after '%' in
the pattern
JRUBY-1759: JRubyFileStat gives an NPE for the root directory
JRUBY-1760: Joda Time error installing rails with RubyGems 1.0.0
JRUBY-1762: IRBApplet fails to start due to various security restrictions
JRUBY-1764: unsafe allocation of module and symbol ids
JRUBY-1765: YAML cannot load string with hash symbol
JRUBY-1766: Yaml.load returns obects of different type compared to MRI
JRUBY-1768: RubyGems 1.0.0 hack may be due to yaml_initialize not
getting called
JRUBY-1771: gem install mongrel broken
JRUBY-1774: String#% with 'g/G/e/E' patterns produces incorrect output
different from MRI
JRUBY-1777: WebStart sample should be provided
JRUBY-1778: Regression: String#match after String#gsub (and vice versa)
with the same string work incorrectly
JRUBY-1779: String#unpack with Q pattern is incorrect
JRUBY-1780: String#unpack with X pattern is incorrect
JRUBY-1781: test_higher_javasupport threading test fails periodically
JRUBY-1782: error running sample/jirb.jnlp with signed version of
jruby-complete.jar
JRUBY-1785: Failure in test_glob_inside_jar_file
JRUBY-1786: yaml_initialize is not called
JRUBY-1806: String#inspect works incorrectly when KCODE is set
JRUBY-1807: Lots of spec failures for Time
JRUBY-1809: IRBConsole doesn't fully exit the VM when its window is closed
JRUBY-1811: Kernel#` (backtick) should call to_str on the passed string
JRUBY-1812: Kernel#load should accept a second "wrap" parameter that
wraps the load in a new anonymous toplevel self
JRUBY-1813: Object#methods should return only singleton methods when
passed false
JRUBY-1814: Object#singleton_methods should only return singleton class
methods and module methods included into singleton
JRUBY-1815: FileTest#identical? is not implemented
JRUBY-1816: Native File Stat mode comparisons + filetype is borked
JRUBY-1817: native filestat isReadable{,Real}, isWritable{,Real}, and
isExecutable{,Real} have small logic error
JRUBY-1818: Method and UnboundMethod inspect/to_s not quite right
JRUBY-1819: Kernel#require should try to to_str coerce the provided object
JRUBY-1820: Dir.mkdir does not honor mode bits
JRUBY-1823: Proc arity failures for lambdas with a single argument
receiving 0 or >1 argument
JRUBY-1824: module_eval should coerce to string
JRUBY-1825: UnboundMethod.clone ends up becoming a Method
JRUBY-1826: UnboundMethod/Method.== fails for some Rubinius specs
JRUBY-1827: Range failures in ruby specs: step and each must have "succ"
defined on begin (if not an integral type), each must use spaceship for
comparisons
JRUBY-1828: Module.<=> should return nil when other is not a module
JRUBY-1829: eval + friends do not honor line number argument
JRUBY-1830: Dir.open(..) with block should return last value/returned
value of block
JRUBY-1831: ObjectSpace spec test fails from time to time
JRUBY-1832: StringIO spec failures: reopen should truncate actual
string, reset mode flags
JRUBY-1833: Time should roll over too-high hours to days and too-high
days to months
JRUBY-1834: String#unpack with "m" pattern is incorrect
JRUBY-1835: Proc.new should return the existing proc associated with a
block if one has already been created
JRUBY-1836: AIOOB in String#each spec running with +C
JRUBY-1840: Complex default args that define methods not defining in
correct class
JRUBY-1841: throw that bubbles all the way to the top of a non-main
thread should result in a ThreadError instead of a NameError
JRUBY-1842: Modifications to $LOADED_FEATURES should be reflected in
require behavior
JRUBY-1843: Implement File::readlink
JRUBY-1844: Fix all Dir.glob issues in current Rubinius spec
JRUBY-1845: Implement Kernel::fork (for experimental purposes only)
JRUBY-1848: Bignum#[] should not throw exceptions even when the argument
is very big
JRUBY-1849: $defout and $deferr are not changed when $stdout and $stderr
modified
JRUBY-1850: UnsatisfiedLinkError with 'mkdir' while running gem
JRUBY-1851: Exception raised while attempting to retrieve a plain text
document from a https service.
JRUBY-1857: how to get mac address, gem uuidtools 1.0.2 not working
JRUBY-1858: JRuby reports wrong position in stack trace
JRUBY-1862: Missing constants in Errno
JRUBY-1863: String#% should raise ArgumentError or print a warning when
$DEBUG or $VERBOSE are set
JRUBY-1866: [PATCH] RubyGC singleton methods
JRUBY-1867: Module#autoload must validate arguments
JRUBY-1868: Signal.list must list all (short) signal names and their
values in a hash
JRUBY-1869: JRuby must be compatible with Ruby 1.8.6 instead of 1.8.5
JRUBY-1870: Object#extend should extend in order from last arg to first
JRUBY-1871: Kernel#proc should raise argument error when no block present
JRUBY-1873: Kernel#exec should raise a SystemCallError if cmd cannot execute
JRUBY-1874: HttpOutput flush doesn't send headers
JRUBY-1875: Integer overflow in Array#fill
JRUBY-1876: Array#initialize should not modify frozen array
JRUBY-1877: Marshalling of Gem::Specification broken under Rubygems 1.0
JRUBY-1878: Failing to send mails to msmtp mail server using IO.popen.
For instance impossible to send mails to GMail using msmtp. This is a
regression.
JRUBY-1880: Kernel#trap sometimes throws Java-base exception
JRUBY-1881: support stdlib yaml/store
JRUBY-1883: RubySignal should be modified to not try to load
Sun-specific Signal classes when they are not present
JRUBY-1885: Reopen of a filename after close should succeed
JRUBY-1898: YAML loading incorrectly returns the same instances for strings
JRUBY-1914: Class file has wrong version 50.0 on Maven repository

--
Thomas E Enebo <thomas.enebo@sun.com>
JRuby Core Developer, http://www.bloglines.com/blog/ThomasEEnebo

On Jan 8, 2008 11:39 AM, Thomas Enebo <Thomas.Enebo@sun.com> wrote:
> The JRuby community is pleased to announce the release of JRuby 1.1 RC 1

Congrats to all the JRuby team on a good looking RC1 release. I've run my
normal performance test on it (no, it's not a microbenchmark -- yes,
it's specific
to a particular task I use Ruby (and maybe JRuby in the future) for at my day
job). The short version is that this version is better than 25%
faster than the 1.0
versions, and almost 20% better than the 1.1 beta relase. It's getting close to
1.8 and 1.9 speeds (at least for me).

If you want to see the full-on JRuby comparisons, look here:

http://on-ruby.blogspot.com/2008/01/...rformance.html

If you want to see comparisons against the C implementation, you'll have to
wait a day or two.


>
> --
> Thomas E Enebo <thomas.enebo@sun.com>
> JRuby Core Developer, http://www.bloglines.com/blog/ThomasEEnebo
>
>
>



--
thanks,
-pate
-------------------------
Duty makes us do things, Love make us do things well.
http://on-ruby.blogspot.com http://on-erlang.blogspot.com
http://on-soccer.blogspot.com

With all the blog posts about JRuby being posted, I thought I would
finally try JRuby myself.
I tested it on my genetic algorithms library. Lots of metaprogramming
going on in the initialization, and a lot of calculations afterwards
using the generated modules and classes.

First tried my tests.
Finished in 34.726 seconds.
33 tests, 626 assertions, 0 failures, 0 errors
That's better than 1.9, which couldn't handle some of the metaprogramming.

Then tried a benchmark:
1.8 : 676.75 seconds (ubuntu/apt-get)
1.9 : 161.99 seconds (svn/-O3/no enable-pthread)
JRuby: 302.23 seconds (java opts -server, jruby +C)

Did JRuby just outperform 1.8 by a factor >2 ?
I'm impressed. Great job JRuby team.

Sander Land wrote:
> With all the blog posts about JRuby being posted, I thought I would
> finally try JRuby myself.
> I tested it on my genetic algorithms library. Lots of metaprogramming
> going on in the initialization, and a lot of calculations afterwards
> using the generated modules and classes.
>
> First tried my tests.
> Finished in 34.726 seconds.
> 33 tests, 626 assertions, 0 failures, 0 errors
> That's better than 1.9, which couldn't handle some of the metaprogramming.
>
> Then tried a benchmark:
> 1.8 : 676.75 seconds (ubuntu/apt-get)
> 1.9 : 161.99 seconds (svn/-O3/no enable-pthread)
> JRuby: 302.23 seconds (java opts -server, jruby +C)
>
> Did JRuby just outperform 1.8 by a factor >2 ?
> I'm impressed. Great job JRuby team.

Wow, that's great to hear. There are a few experimental options you can
see running jruby --properties that might boost it further. They're not
all 100% safe, and may have side effects, but you can try them anyway
and see how the performance comes out.

Especially look at -J-Djruby.compile.frameless, which improves some
benchmarks by a factor of 3.

- Charlie

Charles Oliver Nutter wrote:
> Sander Land wrote:
>> With all the blog posts about JRuby being posted, I thought I would
>> finally try JRuby myself.
>> I tested it on my genetic algorithms library. Lots of metaprogramming
>> going on in the initialization, and a lot of calculations afterwards
>> using the generated modules and classes.
>>
>> First tried my tests.
>> Finished in 34.726 seconds.
>> 33 tests, 626 assertions, 0 failures, 0 errors
>> That's better than 1.9, which couldn't handle some of the
>> metaprogramming.
>>
>> Then tried a benchmark:
>> 1.8 : 676.75 seconds (ubuntu/apt-get)
>> 1.9 : 161.99 seconds (svn/-O3/no enable-pthread)
>> JRuby: 302.23 seconds (java opts -server, jruby +C)
>>
>> Did JRuby just outperform 1.8 by a factor >2 ?
>> I'm impressed. Great job JRuby team.
>
> Wow, that's great to hear. There are a few experimental options you can
> see running jruby --properties that might boost it further. They're not
> all 100% safe, and may have side effects, but you can try them anyway
> and see how the performance comes out.
>
> Especially look at -J-Djruby.compile.frameless, which improves some
> benchmarks by a factor of 3.

I realized that might confuse some...the full flag would be

-J-Djruby.compile.frameless=true

Fun stuff.

- Charlie

Sander Land wrote:
> With all the blog posts about JRuby being posted, I thought I would
> finally try JRuby myself.
> I tested it on my genetic algorithms library. Lots of metaprogramming
> going on in the initialization, and a lot of calculations afterwards
> using the generated modules and classes.
>
> First tried my tests.
> Finished in 34.726 seconds.
> 33 tests, 626 assertions, 0 failures, 0 errors
> That's better than 1.9, which couldn't handle some of the metaprogramming.
>
> Then tried a benchmark:
> 1.8 : 676.75 seconds (ubuntu/apt-get)
> 1.9 : 161.99 seconds (svn/-O3/no enable-pthread)
> JRuby: 302.23 seconds (java opts -server, jruby +C)
>
> Did JRuby just outperform 1.8 by a factor >2 ?
> I'm impressed. Great job JRuby team.

Also, depending on how your app runs, you may want to try without +C. +C
can slow down the overall startup enough to be measurable, since it has
to compile everything before running. Play with it, let us know what you
find out. We want to have good defaults.

- Charlie

On Jan 8, 2008 6:59 PM, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
> Also, depending on how your app runs, you may want to try without +C. +C
> can slow down the overall startup enough to be measurable, since it has
> to compile everything before running. Play with it, let us know what you
> find out. We want to have good defaults.


In my case, +C took about 25 seconds, -C took about 15, and no C switch
took about 20. I'm obviously going to need to play with switches for a bit


>
> - Charlie
>
>



--
thanks,
-pate
-------------------------
Duty makes us do things, Love make us do things well.
http://on-ruby.blogspot.com http://on-erlang.blogspot.com
http://on-soccer.blogspot.com

pat eyler wrote:
> On Jan 8, 2008 6:59 PM, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
>> Also, depending on how your app runs, you may want to try without +C. +C
>> can slow down the overall startup enough to be measurable, since it has
>> to compile everything before running. Play with it, let us know what you
>> find out. We want to have good defaults.
>
>
> In my case, +C took about 25 seconds, -C took about 15, and no C switch
> took about 20. I'm obviously going to need to play with switches for a bit

Yes, and please report back your findings. We want to tweak the defaults
to something that gives "good" performance for everyone, leaving
tweakage only necessary to get "stellar" performance.

- Charlie

Sander Land wrote:
> 1.8 : 676.75 seconds (ubuntu/apt-get)

What if you build ruby from source (let's say, with the same opts as you
used for 1.9)?

--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

On Jan 9, 2008 3:34 AM, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:
> Sander Land wrote:
> > 1.8 : 676.75 seconds (ubuntu/apt-get)
>
> What if you build ruby from source (let's say, with the same opts as you
> used for 1.9)?
>
> --
> vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
>
>

Ruby 1.8 from source (gcc4.1 -O3) : 294.42 (what!?, the apt-get
version is _that_ bad?)
JRuby (-C) : 401.07
JRuby (+C, frameless) : 313.12

All times are measured in the program itself, i.e. startup and
compilation time is not included.

Sander Land wrote:
> Ruby 1.8 from source (gcc4.1 -O3) : 294.42 (what!?, the apt-get
> version is _that_ bad?)
>

If the packager doesn't pay attention to the compile options, it can be.
On Gentoo, compiling without pthread (USE=-threads) gave me at least a
x10 (not a typo) speedup in XML parsing and a modest +7% average speedup
on one complex Rails app (measured by the time spent running the test
suite).

Lionel

On Wed, 9 Jan 2008, Lionel Bouton wrote:

> Sander Land wrote:
>> Ruby 1.8 from source (gcc4.1 -O3) : 294.42 (what!?, the apt-get
>> version is _that_ bad?)
>>
> If the packager doesn't pay attention to the compile options, it can be.

Erm.

> On Gentoo, compiling without pthread (USE=-threads) gave me at least a x10

You don't want to say Debian should use "-threads" and thus not allow its
users to use the Tk library which requires "-threads"?

> (not a typo) speedup in XML parsing and a modest +7% average speedup on one
> complex Rails app (measured by the time spent running the test suite).


--
-----------------------------------------------------------
Tomas Pospisek
http://sourcepole.com - Linux & Open Source Solutions
-----------------------------------------------------------

Tomas Pospisek's Mailing Lists wrote:

>> If the packager doesn't pay attention to the compile options, it can
be.
>>
>
> Erm.

Oups ?

I only said "can" which only refers to a possibility as:
- I didn't use Ruby on Debian/Ubuntu much (yet),
- but I just read a 2x perf increase report after recompilation and
remembered other such reports last year on this list.
Can you comment on the tradeoffs these reports might have made unknowingly?

> You don't want to say Debian should use "-threads" and thus not allow
> its users to use the Tk library which requires "-threads"?
>

"USE=-threads" in my post refered to an option disabling pthread support
in one of my Gentoo setups which has not much to do with the more common
perf increases reported (most of them on Debian/Ubuntu).

BTW, technically Tk can be supported wihtout pthread if Tk isn't
compiled with it itself... IIRC the problem is the same with most libs
Ruby interfaces with: if it's compiled with pthread, Ruby must too.

In a binary distro, you have to make choices though and it's perfectly
understandable that disabling pthread nearly everywhere in Debian just
to solve the performance problems of a very small minority is not OK.

Unless all the reports of increased performance on Debian/Ubuntu are
based on unknowingly disabling pthread (ldd /usr/bin/ruby anyone?) this
subject isn't really interesting though.

Lionel

On Thu, 10 Jan 2008, Lionel Bouton wrote:

> Tomas Pospisek's Mailing Lists wrote:
>
>>> If the packager doesn't pay attention to the compile options, it can be.
>>>
>>
>> Erm.
>
> Oups ?
>
> I only said "can" which only refers to a possibility as:
> - I didn't use Ruby on Debian/Ubuntu much (yet),
> - but I just read a 2x perf increase report after recompilation and
> remembered other such reports last year on this list.
> Can you comment on the tradeoffs these reports might have made unknowingly?
>
>> You don't want to say Debian should use "-threads" and thus not allow its
>> users to use the Tk library which requires "-threads"?
>
> "USE=-threads" in my post refered to an option disabling pthread support in
> one of my Gentoo setups which has not much to do with the more common perf
> increases reported (most of them on Debian/Ubuntu).
>
> BTW, technically Tk can be supported wihtout pthread if Tk isn't compiled
> with it itself... IIRC the problem is the same with most libs Ruby interfaces
> with: if it's compiled with pthread, Ruby must too.
>
> In a binary distro, you have to make choices though and it's perfectly
> understandable that disabling pthread nearly everywhere in Debian just to
> solve the performance problems of a very small minority is not OK.
>
> Unless all the reports of increased performance on Debian/Ubuntu are based on
> unknowingly disabling pthread (ldd /usr/bin/ruby anyone?) this subject isn't
> really interesting though.

There was a thread a while ago about performance numbers here and the two
variables influencing it were, AFAICS, "-threads" and ruby version number (i.e.
1.9 being much faster).
*t

--
-----------------------------------------------------------
Tomas Pospisek
http://sourcepole.com - Linux & Open Source Solutions
-----------------------------------------------------------

Sander Land wrote:
> With all the blog posts about JRuby being posted, I thought I would
> finally try JRuby myself.
> I tested it on my genetic algorithms library. Lots of metaprogramming
> going on in the initialization, and a lot of calculations afterwards
> using the generated modules and classes.
>
> First tried my tests.
> Finished in 34.726 seconds.
> 33 tests, 626 assertions, 0 failures, 0 errors
> That's better than 1.9, which couldn't handle some of the metaprogramming.
>
> Then tried a benchmark:
> 1.8 : 676.75 seconds (ubuntu/apt-get)
> 1.9 : 161.99 seconds (svn/-O3/no enable-pthread)
> JRuby: 302.23 seconds (java opts -server, jruby +C)
>
> Did JRuby just outperform 1.8 by a factor >2 ?
> I'm impressed. Great job JRuby team.

What Java version is this?

- Charlie

On Jan 10, 2008 12:35 AM, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
> What Java version is this?
>
> - Charlie

$ java -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)

Sander Land wrote:
> On Jan 10, 2008 12:35 AM, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
>> What Java version is this?
>>
>> - Charlie
>
> $ java -version
> java version "1.6.0_03"
> Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
> Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)

Can I see the benchmark? I'd like to investigate why it's not still
faster than 1.8, even after -O3.

- Charlie

On Jan 10, 2008 2:40 AM, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
>
> Sander Land wrote:
> > On Jan 10, 2008 12:35 AM, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
> >> What Java version is this?
> >>
> >> - Charlie
> >
> > $ java -version
> > java version "1.6.0_03"
> > Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
> > Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)
>
> Can I see the benchmark? I'd like to investigate why it's not still
> faster than 1.8, even after -O3.
>
> - Charlie
>

The benchmark depends on a ~1500 line library. I can send you an email
when I have the next release (in a few days), but I'm not sure if
digging through the library would be an effective use of your time.
The benchmark show that JRuby is a little slower, independent of the
specific selection, crossover or mutation algorithm used. The only
thing in the inner loop that all of these algorithms have in common
are the fitness evaluations.

This script takes just the fitness evaluations, and it does seem the
problem is in this code:

require 'enumerator'
class RR
attr_accessor :genes
def initialize
@genes = Array.new(64){rand(2)}
end
def fitness
1 + genes.enum_slice(8).find_all{|e| e.all?{|x|x==1} }.size
end
end

require 'benchmark'
Benchmark.bmbm{|x|
x.report{ 200_000.times{ RR.new.fitness } }
}

1.8 -O3
user system total real
15.350000 0.160000 15.510000 ( 16.929467)

1.9 -O3, (with alias :enum_slice :each_slice)
user system total real
9.530000 0.000000 9.530000 ( 9.530245)

JRuby -C
user system total real
35.701000 0.000000 35.701000 ( 35.701000)

JRuby +C
user system total real
32.980000 0.000000 32.980000 ( 32.981000)

I also ran one of my other benchmarks (a function optimization test)
which uses the same library.
1.8 compiled : 81.39
1.9 compiled : 43.79
JRuby -C: 95.28
JRuby +C: 63.98

Sander Land wrote:
> The benchmark depends on a ~1500 line library. I can send you an email
> when I have the next release (in a few days), but I'm not sure if
> digging through the library would be an effective use of your time.
> The benchmark show that JRuby is a little slower, independent of the
> specific selection, crossover or mutation algorithm used. The only
> thing in the inner loop that all of these algorithms have in common
> are the fitness evaluations.

Yeah please do send an email then. I'd like to profile a bit and see if
there's some bottleneck you're hitting in JRuby.

> This script takes just the fitness evaluations, and it does seem the
> problem is in this code:

I'll have a look. On my system with Ruby compiled -O2 JRuby's equal or a
little faster, but that's a bit disappointing.

> I also ran one of my other benchmarks (a function optimization test)
> which uses the same library.
> 1.8 compiled : 81.39
> 1.9 compiled : 43.79
> JRuby -C: 95.28
> JRuby +C: 63.98

That's more the performance I'd expect to see.

- Charlie

Thanks for getting this release out - I've been tracking progress
on the blogs and mailing lists and was really looking forward to
seeing the results. Just to add another datapoint, here are some
timings for how jruby performs on a script that I run fairly
regularly. Its a REXML stream parser that parses the output from a
network scanning tool, and outputs any differences noted in security
issues identified by the the scanner. Its a script used for real work,
and not a synthetic benchmark.
For these runs, I ran each configuration 5 times on a fairly
quiescent CentOS machine, and averaged the results. The files that
were diffed were added up to almost 19MB total. The Ruby build is a
little older (1.8.4) and the Java VM is relatively recent ( 1.6.0_02)

Time Version
2m18.463s Ruby 1.8.4
3m45.140s JRuby 1.1RC1
2m40.635s JRuby 1.1RC1 -J-server
2m50.922s JRuby 1.1RC1 -J-server +C
2m36.970s JRuby 1.1RC1 -J-server -J-Djruby.compile.frameless=true
2m33.344s JRuby 1.1RC1 -J-server -J-Djruby.compile.frameless=true -J-
Djruby.compile.boxed=true

The difference in times between the last 2 runs is small enough to
be within the margin or error for these sorts of things. It is pretty
close to the speed of the 1.8.4 Ruby interpreter, but not quite there
- it would probably be competitive maybe even a little faster if the
JVM startup and code compilation overhead were amortized over a much
longer run.

Steve

Steve Chan wrote:
> Thanks for getting this release out - I've been tracking progress
> on the blogs and mailing lists and was really looking forward to
> seeing the results. Just to add another datapoint, here are some
> timings for how jruby performs on a script that I run fairly
> regularly. Its a REXML stream parser that parses the output from a
> network scanning tool, and outputs any differences noted in security
> issues identified by the the scanner. Its a script used for real work,
> and not a synthetic benchmark.

Thank you for this...we're actually looking at some REXML performance
issues this weekend. Unlike most other Ruby code, REXML seems to perform
more poorly than MRI. It's contrary to what we would expect, so there's
something wrong. It's a confirmed performance bug

If you have any scripts or benchmarks you can send us, we'd appreciate it.

- Charlie