Slashdot Mirror
Fast Native Eclipse with GTK+ Looks
Mark Wielaard writes "The gcj team created a natively compiled build of the Eclipse IDE. The resulting binary starts up faster then with any traditional JVM since there is no virtual machine to initialize or slow byte code interpreter or just in time compiler involved. This means that gcj got a lot better since the last Slashdot story in December about gcj and Eclipse. Red Hat provides RPMs for easy installation. Footnotes has screenshots by Havoc Pennington of the Eclipse IDE with GTK+ widgets."
GCJ aka "native Java" now really seems to be ready for its day under the spotlights.
The intriguing idea behind JIT compilers is that the result can be optimized for your exact configuration (AMD vs Intel, particular kinds of RAM, etc.) It can even (conceptually) optimize the same program differently at different times depending on usage. At, of course, a startup penalty and runtime compilation overhead.
I don't know how much of this potential is actually realized in JITs (it's insanely hard to do) and how much of a difference it makes in the end. How substantial would the difference between a specialized AMD vs Intel optimziation be, for example (which would presumably depend on the task)?
I suppose the best possible world would be to have the optimization run exactly once, the first time you install a program. (Yeah, you could conceptually move the same installation to a different CPU, or add more RAM, or some such, but let's not make an already messy issue even messier.)
I doubt such things are easy to benchmark, and the best test may well be something like this (gcj'd Eclipse), where the end result to the user is "which one feels faster?" and "which one actually runs faster?"
From your comments it's apparent you're not a Java programmer then, because you merely repeat old complaints that are no longer valid. Ok, sure, the JRE takes up a bit of space but compared to the size of hard drives today the amount is trivial. Having the JRE on disk is like installing the MS or Borland libraries (or Linux counterparts) that some applications use - once it's there other applications don't have to include the code as part of the executable.
Swing suffers from obesity - what does that mean?
I've been developing Java applications for years (including a stint as project lead on a weather satellite imagery analysis program) and I know firsthand how much Java has improved. Spend some time writing applications in Java, using Swing (I use Netbeans for my IDE)...you'll see how sporty applications can be. Also check out Sun's Java Games community for some links to games that really exhibit excellent performance.
But seriously, would it kill the poster to include the tiny little fact that gcj stands for "Gnu Compiler for Java?"
Probably not. Nor would it have kill him to explain that a compiler turns source code into a binary executable for a particular architecture, or that IDE stands for Integrated Development Environment, or that a JVM is a Java Virtual Machine, or that RPM stands for Redhat Package Manager, or that GTK+ stands for GIMP ToolKit, or that now it is now used for far more than just GIMP, or that GIMP stands for GNU Image Manipulation Program, or that the included acronym stands for Gnu's Not Unix, or that GNU is a project to write free implementations of operating system components derived around the POSIX model, or that POSIX is a collection of operating system standards based around tradional Unix interfaces.
Doing all of these at once, however, would probably piss everyone off. Explaining just the particular missing piece of information that a specific reader is going to need would be better, but would require Slashdot readers to be more homogenous and Slashdot posters to be more psychic than they are.
The compromise, wherein the word "gcj" is linked to a web page entitled "The GNU compiler for Java", seems to be hard to improve upon.
There's an interesting claim I have seen made: Apparently the late binding feature of object-oriented languages -- virtual methods in C++, any non-static method in Java -- works against branch prediction, effectively resetting the prediction state whenever such a call is made, because the target jump address must be resolved -- read from a memory location -- only at the time of the jump. If this claim is accurate, this means typical OO code is inherently slower to execute than non-OO code on modern processors. Of course, the problem will equally apply to any language that supports function pointers, and in particular to C programs "emulating" OO with structs and function-pointer tables.
For those who start up their IDE in the morning and close it down in the evening (or at the end of the week, whatever), then long startup times are just a minor cost of doing business.
For someone like me, however, who is ambivalent about this IDE or that IDE, and whose fingers are too hard-wired for one particular editor to use the brain-damaged editors foisted by most IDEs, startup time IS a big issue. When you are going in and out of tools all day long, it becomes a major annoyance to have to wait for the darned thing to start up.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
I could show you plenty of examples of benchmarks that run significantly faster with GCJ than on the IBM JDK. Its true that there are still some occasions where GCJ will run slower - due to bottlenecks in the runtime or missed optimizations in the compiler. But if you have a simple application that runs significantly slower with GCJ, please write to java@gcc.gnu.org and tell us about it. We can't fix performance problems we don't know about.
Are you even aware of the number of web sites exist whose server code is completely written in Java? Most likely you visitied a couple before you came here today.
two responses to that.
I write 95% of my work in Java. It's just as performant as anything else doing the same job. Most of my stuff (web applications) typically service small requests - very much like ls, albeit in a different environment. But the trick is, you don't start a new JVM for each invocation; you have a JVM running all the time and service the requests you receive within it. In this sense, the webapp is analogous ot a shell.
I'm not saying Java doesn't have problems - it does have a significant problem which is Sun's attitude to 'intellectual property' and their continued restrictive licensing. But speed and efficiency are no longer problems Java has.
I'm old enough to remember when discussions on Slashdot were well informed.