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!"
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.
That basically uses dynamic programming, which is "cheating". (It is a linear time algorithm instead of exponential!) Different compilers will almost always just give us constant factor improvements. Smarter algorithms will always beat that, but sometimes a smart algorithm with a slow compiler still isn't fast enough.
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.
> ... 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.
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:
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).
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...)
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.)
[+] [-] raganwald|16 years ago|reply
http://github.com/raganwald/homoiconic/blob/master/2008-12-1...
Does a pretty quick job using plain-old-old-ruby (POOR Implementation):
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|16 years ago|reply
See Performance and Evaluation of Lisp Systems, http://www.dreamsongs.com/Files/Timrep.pdf, for more discussions of the nature of benchmarks.
[+] [-] lliiffee|16 years ago|reply
[+] [-] megaduck|16 years ago|reply
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|16 years ago|reply
I was going to say, "damn, that's it? that's pretty slow" until I realized:
It may be the fact that I have a ton of stuff running on my machine right now, but still.[+] [-] lliiffee|16 years ago|reply
http://shootout.alioth.debian.org/u32/benchmark.php?test=nbo...
Python is about 65 times slower than c/c++/java/fortran/scala.
[+] [-] megaduck|16 years ago|reply
For a good example, check out Nailgun (http://martiansoftware.com/nailgun/background.html).
[+] [-] donw|16 years ago|reply
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|16 years ago|reply
[+] [-] unknown|16 years ago|reply
[deleted]
[+] [-] snprbob86|16 years ago|reply
http://boo.codehaus.org/
[+] [-] lucifer|16 years ago|reply
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|16 years ago|reply
[+] [-] jrockway|16 years ago|reply