Thomas said:
Very common mantra from nearly every java pundit except me. I very much
like java, and will likely be a proponent of it for a very long time, but in
real life, it is "slow" when compared to anything else native.
I agree with you. Now, I don't consider myself a Java "pundit", so I
don't know if that disproves your statement or not. I do use Java a
lot. Nevertheless, it makes sense from the standpoint of objective
decision-making to admit that Java is mostly slower than native code.
I don't think I'd go so far as you, though. I don't agree that:
the consensus is still that the JVM just cannot
come close to a "real" cpu.
Java certainly can come close to a real CPU. I find it to be comparable
in micro-benchmarking, and within 20% in real-world application testing,
of the performance of applications compiled straight to machine code.
Of course, these are generalizations, but they describe my experience,
and I think it meets the definition of "close" fairly well.
There seem to be four factors that account for the "slow" reputation, in
no particular order:
1. Poor programmers
2. Garbage collection
3. Memory/locality issues
4. Pure object model
Poor programmers is a somewhat standard excuse, but one that holds some
merit. Java is definitely more accessible to the novice programmer than
C and C++ were; and as a result, there are plenty of examples of poor
code in Java. In general, though, evidence of poor code takes the form
of bad design and abstraction, as even poor programmers can write
reasonably well-performing code in 90% of situations. In fact, many
poor programmers are obsessed with it!
Garbage collection, of course, can theoretically be made faster than
explicit memory management when given enough memory, as Andrew Appel is
famous for having argued. I believe it's important to realize that GC
opens up new ways of managing a heap that have their own unique
advantages performance-wise over an explicitly managed heap.
Nevertheless, in practice, garbage collection is generally slower except
in certain specialized algorithms that can exploit it efficiently.
Java's being fundamentally based on garbage collection has many benefits
for safety, ease-of-development, and security... but it objectively must
be admitted to be slower on average.
The most overlooked reason for Java's performance problems is the
difficulty of maintaining good cache and page locality. Because Java's
microbenchmark improvements have come at the cost of memory usage, Java
processes are often larger than native processes. They maintain two
copies of a lot of the code (native and bytecode), and they lack the use
of shared libraries so that memory becomes even more scarce when
multiple virtual machines are running. They also maintain a lot more
information at runtime than a typical C or C++ application, for the
purpose of providing powerful features like OO dynamic linking/loading
and reflection. The result is a higher likelihood of paging and of
cache misses, both of which slow things down. This is largely a direct
cost of the bytecode format. It also accounts for much of the curious
fact that simple benchmarks often show Java at comparable performance
with native code, but real-world (larger) applications fail to
demonstrate such similar performance.
The pure object model (by which I mean that all objects own their
identity and therefore do not have a lifetime tied to local scope) is
perhaps a bigger concern. It exacerbates both the garbage collection
impact (because garbage collection runs more often) and the locality
impact (because data is not stored as compactly or contiguously in
memory) as described above.
Now saying this often causes very emotional kneejerk reactions.
Yes, it does. Loyalty is a natural human emotion, whether it's
appropriate or not.
--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
but is harder work so ultimately makes you better.