 Will Java always be slower than C++
started 5/22/2001; 8:19:28 AM - last post 9/8/2001; 11:55:46 AM
|
|
Ehud Lamm - Will Java always be slower than C++ 
5/22/2001; 8:19:28 AM (reads: 2815, responses: 8)
|
|
|
|
andrew cooke - Re: Will Java always be slower than C++
5/22/2001; 9:47:16 AM (reads: 1747, responses: 0)
|
|
|
Point 2 (casts) will go soon, hopefully, but that's a side issue.
More importantly, the article doesn't discuss:
1 - what the difference in speed is (assuming a native code Java compiler)
2 - whether the trade-off is worth it
Personally, I work in a company where the time spent getting reliable, re-usable code out of the door is more important than the speed it runs at. I don't think that's unusual. Is speed really that big an issue these days?
{Added later) Another point - is language speed what determines program speed? Decent profilers are probably more useful, for example. What about algorithm choice? I'd rather hire someone who knows efficient algorithms than someone who knows how to exploit a particular language for speed (more maintainable code; more transferable skills).
|
|
Ehud Lamm - Re: Will Java always be slower than C++
5/22/2001; 10:38:13 AM (reads: 1668, responses: 0)
|
|
|
You are right that most of the time implementation details are the major factor in the speed of the produced code. However, it is possible that a language supoprts features that make it hard to optimize. A classic example is aliasing issues.
As to the importance of speed. It really depends on the programming domain. For most programming tasks one can easily find hardware that will give decent speed, so it is better to concentrate on design issues. However there are systems with very stringent timing needs. Consider a system that must run embedded on a TGV train. The embedded chip has very small memory space, and the timing of the controller software must match the speed of the train! In these hard real-time cases (planes are another common example) the speed of code can be critical, and is often one of the most important requirements from the software.
|
|
Chris Rathman - Re: Will Java always be slower than C++
5/22/2001; 10:54:33 AM (reads: 1719, responses: 0)
|
|
Point 2 (casts) will go soon, hopefully, but that's a side issue. Actually, GJ does not change the nature of the compiled VM bytecode. The cast is still done implicitly, it's just that an explicit cast is no longer required in the source code.
On the other hand, casts in C/C++ are not run time issues. Instead, they are comments to the compiler that says forget what you think the types are, this is what I mean. That basically short circuits any compiler checks on the type consistency and since C++ does not do run time type checking, that's the end of the story.
Bottom line is that C++ gains the speed because it does no runtime checking for types whereas Java (and Smalltalk) do. The costs in speed really have nothing to do with type casting, and everything to do with run time type checking and dynamics. So, the comparison should note that C++ sacrifices type checking for speed.
Another point - is language speed what determines program speed? Decent profilers are probably more useful, for example. It really depends on the nature of the application. For many applications, it is the external resources (database, network bandwidth, etc), that are the true bottlenecks of the application. That means that how you use those resources is a greater consideration for the speed than any optimization done by the compiler.
Of course, C more closely follows the abstraction of most computer processors, rather than being a higher level language. For problems that are closely related to computer processes, C will always be a better fit for the problem. OTOH, problems which are at a much higher level are much harder to code by hand. This usually means that an optimizing compiler can, on average, beat the typical hand coded solution - look at the performance of Objective CAML.
|
|
andrew cooke - Re: Will Java always be slower than C++
5/22/2001; 12:03:06 PM (reads: 1720, responses: 0)
|
|
|
No real argument here - I thought it was interesting that the one area I noticed in the article where C++ could argue that it was "higher level" than Java was in support for Intentional (IIRC that's another take on Adaptive) programming. Which brings us back to the power of macros ;-)
And I don't understand why OCaml is so fast compared to other functional languages. Weren't there some links a while back indicating that it did very little optimisation? Maybe the "fast" code is imperative (since it's impure) - just C in disguise? (I guess it's really more complicated than that...)
While I guess aeroplanes are weight-limited, what's the deal with hardware limits on the TGV? Age?
|
|
nickmain - Re: Will Java always be slower than C++
5/22/2001; 12:45:39 PM (reads: 1660, responses: 0)
|
|
|
One point not addressed is that of Hotspot. As I understand it, the Hotspot VM does real-time profiling of program activity and optimizes the bottlenecks (by native compilation and function in-lining).
I don't know how much of a difference this makes - but Sun makes big claims about the performance boost.
|
|
John Lawter - Re: Will Java always be slower than C++
5/22/2001; 2:18:59 PM (reads: 1667, responses: 0)
|
|
|
Hotspot can make a difference for long-running (e.g. server) applications. Optimization doesn't occur until the VM has passed through a code section at least once, so in some cases it won't make a difference, and in others it can even harm performance. Examples of this are in the O'Reilly Java Performance Tuning book. I'd like to see how Java/Hotspot or Java/Marmot compare with C and HP's Dynamo.
There was an interesting anecdote related to Java performance in a series of mails on Omni's MacOSX-dev mailing list. A developer claimed that he had gotten a Java fft to run faster than several comparable C implementations. He didn't present hard numbers, and no code was available to confirm the observations, but it does give food for thought. I don't find it difficult to believe that a good VM doing some clever whole-program optimizations and instruction scheduling may be able to get better performance than a generic C program.
|
|
Bryn Keller - Re: Will Java always be slower than C++
5/23/2001; 10:14:32 AM (reads: 1663, responses: 0)
|
|
|
In my experience, Hotspot does make a large difference even on the client. But not large enough to be useful for client-side programming. It may be possible to get a faster FFT out of Java, but GUIs using Swing are still (even with Hotspot) dead slow.
For example, I have a Python application which runs the same code (modulo an adapter layer) both under Jython with Swing and Python with Qt. On my Pentium III/500, it takes almost 30 seconds to present the logon screen under Java, and only 2 under C Python + Qt. Admittedly there's more going on in this example than Java, but my experience with Java on the client side has been very frustrating.
Add to this the fact that most of the Swing bugs I've had to deal with have been open for over 2 years now... (sigh)
|
|
Dejan Jelovic - Re: Will Java always be slower than C++
9/8/2001; 11:55:46 AM (reads: 1547, responses: 0)
|
|
Bottom line is that C++ gains the speed because it does no runtime checking for types whereas Java (and Smalltalk) do. The costs in speed really have nothing to do with type casting, and everything to do with run time type checking and dynamics. So, the comparison should note that C++ sacrifices type checking for speed.
Er... Not really.
First of all, C++ gives you two types of casts for casting between classes: static_cast and dynamic_cast. Static casts are performed without run-time checks, while dynamic casts peform run-time checks.
But that's beside the point. When writing C++ code I use almost no casts at all. In Java I can't avoid them if I want to write any generic code. And generics in Java 1.4 will not change that because types are stripped at compile time and what ends up in .CLASS files are again casts.
|
|
|
|