OSNews

It is not so much the speed of calculating a sieve that is the problem, it is the tendency for whole new frameworks to be layered on top of others almost endlessly.

It may not be 200 times slower, but it is slower. It's on average in the same order of magnitude as C/C++ across a series of benchmarks, which for most people is about the same speed. For a good idea of actual relative performance, see the Great Computer Language Shootout. The issue of speed being in the same order of magnitude doesn't matter for applications centered around small packets of work interrupted either by I/O or user think time. But even that depends on the application.

In graduate school I did quite a bit of Genetic Algorithm related classwork. This was purely compute intensive code. In some of the more interesting applications the fact that Java is 2x the speed of similar code under C means 2 weeks of runtime instead of 1 week of run time. If the code was largely computational, that didn't do a lot of I/O, I would use Java because it's a very productive language to work in. JDK 4/5 didn't seem to have the same I/O performance as straight C. Having no evidence, I always assumed this had to do with the layers of library code surrounding Java I/O.

If you start adding in issues like memory usage, the picture becomes murkier. Java requires significantly more memory than the equivalent C code. Depending on the version of the VM started up, the difference can be megabytes (for the VM and program) versus kilobytes (for the C code). The libraries layered on top of all this burn even more memory. For example, Rails using C Ruby versus JRuby. They both execute Ruby code, but JRuby deployed in a J2EE environment easily requires 512 of megs of memory to do what C Ruby does in about 20-50 megs of Ram.

Like anything in life, it's a trade off. Java is a very productive language with a huge world of libraries. For many businesses this represents a real cost savings for their custom, line of business applications. It is not the panacea that most Java developers pretend it is. In some cases the speed difference is real and can't be ignored. In some cases Java is actually faster than C due to run-time optimizations that C can't do (as it stands). However, it seems like we have to buy large, more capable servers (in some cases with 4 times the ram and 2 times the speed) just to do the same or a little bit more work than what we did last year. Part of that is the result of these huge frameworks that are not intrinsic to Java but come along for the ride (weather we want them or not).

But these days buying hardware with 4 times the memory and twice the speed can be cheaper than getting the same app developed in C/C++ ...

You're making that up. JRuby actually uses LESS memory than C Ruby. JRuby 1.0 might have used about the same or a bit more, but we've never used ten times as much memory. And JRuby 1.1 consistently uses less memory than C Ruby. Or are you referring to an entire Rails app under JRuby with ten instances (to be able to handle ten concurrent requests) versus a single C Ruby instance (which can only handle one?) Both JRuby and C Ruby must start up multiple instances to handle concurrent requests in Rails. The difference is that JRuby does it automatically (configurable) and C Ruby does not. When you run both with the same number of instances, JRuby will win every time.

Check your facts please before you post comments like this.

Many of us had our first go at running Java desktop apps back in the mid 90s. Unfortunately, Swing was very slow at that point and this created the myth, in the mind of many people, that Java is slow.

I think that Java could have made massive inroads into the desktop if only Sun had worked harder to polish Swing performance in the early days.

Today, Java desktop apps are not exactly slow. But the slowness has been replaced by a tendency to be horrendously irritating. Download LimeWire and you will quickly become afraid to move your mouse. Because every time you move it, say, a quarter inch, you get a new and annoying popup giving you all the gory details about another song you didn't really care about, and blotting out your view of something that you *did* care about.

The only java based, full fledged application I have any experience with is Eclipse and my experience has been that Eclipse is significantly and noticeably slower that other IDEs. It's usable on a fast, modern system with lots of memory but I have Linux loaded on a couple of older, slower boxes with half a gig of memory and using Eclipse on them is downright painful.

I'm also not sure I agree with either the original article or the response above when it comes to operating systems. I use a computer that is on the military's NMCI network on a daily basis. Because of government requirements, it's still running Windows 2k. It's not noticeably faster than similar machines running XP, but neither do I notice any significant decrease in capability.

I'm not saying Java or C# is faster than C++, and don't completely believe in these benchmarks. But I know that they are at least comparable. As far as you're doing the same work, the results are very similar.

It depends on the application, but I largely agree. I wrote a fairly CPU-intensive natural language processing application in both C++ and Java, and the C++ implementation was about 10% faster. Of course, this is in no way a scientific benchmark, but it shows that it does not matter that much (especially compared to Java sans JIT). Of course, the same application is awfully slow in Python or Ruby. Which enforces the old mantra: use the right tool for the job.

Of course, when comparing C++ and Java/C# there are much more interesting facets. For instance, language features like const-correctness, operator overloading, and templates are things I very much prefer in C++.

In this respect, I am very interested in the development of Digital Mars D, because aims to provide a good middle road between C++ and more dynamic languages.

I agree that broad claims such as the one in the post should not be made without a substantial study backing the claim.

That said, I can say that I've written a small data mining app for finding nearest neighbors in a dataset of 1M records. I did the implementation once in C++ using STL, and once in C#. The two implementations took nearly the same time to finish (on average over multiple runs).

That to me says that .NET is not slower than C++ when it gets to number crunching. A different type of app may behave differently though.