Am 19.09.2013 19:44, schrieb Bruno Medeiros:
On 19/09/2013 11:06, deadalnix wrote:
*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.
Yeah, tell me about it. :/
When I was writing the new parser for DDT I explored and tested a few
optimizations that the JVM does to ellide object allocations
(essentially escape analysis to see when an object can be treated as
value object, and deallocated automatically at the end of some scope).
I wanted to use a certain pervasive code idiom in the parser that would
make the code more elegant, but less performant if this optimization was
not made.
( http://www.meetup.com/Londonjavacommunity/messages/52187462/ )
Fortunately the JVM is its later incarnations is quite smart in its
escape analysis, but unfortunately this is all done at runtime, whereas
a lot of it could be performed compile-time. :( But it seems the Java
folks (at least for OpenJDK) have a big aversion to performing any kind
of compile-time optimizations, even though a lot could be done here.
I once read in a blog, an entry from an ex-JVM engineer from Sun,
describing that anything that disputed Hotspot JIT capabilities was tabu
and ideas about native compilation were frowned upon.
Sadly I don't remember any longer where I read it.
--
Paulo
