After writting last entry on installation of .NET and Java runtimes I did a bit of searching. I noticed that one of very popular contest is .NET versus Java or C/C++ versus Java or C/C++ versus .NET (ok, I haven’t actually seen the last one in the wild, but I am sure it exists).

I have worked with all languages mentioned above. Assuming competent programmers, C/C++ with good compiler wins. Java and C# are usually about the same. I recently participated in one of the contest of topcoder.com. This confirms my statement. Also, keep in mind that coders in this contest are quite good and that Intel optimizing compiler is used, which supports SIMD (Single Instruction Multiple Data) instructions and is supposed to do vectorisation and other cool stuff.

Now, the funny part. For the many (most?) applications language (and platform) speed is not important. Even if one platform is 2x faster then the other, that is relatively unimportant. Of course, there are exceptions. You want games to be fast, image and video processing should be fast. But once application response time for any input is below, say, 0.1 s, there is rarely reason to optimize it.

I have been doing quite a lot of Ruby (on Rails and pure Ruby). Now, Ruby is slow. But writting code is fast (Rails is also awesome web framework). You might not want to base your Google killer search engine on Ruby but for many applications, Ruby is fast enough.

Now, I will stop talking and actually do some testing. Below is source code for very simple performance test.
The code itself has no significance. I only wanted two loops and some operations. Timing was done from batch files.
Timer started before the program was started and ended after program exited. So start-up times WERE included in the time.

C#


using System;
class Perf
{
public static void Main()
{
long val = 0;
for (int x = 0; x < 10000; x++)
{
for (int y = 0; y < 100000; y++) val += y + x;
}
Console.WriteLine("Val = {0}", val);
}
}

Java


class perf
{
public static void main(String[] args)
{
long val = 0;
for (int x = 0; x < 10000; x++)
{
for (int y = 0; y < 100000; y++) val += y + x;
}
System.out.println("Val = " + val);
}
}


C++


#include
using namespace std;
int main()
{
long long val = 0;
for (int x = 0; x < 10000; x++)
{
for (int y = 0; y < 100000; y++) val += (y + x);
}
cout << "Val =" << val << endl;
return 0;
}

Ruby

val = 0
0.upto(10000) do |x|
0.upto(100000) do |y|
val += x + y
end
end
puts "Val = #{val}"

This was run on 1.7 Ghz IBM Thinkpad with 1.5Gb of RAM and Windows XP Professional SP2 (not that RAM is important here, maybe in some other test?). Each test was run a couple of times and best time was recorded.

Java 1.5 (command line: java perf -server)
6.84 seconds

C# 2.0, without ngen.exe (code with ngen.exe was .3 seconds slower, go figure ):
4.02 seconds

C++ (compiled with cl cpp_perf.cpp /Og /Ox)

2.97 seconds

Ruby (it was so slow, I ran it for 1% of cases and extrapolated)
3861 seconds (yes, there is no dot in there. It is more that 1 hour).

Now, what does that tell us? First, you should not use Ruby (or any other scripting language) for numberic processing. Really, they are not intended for that.
Now, if you are Java guy and feel that C# "won" this round, you are mistaken. If 50% speed increase in numberical processing is significant for you, neither C# nor Java are right for you. C++ is the way to go. I used MS Visual C++ (from MS.NET 2005). If I used intel compiler, things might be different.

The moral of the story is: C++ for performance critical things (e.g where number chrunching performance factor 2x is an issue. It happens less than you would think). C#/Java have "good enough" performance for most tasks. Pure numerical performance should not be a factor in deciding which language to take (for c# vs. java).
Ruby shows the weakest point of scripting languages - pure speed. But once you start being limited by other things (databases, web services, file system - pure speed becomes less and less of an issue).

And keep in mind, even handcrafted assembly code bubble-sort code written for exact hardware will lose agains quicksort algorithm (even if written in Ruby...). At least for large enough number of elements.