From: Charles O Nutter Date: 2006-07-29T00:21:48+09:00 Subject: Re: For performance, write it in C - Part 2, comparing C, Ruby and Java ------=_Part_50352_26814096.1154100104655 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Man, I needed a good laugh today. Where to begin... On 7/28/06, Peter Hickman wrote: > > This is the follow up to my "Write it in C post" and is intended to > report the timings for the Java implementation that I said I would write > for Charles O Nutter and the Ruby version by Simon Kroeger. First let us > deal with the Ruby version. You start off right, but it's quickly apparent you're setting out to prove Java claims wrong. You're starting off with a specific intent. The program differs from the Perl and C versions in that the various > values it requires are not precomputed. Simon's program is completely > self contained. > > [Latin]$ time ruby latin.rb 5 > r5 > > real 0m35.793s > user 0m32.081s > sys 0m0.843s Not bad, really, but not even as good as the bogus Java numbers below. This quite clearly pisses all over the Perl version, and yes the results > were correct. Both faster than the Perl version and considerably less > code, a testament to the power and expressiveness of Ruby. So then Java is obviously more powerful since the bogus numbers are faster...you can't draw one conclusion from Ruby numbers and another conclusion from Java numbers. You're serving the food before setting the table. Now the Java version. I will be honest here, I might be paid to program > in Java but it hasn't been my language of choice since around 1992. I > find it gets in my way and today it found yet another way to do it. > > A straight translation like the C version worked fine for a 4 x 4 grid > but when I got to the 5 x 5 grid I got the following error 'code too > large'. Yes Java has hard coded limits as to the allowed size of various > data structures within class files and the Compared array of 120 x 120 > boolean values could not be initialised with the following code: As another posted, Java hasn't been around since 1992, so I think perhaps you're mistaken. private static boolean[][] Compared = { > {false, false, ... > ... > {true, true, ... > }; > > I had to have a whole load of 'Compared[0][44] = true;' and the like to > get the data in. This got the 5 x 5 grid to run but the 6 x 6 grid blew > up even that. Java has a 64Kb limit for various structures in the class > file (see > http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html > ). > The last time that I had to work round such mind numbingly arbitrary > limits was when I was programming Quick Basic. Now the timings. First off, I call Troll. Second, you're not a very good Java programmer if you didn't know about this limit. Perhaps they didn't teach you this in Java class in 1992? (a response troll, admittedly) The limit is not arbitrary; it's to allow the JVM to maintain certain constraints over the memory used by incoming class definitions, since they're typically not garbage collected. It would not be advisable to allow loading an extremely large class definition into permanent memory space, eating up the entirety of the heap. Put your gigantic data in a separate file and load it at runtime. [Latin]$ time ./j_version.sh 5 > j5 > > real 0m29.553s > user 0m13.813s > sys 0m10.745s > > Sorry Java fans but "as fast as C" or "faster than C" it is not. It's > only a bit faster than Ruby despite having much more resources being > dedicated to speeding it up. Startup time is and always has been a concern with Java apps, which is why their area of choice is primarily long-running server-side applications or somewhat less-long-running desktop applications. For example, would you benchmark the speed of Excel's calculation algorithms from the time you start it up until you'd entered the numbers in and told it to calculate? To do so would be absurd. If you want to put languages on a level playing field you must remove limitations that each incurs for different reasons than the others. I'd also remove any Ruby load/parse time before running any benchmark, since that's skewing numbers too. Are we benchmarking the performance of the language implementation or benchmarking how fast we can load Ruby's couple hundred k of executable data versus Java's many megabytes of base platform code? Compare apples to apples, man, and just benchmark the algorithm. The really odd thing here is that Java should actually be much faster > than this. I did manage to get the 4 x 4 grid to be written with the > same initialisation method as the C version and the timings (admittedly > on a much smaller problem) were much closer to the C version for the > same 4 x 4 grid. The solution just didn't scale because of the 64Kb > limit in the class files, which is probably not going to be change any > time in the near future. No, it's not. You shouldn't stuff data into your class files. Class files are for code. In the interest of fairness I also looked at the timings of just the > execution of the C and Java version so that the performance of the > compilers were not impacting the times. So here is the C and Java > versions without the precomuting phase and without the compiling. > > [Latin]$ time ./latin > /dev/null 2>&1 > > real 0m1.961s > user 0m1.680s > sys 0m0.051s I'm actually surprised C wasn't even faster here. [Latin]$ time java Latin > /dev/null 2>&1 > > real 0m15.483s > user 0m9.641s > sys 0m4.280s Some versions of Java have taken as much as 15 seconds to start up on certain platforms, and the startup time on Linux is frequently slower than on other platforms. Java 5 on Windows takes perhaps a second to start up now, primarily because they do use a shared-memory cache of much of the static data loaded at startup. Of course, it's not a startup cost of zero, but people simply don't use Java for command-line tools. There you have it, C is still faster by an order of magnitude. > Performance is yours for the asking, but it comes at a price - you have > to write it in C. Ease of development also comes at a price, you don't > get the same performance as C. Of course if you have a fear of C this > does show that you can go some of the way by converting to Java, if that > is fast enough for you then well and good but know this, C is faster. I have no fear of C. I have fear of making C work everywhere, which I do not have to worry about with either Ruby or Java. I also have a fear of C fanboys giving up on improving Ruby and always advising that people drop to C for their problems. -- Contribute to RubySpec! @ www.headius.com/rubyspec Charles Oliver Nutter @ headius.blogspot.com Ruby User @ ruby.mn JRuby Developer @ www.jruby.org Application Architect @ www.ventera.com ------=_Part_50352_26814096.1154100104655--