Maximum PC

Good catch on BlueJ. VS has changed pretty substantially over the years, right?


Please. That is the same BS arguement that RedHat gave for their 'compiled' version of Eclipse. It didn't run any faster and was even more buggy than the regular version (this was quite a while back -- I doubt that Eclipse is very buggy). Also, NetBeans seems just as fast on my machine as VS, and I'm pretty sure that VS isn't written in Java.

Hmm, well I tried netbeans before and it was moderately slow compared to VS and JCreator. To each his own I suppose, and it also doesn't help that the computer I tried it on was somewhat old (2003). Also, I've made some little programs in Java with GUIs and it seems like Swing really sucks the performance out of everything. Then again, the machines we had at school were PIII 900mhz machines, and for some reason mine was actually at 600mhz for some reason, but native code ran fine so I think Swing is still to blame. The fact is that no matter what, even in a best case scenario the Java code is still running through a VM, even if the difference is hardly noticeable on a faster computer.

Creating a fast, responsive GUI in any language is a bit of an art. I won't argue that Swing is fast, but I've seen and written enough Swing apps to know that it usually isn't the library causing the problems.

BTW, you may want to take a look at the changes in Java 6. Swing changeg quite a bit since Java 5.


Unfortunately, this frequently given arguement is flawed. It is probably easiest demonstrate why by exposing a hole in the similiar arguement that hand-written assembly code is always faster than the code generated by a compiler. Taken at face value, it would seem true that an experienced assembly language programmer should be able to write better/faster code than a compiler. However, it turns out that the compiler writers know all the same tricks as the assembly language programmers (often more) and the well written compiler is able to do a much better job at analyzing the code (in much the same way that deep blue would kick all of our collective butts in a game of chess -- including the authors). Hennessy and Patterson, who created the MIPS and RISC architectures, discuss this in their book.

Now you might be saying to yourself that this isn't exactly an apples/oranges comparison (and you'd be right). However, by delaying compilation until runtime, a JIT compiler is able to take advantedge of optimizations that are not available to a normal compiler at compile time. Also, the Java language doesn't have pointers which makes it possible to optimizations that are next to impossible in other languages.

Anyways, I'm not saying Java is faster. On average, I suspect it is about 10-20% slower than C++ or Ada and probably 15-30% slower than C or Fortran. However, you'll be hard pressed to notice the difference in most apps, especially networked or disk bound applications. As with the GUI example above, more often than not, any perceived slowness is the fault of the programmer. I'll create a second post supporting this postion in a second.

* Outside of the well known issue with trig functions on x86 hardware.

In March of 2006, TopCoder began offering a new type of programming contest called a Marathon Match. Unlike a traditional programming contest where you are competing to submit a correct solution in the least amount of time, the Marathon Match problems often involve variations on 'hard' problems and competitors compete by submitting the best answer they are able to find in under a given time limit (say 10s).

In terms of the enviroment, the contest is pretty wide open. You are able to submit solutions in the following languages: Java, C++, C#.NET, VB.NET, or Python. The Intel Multi-core matches allowed competitors to utilize all of the cores on a quad machine. Competitors are even allowed to use inline assembly and precomputation techniques.

Example problem: You are given the connectivity information for 10 million cities and must return the minimum tour. This is obviously the famous TSP problem, and as most of you know, you're (probably) not going to find the best answer for a graph of this size (unless you get lucky and you certainly won't be able to prove it). However, the goal isn't to find the optimal answer... you just have to find a better one than all of the other competitors.

If you stop to think about it, a 'fast' programming language should offer someone quite an advantedge on this type of problem, right? Below are partial results for the Marathon Matches 28 and 29, the last two non-tournament matches that have been held:


Sorry about the messy table; it is such a pita to present this type of data on the forum. The first column is the rank, the 2nd and 3rd the results for match #28, and the 4th and 5th results from match #29. At least to me, it seems pretty clear that both Java and C# are doing quite well in this type of contest despite their alledged shortcomings in speed. Just my .02 on the subject.

I also believe that people often forget that languages have evolved as problem domains grew. You're right, at face-value, Assembly would kick butt - the difference is like watching James Bond race Larry the Cable Guy. However, this would only be true if the problem domain(s) remained at a constant.

I looked at your tables, and I noticed that Java/C# where ahead. I wonder why? These compiler writers aren't stupid, like you said, they know tricks that even seasoned Assembly writers know. Plus, with the advent of managed code, memory management is more optimized because you don't have to worry about freeing resources manually. Also, compiler writers have written compilers that are built to handle larger problem domains, and have more optimized assembly code for it. I remember that the first time I saw that java was faster than gcc, I was a bit surprised but through experience in working with managed languages, I realized why it was faster: they're highly evolved languages with very specific attributes that are designed for very specific problem domains. This is why java/C# rules in performance though, at a glance, it seems slow.

A quick caveat. I want to try and make sure that the results don't mislead people. The ranking is NOT determined by finding the correct answer in the least amount of time. It is determined by finding the best solution to a computationally expensive problem in a given amount of time.


I would even go further and say that they are much more likely to be current and more knowledgable with regards to performance optimization research.

And I think that it goes without saying that compiler writers aren't stupid. =)

Aha! Ok, I misunderstood the test results. But that still doesn't diminish C#/Java's power. That still shows that these languages have been fine tuned for these types of problems, so I don't know why people keep harping on C#/Java as being "slow".



I hope not, I pay a lot of money to buy Visual Studio, so I hope that at least they do their research. ;P