Matthew Rosewarne on 21 Nov 2007 19:06:06 -0000


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Android Forums


On Wednesday 21 November 2007, Toby DiPasquale wrote:
> On Tue, Nov 20, 2007 at 11:13:22PM -0500, Matthew Rosewarne wrote:
> > On Tuesday 20 November 2007, Josh Goldstein wrote:
> > > I agree it isn't, but I wasn't talking about bytecode.
> > > Java has had a JIT compiler for years now, that generates machine code.
> > > Check out these results:
> > > http://shootout.alioth.debian.org/gp4/benchmark.php?test=all???=all
> > > Unless I'm misreading that chart, Java looks like it's doing better
> > > than a _lot_ of other languages.
> >
> > Clearly, there needs to be machine code at some point.  JIT is just the
> > technique the Java VM uses to transform its bytecode into executable
> > machine code.  There aren't really any other good ways to do what Java
> > does, but compiling bytecode at runtime carries with it a considerable
> > overhead.  The code the JIT compiler generates may be as good as an
> > equivalent C compiler, but that generation still needs to happen, so more
> > resources will be used overall.
>
> Which, of course, completely ignores the benefits that a JIT bytecode VM
> can acheive that compiled C++ cannot easily replicate, e.g. dynamic
> optimization, reflective dispatching, etc. Not to mention the portability
> aspect of bytecode and a bytecode VM. Its far easier to port a bytecode VM
> to a new platform once than to port every program written with Qt; witness
> how many Java programs I can run on my Mac (all of them) versus how many
> Qt programs I can run (???, but certainly not anywhere near all of them).

Actually, to port a C++ (Qt in particular) program to a new platform, the same 
amount of work has to be done as a Java program, except for the added 
recompilation.  Any app that uses Java ONLY will run just as well on a Mac as 
on any other Java-capable machine.  Likewise, any app that uses Qt ONLY will 
also run just as well.  The problems come not from the fact that there's a VM 
vs. machine code, but that people use platform-specific code alongside 
Java/Qt/etc.  Just like there are plenty of Java-based apps that only run on 
Windows, there are Qt-based apps that only run on Linux, simply because the 
coder assumed that COM+ or /bin/sh was always available.  Java also doesn't 
solve the problem of running your program on a new platform if that platform 
doesn't already have a port of Java, and porting the Java runtime to a new 
platform as at least as much (if not more) effort than porting a framework 
such as Qt.

>  The tradeoff is very often worth the slightly additional overhead, and
> lets be clear: it is *slight* these days. C++ is no longer that much faster
> than Java, if at all, depending on what you're doing. Given the fact that
> the Java language is a far better language than C++, built-in GC, a
> fantastic bytecode VM with an orders-of-magnitude higher level of
> portability right out of the box, you'd have to be a fool to choose C++
> over Java at this point unless it was strictly warranted (speaking purely
> on a C++ vs. Java basis, I'm not a tremendous fan of Java in the absolute).

Java has advanced considerably since its early days.  The code that that VM 
generates is at least as good as that of GCC.  The overhead comes not from 
running that compiled code, but from the fact that it has to be compiled at 
runtime.  It's easy to make a benchmark that shows Java to be as fast as C, 
so long as you ignore the additional resources it takes to JIT compile.  It's 
easy to demonstrate simply by comparing the difference in resource use 
between a Java program compiled to machine code with GCJ and the same Java 
program JIT compiled with GIJ.  The two methods use the same compiler, but 
since the former is pre-compiled, the real-world resource & speed benefits 
are significant.

Attachment: signature.asc
Description: This is a digitally signed message part.

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug