Re: Ruby and science ?

On Thu, Dec 16, 2010 at 9:39 PM, David Masover <[e-mail]> wrote:
> And JRuby is getting faster all the time. It's not clear whether one will
> necessarily beat the other.

We've always emphasized compatibility and bugfixes over performance,
and so while we handily beat 1.9.1 and earlier versions of Ruby a year
ago, these days it's a bit of a toss-up with 1.9.2. Even in the JRuby
1.6 cycle, we got in a little perf work...but soon moved priorities
back to implementing remaining 1.9.2 features. One of these days we'll
have caught up on all features, or I'll just decide I need to spend my
time entirely on performance :)

In general, though, if you find something that's notably slower than
1.9.2, please file a bug. There are areas where we know we're a bit
slower, but I'm sure there's areas we have bugs keeping us slow.

> In particular, I remember hearing discussions of a commandline flag in JR=
uby
> which one could use to disallow altering methods on the core numeric type=
s.
> This would basically make Ruby math compile down to Java math. I imagine =
most
> scientific applications wouldn't care about altering the core numeric typ=
es,
> while most scientific applications would care about fast math.

This would be the --fast flag. It used to help the performance of
small methods and math operations, but the bulk of its benefit is now
in JRuby master (1.6) by default:

~/projects/jruby =E2=9E=94 ../jruby-1.5.2/bin/jruby bench/bench_tak.rb 4
      user     system      total        real
  2.601000   0.000000   2.601000 (  2.537000)
  1.805000   0.000000   1.805000 (  1.805000)
  1.790000   0.000000   1.790000 (  1.791000)
  1.807000   0.000000   1.807000 (  1.807000)

~/projects/jruby =E2=9E=94 jruby -v bench/bench_tak.rb 4
jruby 1.6.0.dev (ruby 1.8.7 patchlevel 249) (2010-12-17 d2575a7) (Java
HotSpot(TM) 64-Bit Server VM 1.6.0_22) [darwin-x86_64-java]
      user     system      total        real
  1.810000   0.000000   1.810000 (  1.742000)
  1.058000   0.000000   1.058000 (  1.058000)
  1.053000   0.000000   1.053000 (  1.053000)
  1.057000   0.000000   1.057000 (  1.057000)

The next "big thing" that probably won't land in 1.6 is "dynopt",
which performs more runtime optimization of code:

~/projects/jruby =E2=9E=94 jruby -v -Xcompile.dynopt=3Dtrue bench/bench_tak=
.rb 4
jruby 1.6.0.dev (ruby 1.8.7 patchlevel 249) (2010-12-17 d2575a7) (Java
HotSpot(TM) 64-Bit Server VM 1.6.0_22) [darwin-x86_64-java]
      user     system      total        real
  0.912000   0.000000   0.912000 (  0.837000)
  0.518000   0.000000   0.518000 (  0.518000)
  0.516000   0.000000   0.516000 (  0.516000)
  0.517000   0.000000   0.517000 (  0.517000)

Both the 1.6 and the 1.6+dynopt results should consistently be faster
than 1.9 for small benchmarks.

For large benchmarks and real applications, performance almost always
comes down to the performance of core classes like String and Array.
At that point, it's mostly a matter of figuring out where the core
classes don't perform as well...and fixing them.

> About the only unintuitive thing I ever found was implementing a Java
> interface, and while it's somewhat unintuitive, it's still trivial:

If you have suggestions for how to improve it, we'd love to hear them :)

> # singleton comparator
> comp =3D Class.new {
> =C2=A0include Comparator
> =C2=A0def compare a,b
> =C2=A0 =C2=A0a.to_s <=3D> b.to_s
> =C2=A0end
> }.new
>
> pq =3D PriorityQueue.new 11, comp

You can also do:

Comparator.impl do |name, a, b|
  # name is name of interface method, check it or not
  a.to_s <=3D> b.to_s
end

Or this may work too (I don't remember PriorityQueue's API):

pq =3D PriorityQueue.new(11) do |a, b|
  a.to_s <=3D> b.to_s
end

> Oracle's behavior lately is making me kind of iffy about the future of Ja=
va as
> a platform, but JRuby is just made of awesome.

Oracle's actions relating to Java have all been political. At the same
time people publish that they're fighting with Apache or Google, they
are also getting IBM (GPL-haters) and Apple (not big OSS contributors)
to collaborate on the GPLed OpenJDK, and making concrete plans for
OpenJDK to continue beyond Java 8.

As far as *using* Java, nothing has changed for the worse in the past year.

> ruby-inline is very cool, but it's still not quite as easy as being able =
to
> write a Java class, pretend it's a Ruby class, and have it work.

There's also java_inline, an extension to ruby_inline I made that
allows you to write Java code inline like C code in ruby_inline:

https://github.com/jruby/java-inline

require 'java_inline'

class Foo
  inline :Java do |builder|
    builder.package "org.jruby.test"
    builder.java "
      public static int fib_java(int n) {
        if (n < 2) return n;

        return fib_java(n - 2) + fib_java(n - 1);
      }
      "
  end
end

Foo.new.fib_java(45)

Fun stuff.

- Charlie