jdaues
asked on
Java speed...more
I don't mean to be obsessive/compulsive about this, but I have to be certain.
I mention to people that Java is pretty much as fast as C++ nowadays, and I get the following responses.
1. "Oh, they took care of the little endian/big endian problem?"
I wasn't aware of the problem, I assume what is meant is speed lost due to little endian/big endian conversion.
2. "Benchmarks can be manipulated anyway you want"
3. "JIT compilers still build bytecode. How can it be as fast as C++?"
Anyone?
I mention to people that Java is pretty much as fast as C++ nowadays, and I get the following responses.
1. "Oh, they took care of the little endian/big endian problem?"
I wasn't aware of the problem, I assume what is meant is speed lost due to little endian/big endian conversion.
2. "Benchmarks can be manipulated anyway you want"
3. "JIT compilers still build bytecode. How can it be as fast as C++?"
Anyone?
Depending on what you're doing, C++ code will be anywhere from a few percent faster to 100% faster... Java's speed is excellent when it comes to server-side work, and much slower when dealing with GUIs (in Swing). But overall, Java's speed is more than sufficient to be used as a general purpose language... Any perceptible slowness today will be eradicated tomorrow by faster hardware :) (the "microsoft excuse"...)
You could always tell the C++ guys that you're willing to take a 5 or 10% performance hit in exchange for better class libraries, better development speed (it is simply easier to write lots of code in Java than C++, in my experience), fewer bugs (no pointers, leaked memory, etc.), no subtle side-effects because someone overloaded an operator without telling anyone else, and you don't have to put up with weird syntax rules (like the ability to put "const" in 15 different places on the same method declaration -- which forces all the other developers to insert those ugly const casts in their code)...
Not to mention the fact that you get cross platform code for free, have numerous high-quality free tools available...
For all the advantages, I'm more than willing to put up with a little slowdown in code execution...
You could always tell the C++ guys that you're willing to take a 5 or 10% performance hit in exchange for better class libraries, better development speed (it is simply easier to write lots of code in Java than C++, in my experience), fewer bugs (no pointers, leaked memory, etc.), no subtle side-effects because someone overloaded an operator without telling anyone else, and you don't have to put up with weird syntax rules (like the ability to put "const" in 15 different places on the same method declaration -- which forces all the other developers to insert those ugly const casts in their code)...
Not to mention the fact that you get cross platform code for free, have numerous high-quality free tools available...
For all the advantages, I'm more than willing to put up with a little slowdown in code execution...
1. Ya, Different operating system running a client-server program would run across this problem. CORBA was handling it for a a long time and Java also implements CORBA, plus some of their own stuff.
2. If they make the point irrevant then they also loose their own argument which had previously used the benchmarks as a winning point. HA! What is that? Benchmarks are only a valid arguement when they work for me, when not then trash them.
3. The JITs are faster than the normal compilers, that is what counts.
You also said "Java is pretty much as fast as C++", there is nothing wrong with that statement.
2. If they make the point irrevant then they also loose their own argument which had previously used the benchmarks as a winning point. HA! What is that? Benchmarks are only a valid arguement when they work for me, when not then trash them.
3. The JITs are faster than the normal compilers, that is what counts.
You also said "Java is pretty much as fast as C++", there is nothing wrong with that statement.
ASKER
nebeker said:
Java's speed is excellent when it comes to server-side work, and much slower when dealing with GUIs (in Swing).
While this is a client-server program, the client will be pretty thin, so client side speed isn't much of a concern.
How is it that Java is faster on the server side than the client side? I understand that, in the client side, it is slow to get from Java to native graphics routines, but not why it is faster on the server to go from Java to, for example, some other native function call.
Java's speed is excellent when it comes to server-side work, and much slower when dealing with GUIs (in Swing).
While this is a client-server program, the client will be pretty thin, so client side speed isn't much of a concern.
How is it that Java is faster on the server side than the client side? I understand that, in the client side, it is slow to get from Java to native graphics routines, but not why it is faster on the server to go from Java to, for example, some other native function call.
>>but not why it is faster on the server to go from Java to, for example, some other native function call
It isn't faster. The speed is a function of the processor and memory etc., not whether there happens to be a web server running.
It isn't faster. The speed is a function of the processor and memory etc., not whether there happens to be a web server running.
What I meant is Swing is slow... When I said that Java is faster on the server, I meant that server side apps don't generally run Swing GUIs...
Swing is slowER but the important this is whether it's *perceptibly slower*. I'm generally quite happy with how it performs on my system.
Swing is slow. Period. While it has been much improved in 1.4, it still is not snappy as a native Windows application.
On a 1 GHz machine with 512 MB of memory, I can easily notice where the slowdowns are happening..
Now don't get me wrong -- I really, really like Swing, and I would rather program in Java vs. any other language, and I'm happy to have the speed improvements in 1.4, but it is still not to the point where I'm happy with its speed...
Maybe when a 4 GHz Athlon is the "average" machine, it won't matter anymore. But right now, when the average user doesn't even have a 1 GHz box on their desk, the slowness of Swing is noticeable and can most definitely be an issue.
On a 1 GHz machine with 512 MB of memory, I can easily notice where the slowdowns are happening..
Now don't get me wrong -- I really, really like Swing, and I would rather program in Java vs. any other language, and I'm happy to have the speed improvements in 1.4, but it is still not to the point where I'm happy with its speed...
Maybe when a 4 GHz Athlon is the "average" machine, it won't matter anymore. But right now, when the average user doesn't even have a 1 GHz box on their desk, the slowness of Swing is noticeable and can most definitely be an issue.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Really I had very usefull information. In performance wise C++ is bit faster than Java but comparing to other advantages it is feasible. This is what I got from these conversation.
But it would be good if you guys are compared C# and Java because both has the same structure almost and has some unique features like platform/language independent.
thank u
siva
But it would be good if you guys are compared C# and Java because both has the same structure almost and has some unique features like platform/language independent.
thank u
siva
ASKER
ksivanath: Java / C# is an entirely different subject. I would suggest you post another question
ASKER
ksivanath: Java / C# is an entirely different subject. I would suggest you post another question
Jim -
You're right on the JIT issue -- I guess the rest of us aren't paying attention :)
It might be interesting to compare the performance difference between the normal JIT mode and specifying the flags "-XBatch -Xincgc". Part of the slowdowns in Java code come from running in interpreted mode while the JVM is compiling to native code in the background, and of course, the occasional pauses so the garbage collector can run.
With -XBatch, the startup time will be slower, but should then run the overall program faster. With -Xincgc, the JVM won't have to pause from time to time collecting garbage, so the little "hangs" should disappear... The -Xincgc does slow down the performance of the garbage collector, though, so I wouldn't use it in a system that is very generous with memory usage... (Of course, programs shouldn't be written like that in the first place...).
You're right on the JIT issue -- I guess the rest of us aren't paying attention :)
It might be interesting to compare the performance difference between the normal JIT mode and specifying the flags "-XBatch -Xincgc". Part of the slowdowns in Java code come from running in interpreted mode while the JVM is compiling to native code in the background, and of course, the occasional pauses so the garbage collector can run.
With -XBatch, the startup time will be slower, but should then run the overall program faster. With -Xincgc, the JVM won't have to pause from time to time collecting garbage, so the little "hangs" should disappear... The -Xincgc does slow down the performance of the garbage collector, though, so I wouldn't use it in a system that is very generous with memory usage... (Of course, programs shouldn't be written like that in the first place...).
No matter how 'scientific' the advocacy is, it will never have any impact on dearly held religious beliefs.
How true....
I remember back when C++ was just starting to become popular... All of the die-hard C hacks (myself included :), complained loudly that C++ was too slow to be used for "real" projects -- remember when C++ was translated to C first, then compiled?
Of course, after a while the hardware got faster, native C++ compilers were released and over the years progressed to the point where there was no real speed difference between C and C++...
It is humorous to see those very same C++ programmers using that argument now against the Java camp...
I remember back when C++ was just starting to become popular... All of the die-hard C hacks (myself included :), complained loudly that C++ was too slow to be used for "real" projects -- remember when C++ was translated to C first, then compiled?
Of course, after a while the hardware got faster, native C++ compilers were released and over the years progressed to the point where there was no real speed difference between C and C++...
It is humorous to see those very same C++ programmers using that argument now against the Java camp...
Not important
>>2. "Benchmarks can be manipulated anyway you want"
Interpretation and design of statiscal analyses is inherently problematical. That doesn't mean one automatically falls foul of these problems.
>>3. "JIT compilers still build bytecode. How can it be as fast as C++?"
True. And you can tell them with equal veracity that their code is not as fast as assembler. Ask them if they think that's a good reason for them to rewrite their code.