On Thursday, 19 September 2013 at 08:26:03 UTC, Russel Winder
wrote:
And Windows native code applications don't ship with a version
of all
the Windows DLLs for every application?
Java is no longer under-performant compared to C, C++, Fortran,
D, Go,
Rust. Check the benchmarks.
Benchmarks in Java are often misleading. The language promote a
style with a lot of indirections, in the code and in datas. Once
your application reach a certain size, cache effect makes it
slowdown dramatically. But most benchmark applications aren't big
enough to exhibit that behavior.
That being said, if you code in D like in java, you'll have the
same trouble (in fact, it is likely to be worse in D). Compile
time polymorphism and value types are here a major benefit of
C/C++/C#/D (pick whatever you like).
Obviously, you'll find some pathologic cases where java is faster
(usually mono-threaded memory allocation intensive benchmark
exhibit that, as the JVM is able to add concurrency to the
equation via the GC). But that doesn't represent the typical way
most a program works (and when they do, you want to fix that as
this is a performance killer, in every language, even if java
suffers less from it).
The main problem of java isn't the VM, it is its addiction to
indirections.
*Java's sluggish performance was what made me look for
alternatives in the first place, and I found D.
I accept this as true as it is a statement by you about your
decision
making, but Java 8 is not Java 1. Early desktop Java was pure
interpretation, and hence slow. Modern Java, via the JIT,
generally
executes native code. With Java 7 and method handles and
invokedynamic,
the world changed even more and now computationally intensive
codes can
run basically as fast using Java as using C, C++, Fortran, D,
Rust, Go.
(After initial "warm up" of the JIT.)
Yes, the warm up is usually a severe drawback for user
applications. Server app do not suffer from it that much. I guess
that is why java is so much used server side, but not that much
to create GUI apps.
