Perl Best Practices Advertising in RSS Feeds
Jun 23

Typical Benchmarks…. in Ruby Land

Java, Ruby, Tech Add comments

A Ruby newbie posted to Ruby Lang that he had implemented an is_prime? algorythm in Ruby, Perl, and Java with results:

  1. Ruby result: 101 seconds
  2. Java result: 9.8 seconds
  3. Perl result: 62 seconds

Ruby lang is a great community, and over time they broke down the code and got all of the versions to fractions of these numbers.

It again really showed:

  • How micro-benchmarks are a scary beast
  • The choice of the algorythm here made the biggest difference (good ‘old Big O). The right choice with Ruby was magnitudes faster than the wrong choice in C.
  • The power of CPAN and company, where everything you ever need is already done
  • Inline C. Mmm :/
  • FAST ENOUGH IS FAST ENOUGH

That being said, having Ruby grow up from the world of the interpreter would be very cool (YARV etc etc).

4 Responses to “Typical Benchmarks…. in Ruby Land”

  1. aaa Says:

    First of all, i am completely against current use of micro benchmarking. It is so commonly abused, and creates false bad impression and being used as a political tool instead of technical in many cases.

    However, performance problems are real. if a language or platform does not allow me to make performance improvements when i am having a performance bottleneck, then this becomes a problem. Java has this ability IMHO, it is fast enough for most of the high level operations, and it gives you the ability to make rather low level implementations (lets say rolling your own String or Collections objects, primitive operations etc.) JVM optimizations also effects this matter.

    This is in many cases not true for scripting languages (Ruby for example). When you have a big performance problem you are out of solutions and start digging for native language hacks.

    So, Java is doing well and i like it :). i think ruby would do well if it used the JVM too.

  2. Kirk Says:

    The problem isn’t with the microbenchmarking technique. The technique is a perfectly valid tool when applied correctly. But the key phrase is… applied corectly.

    Even with this benchmark, there appear to be some interesting conclusions. Biggest one is that choice of algorythm matters. Secondly, Ruby can do the job if you take care of the first point. Which brings me to my third point.

    Now I’ve not programmed in Ruby so I don’t have a clue on where it fits in my development effeciency scale but I do know that C/C++ don’t rate very highly on it. I would rate Smalltalk as a 1, Java as a 4, and C/C++ as a 10. IOW, it is my experience that what I’ve done is Smalltalk will take 4x longer to code in Java and 10x longer in C/C++. Now one may argue about the absolute values here but one cannot argue about the order. So at the end of the day, if Ruby does move me toward 1 or beyond, then I choose Ruby because my time is more important to me than the CPUs time is. Also, if I’m moving towards 1, then maybe I’ll have the time to make the proper choice of algorythm and in doing so not take so much of a performance penalty. After all, fast enough is not only good enough, it all that is required except for most business applications.

  3. Kirk Says:

    oops, last line should read

    After all, fast enough is not only good enough, it all that is required for most business applications.

  4. Rob Evans Says:

    Speaking of CPAN, I wonder if Maven and the Maven Repo will one day be to Java what CPAN is to Perl.

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: What is the number before 3? (just put in the digit)