Hi,
With Java 1.6 out can we say that performance of Java 1.6 is almost equivalent to C++ code or still there is lot to improve on performance front in Java compared to C++ ?
Thanks.
+8
A:
Debian likes to conduct benchmarks on this sort of thing. In their case, it appears that Java is about half as fast and consumes 2-18 times as much memory as C++.
Crashworks
2009-10-05 01:15:16
Which should be taken with a grain of salt. Firstly, you can write the program as you like. I know haskell does well, but the code is not idiomatic, so the cheap tricks you'd never use come out. Secondly, it only uses tiny programs. Few interesting Java and C++ programs are less than 10000 lines of code. Many are greater than 1 million LOC.
Paul Biggar
2009-10-05 01:51:38
This is a good point, but I should also provide the counter that if the 95/5 rule is true ("95% of time is spent in 5% of code"), then it is that 5% that should be benchmarked. And in any event, even a million-line program is comprised of numerous individual 100-line functions.
Crashworks
2009-10-05 05:57:19
@Crashworks that only really applies to optimising a given program in a given environment - if you are comparing a garbage collected environment to one that, say, uses automatic pointers made thread safe using fine-grained bus locking, or immutable vs mutable string handling, you get whole program effects as well as specific bottlenecks.
Pete Kirkham
2009-10-05 09:52:57
"Debian" are kind enough to host the benchmarks game among many other open source projects - "Debian" don't do the benchmarks game.
igouy
2009-10-06 16:55:45
igouy
2009-10-06 16:57:44
igouy
2009-10-06 17:19:22
The Debian Shootout are a small set of toy benchmarks. Biggest is what, 300 lines?
Paul Biggar
2009-10-05 01:49:12
+1
A:
I would expect that most of the time for most applications C++ will be faster than Java.
In some cases there will be some C++ which is slower than Java for a given task. This is pretty rare and always a result for poor implemntation or more commenly poor refactoring of an application.
In the majority of cases the performance difference more than offset by the fexibility, ease of use, availability of libraries, and, portability that Java provides.
In a very few cases performance is so critical that developing in Java would be a poor choice <opinion><flame off>in these cases plain C is usually a better choice than C++ </flame></opinion>.
Currently the sweetspot in performance/ease of use/ease of development tradeoffs is C#. Portability is a big issues here though.
James Anderson
2009-10-05 01:45:40
+1
A:
I find that Java performs very well.
However, why has no one ever fixed my biggest complaint?
Java uses FIVE TIMES as much memory as a C++ program doing the same job. At least!
And once it's used, Java keeps it!
Please, please, why won't anyone write a garbage collector for Java that uses minimum amounts of RAM? It could compact the heap and returns the memory to the OS. Instead of ridiculous piles of -Xm* options, use the memory needed and then give it back!
Actually I am sure some of the embedded system JVMs do this, but none of the desktop or server systems do.
This memory piggishness makes Java applications all want to act as if they own the entire computer system, that no one ever wants to run more than one application and that RAM is free and infinitely upgradable.
Therefore, no matter how great the performance, I would never write anything like a utility program in Java. Only gigantic server apps need apply.
Zan Lynx
2009-10-05 04:56:25
Which JVM's have you looked at? The AS/400 JVM does that. (and the Microsoft one, from long ago).
Thorbjørn Ravn Andersen
2009-10-05 05:25:05
I don't think this is entirely true. I wrote a small test program to check this and ran it using Sun's JVM on Windows. The test program allocated a huge list and then nulls it. After A couple of calls to System#gc, the working set was reduced, but there seems to be a timing factor involved; the memory is not reduced immediately. JVisualVM displayed a reduction in heap size, and the windows Task Manager showed a reduction in physical memory usage.
JesperE
2009-10-05 07:13:01
It doesn't matter anyway. A process doesn't need to deallocate pageable RAM; modern harddisks are big enough (for all practical purposes free and infinite). And JVMs rarely use non-pageable memory.
MSalters
2009-10-05 08:30:18
On any modern operating system, giving back memory to the operating system would achieve little. If java isn't actively using that memory then it will soon enough be paged out if the system needs more. returning that memory to the operating system merely gives the system work to do for little benefit.
John Burton
2009-10-05 10:37:01
Its also worth noting that, while it may not always be true, a common thought is that "if a program uses X memory once, it will probably use X memory again". As such, the cost of releasing the memory to the OS probably isn't worth it.
RHSeeger
2009-10-05 18:07:39
A:
Performance is usually "good enough" for most purposes. The question is what you want to compare exactly, and if you have applied a profiler to find and fix the hotspots in your code.
JVM's based on Sun's code still pay a hefty startup-tax (I still wonder why they cannot snapshot that and restart from there) but Suns approach has been correctness first, speed second, and it's taken them 10 years to get up to par.
So the answer is "It depends" :)
Thorbjørn Ravn Andersen
2009-10-05 05:29:02
+8
A:
A well-written Java program is never going to be as fast as a well-written C or C++ program. The virtual machine is an irreducible overhead. However, most code is not well written.
Java is a simpler language than C++, and offers a more forgiving environment for inexperienced programmers - so if your programmers are inexperienced (and cheap), then Java will probably perform 'better' than C++.
shared_ptrs offer a similarly forgiving environment in C++, so they are very tempting for inexperienced programmers, or those migrating from Java, But their performance overhead is as bad or worse than Java's garbage collection. I've seen large C++ programs where every variable is a shared_ptr, and they perform terribly.
My opinion
Personally, I think that large projects need to choose an 'easy' programming language for the bulk of their code, and a 'fast' one for sections that need optimising. Java may be a good choice for the 'easy' language, especially since there is currently a plentiful supply of Java programmers - in the future, I think even easier languages such as Python will begin to take over.
C++ is a reasonable choice for a 'fast' language if you already know it, but I think it's over-complexity will eventually see it fall by the wayside, while C will continue to fulfill this role.
alex tingle
2009-10-05 08:02:34
@alex a shared_ptr is a smart pointer, not a garbage collector. you will always know at compile time when a shared_ptr does its cleanup, but you don't necessarily know when a garbage collector breaks in to do its thing. When you write a flight-control system the last thing you want is that a garbage collector will burst in and start spinning aggressively while your plane is undertaking an emergency landing. The two don't work the same and don't perform the same
wilhelmtell
2009-10-05 18:05:58
The point is that 99% of applications out there aren't for flight-control systems, so the difference is moot. And yes, `shared_ptr` overhead, for a separately allocated reference counter, as well as thread-safe reference counting on every copy itself, often ends up being more expensive than a modern generational GC.
Pavel Minaev
2009-10-05 18:20:11
wilhelmtell: 1) I never said that a shared_ptr is a garbage collector. 2) I don't think anyone's going to write a flight control system in Java (or C++ for that matter).
alex tingle
2009-10-05 18:43:13
@alex, C++ is used in lots of mission critical systems, including embedded ones with hard real-time constraints.
Void
2009-10-05 19:42:07
C++ is a perfectly sensible choice for fault-tolerant, performance-critical realtime software. The "problem" of its being unforgiving towards inept programmers can be solved by making your Human Resources team equally unforgiving towards inept programmers.
Crashworks
2009-10-10 12:12:48
@alex: search for "Joint Strike Fighter C++ coding standards". I'm pretty sure military folks are __EXTREMELY__ careful w.r.t. such things
Alexander Malakhov
2010-09-02 06:52:14
A:
For most applications it is almost certainly possible to write a C++ program which performs considerably better than a program to achieve the same thing in java.
However if the program isn't optimised for speed then java will likely be just as fast or faster because the compiler / JIT is able to make optimisations that a C++ environment can't.
Basically if you are willing to spend considerable time understanding and coding for performance you can probably do a considerably better job in c++ eventually than you could in java but for the same amount of time and effort it is quite likely that java will "win".
As usual though, algorithmic improvements tend to make as much if not more difference than the language.
John Burton
2009-10-05 10:33:47
+1
A:
What program are you developing?
Comparing C++ to Java speed is like comparing a screwdriver and a hammer, pointless. In the world we live in, where both supercomputers and toasters need to be programmed, you need to focus on your particular requirements.
I use C++ for hard realtime software running on embedded systems. I wouldn't dream of using the awfully broken Java for realtime spec for at least another 5 years, when it will hopefully be mature. I would be equally loath to use C++ for a database, cloud accessing middleware app (actually I have no Idea what I just said, but I know Java is good for 'that sort of stuff')
Would you use a ferrari with no trunk space to move your belongings? Would you bring a minivan to a drag race?
People have to understand that just because they are programming languages, does not mean they are comparable in a meaningful way.
oldtimer
2009-10-06 03:52:38