On 19/09/2013 19:44, Paulo Pinto wrote:
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
Even without seeing that article, I can well believe it. It seems they
shun away completely from compile-time optimizations, and not much
reasoning is given to that. It seems almost a purely political/marketing
move: like if they want to push the mantra that JITing is the be all and
end all of compiler optimization, and doing any kind of compile-time
optimization would be admitting that compile-time is also important (and
somehow making Java more prone to direct performance comparisons to
other languages/platforms?)
--
Bruno Medeiros - Software Engineer