| Matthew Rosewarne on 21 Nov 2007 19:06:06 -0000 |
|
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 ___________________________________________________________________________ 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
|
|