

Introducing Surinx (Ruby syntax w/ Java typing) - fogus
http://blog.headius.com/2009/08/introducing-surinx.html

======
raganwald
The Fibonacci implementation here:

[http://github.com/raganwald/homoiconic/blob/master/2008-12-1...](http://github.com/raganwald/homoiconic/blob/master/2008-12-12/fibonacci.md#readme)

Does a pretty quick job using plain-old-old-ruby (POOR Implementation):

    
    
        time ruby /Users/raganwald/Desktop/matrix_fib.rb   102334155
    
        real    0m0.012s
        user    0m0.007s
        sys     0m0.004s
    

That doesn't mean we shouldn't welcome implementation improvements, but in my
lifetime the quest for a "sufficiently smart compiler" that will do away with
thinking programmers has enjoyed only modest success.

Append: This is _not_ a criticism of Charles' amazing work dragging Ruby into
the 1980s and designing Ruby-like languages for the JVM. If asked to choose
between algorithm improvements and implementation improvements, I answer
"Yes!"

~~~
wingo
Neat hack, but needless, and besides that, irrelevant: the author didn't
really care about the fibonacci sequence. He cared about function calls and
additions.

See Performance and Evaluation of Lisp Systems,
<http://www.dreamsongs.com/Files/Timrep.pdf>, for more discussions of the
nature of benchmarks.

~~~
raganwald
Thank you, I am aware that the author was deliberately picking a "most
pessimum" algorithm as a benchmark. I am not commenting on the nature of
benchmarks, but rather on the relative importance of algorithms and
implementations.

You may find it irrelevant to the author's point, others may find it an
interesting byway to follow in a larger conversation. Or not.

~~~
dminor
OK, but the implementation layer is just another layer of algorithms, except
that you have somewhat less control over it. I notice your code uses inject,
which is coded in C rather than Ruby -- as are many parts of POOR where C
offers better performance.

The point of Duby/Juby is to give us _more_ control over these algorithms by
dragging them out of the base implementation language and into Ruby. Why
should inject be written in C or Java?

~~~
raganwald
> Why should inject be written in C or Java?

I agree with your point and bless you with a mighty upmod. One of my peeves
about inject being written in C is that there is very little pressure to make
Ruby fast enough that inject could be written in Ruby. So who cares? Well, if
you want to make your own language feature that is like inject but not inject,
your feature will be 100x slower.

So making Ruby fast enough that Ruby can be implemented in Ruby is a huge win
for metaprogrammers :-)

> Now it is not correct to say that Matz does not use Ruby. He does, and so he
> does eat his own dog food. And for the domains where he uses Ruby, he has
> optimized Ruby to be a useful tool. But since he doesn’t use Ruby to build
> Ruby, he does not have the same incentive to tune Ruby for the purpose of
> building languages.

[http://weblog.raganwald.com/2006/11/significance-of-meta-
cir...](http://weblog.raganwald.com/2006/11/significance-of-meta-
circular_22.html)

~~~
stcredzero
Smalltalk Agents had no "primitives." (Read, no methods written in C.) The JIT
was deemed good enough that everything could be written in Smalltalk.
VisualWorks still has primitives, but a surprising number of things are
written in Smalltalk, like Dictionary lookup.

------
megaduck
One of the beautiful things about JRuby is that for performance-intensive
code, you can drop to Java instead of dropping to C. Java's almost as fast,
and a whole heck of a lot nicer to program in.

If Surinx is able to produce Java-like speeds, that means that you never have
to drop out to a different language _at all_. That's pretty awesome, and it
would open up a whole new world to Ruby programmers.

I hope some of this work gets pushed into JRuby. I'll take 5x speed boosts any
day, constant factor or not.

------
apgwoz
> ... fib(40) in only 7 seconds on current MLVM (OpenJDK7 + invokedynamic and
> other tidbits), a five-fold improvement over JRuby's fastest mode (jruby
> --fast).

I was going to say, "damn, that's it? that's pretty slow" until I realized:

    
    
       $ time python fib.py 40
       102334155
    
       real    1m43.363s
       user    1m36.824s
       sys     0m0.577s
    

It may be the fact that I have a ton of stuff running on my machine right now,
but still.

~~~
lliiffee
Does fib.py use psyco? If not, that does still seem slow. Standard numerical
benchmarks indicate that c or fortran or whatever should have a much larger
speed advantage relative to regular python than 40/163. E.g. on the n-body
benchmark here:

[http://shootout.alioth.debian.org/u32/benchmark.php?test=nbo...](http://shootout.alioth.debian.org/u32/benchmark.php?test=nbody&lang=all)

Python is about 65 times slower than c/c++/java/fortran/scala.

~~~
apgwoz
No, it doesn't use psyco. If it did, I'd expect it to be faster of course.

I just rewrote it in C though:

    
    
       $ time ./fib 40 
       102334155
       real    0m3.063s
       user    0m2.912s
       sys     0m0.014s
    

Which makes the python version something like 35x slower in wall clock time.

~~~
ginkgo
Or you could simply make your python code tail-recursive:

    
    
      $ time python fib.py 40
      102334155
    
      real	0m0.013s
      user	0m0.000s
      sys	0m0.010s

~~~
apgwoz
Of course you can, but that's not going to work when you run out of stack
space. The point of my stupid benchmark was to write the equivalent ruby code,
and then the equivalent C code, forgetting the fact that there's a much more
optimal way to do it (e.g. write it in scheme with tail calls).

~~~
apgwoz
> was to write the equivalent ruby code,

that should have stated "equivalent python code"

------
megaduck
One thing to remember about a lot of JVM language benchmarks is that they
include the startup time for the JVM. Java code running on a pre-warmed JVM is
significantly faster, and for short programs can be faster by an order of
magnitude (or two).

For a good example, check out Nailgun
(<http://martiansoftware.com/nailgun/background.html>).

------
donw
I never stop being impressed by Charles (the JRuby lead dev)... remind me to
ship a case of the Sierra Nevada Hefeweitzen to Engine Yard.

The best thing is that this will likely percolate into JRuby, and it bodes
well for JRuby performance on JVMs that support invokeDynamic (not sure if
OpenJDK does yet...)

~~~
rogerthat
You are reminded to ship a case of the Sierra Nevada Hefeweitzen to Engine
Yard.

------
snprbob86
Boo is a similar project with Python and .NET:

<http://boo.codehaus.org/>

------
lucifer
There are so many (new) languages for the JVM; its becoming a curse of plenty!
(Not complaining.) Its a great platform, and invokedynamic will usher in a
whole new generation of languages.

Lets just hope the Java 7 actually happens given the change of ownership, and
I would love to see John Rose's call for programmatic access from Java
(<http://blogs.sun.com/jrose/entry/jsr_292_support_in_javac>) realized. (ASM
is great stuff, but I'll admit that its not a great joy to use for me.)

------
mey
Or you could just use Groovy.

------
jrockway
Java has a type system?

