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.
I think you miss the point; Java is not designed for the sort of speed and efficiency necessary for, say, startup scripts. So, in the context of Java's purpose, those features are not really important. Java is designed for portability and the ease-of-use (from a programmer's standpoint) that comes with the very large amount of memory management that the virtual machine takes care of. Does this result in a larger footprint, and slower operating times? Undoubtedly. But if those things are mission critical, do not program in Java.
No, of course you can't "do embedded" with Java. That's why there's a multitude of phones out there, and some handheld devices that are already using it. Because you know, it can't be done.
You're a fucking moron. That is all.
> 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.
True, the optimization for hardware platforms are less significant than the overall optimizations.
> 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)?
Its huge, Java is already faster than C++ is some benchmarks (very slightly) but the problem is that this feature doesn't benchmark well.
Technically optimizing JIT's aren't all that hard to write since this subject is far from new and has been studied in smalltalk for ages (IBM was strong in smalltalk and Sun just hired everyone else).
As an example these two opimizations are a part of both the Sun and IBM JDKs:
1. Virtual method inlining - where a call to a virtual method can be made inline since at runtime we know for sure the instance we perform invocations upon.
2. Runtime loop unroling - loop unroling is mostly useless in C++ since you need to know the size of the iteration in advance. Even if it never changes.
In Java there are many language restrictions (no pointer arithmetics, bound arrays etc...) that allow the JIT to assume things that a C++ compiler can't assume. Java has in that sense the potential to be much faster then Fortran and simpler than C/C++.
> 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.)
This level of opimization produces some but relatively little benefit. You can do this with open source applications written in C, the advantage in JIT is allowing the application to be profiled according to your specific use case and adapted to it. After all we only use 10% of a programs functionality. When a programmer profiles a C/C++ application he only profiles the way he used it not the way his user will.
Development time.
OK, this is just a minor vent here. Feel free to ignore it if you want.
/.. I'm not a developer, so deep coding articles whiz past me. I don't have a problem with that--articles on biotech and/or legal intricacies most certainly go past other people who don't have the background in those fields.
/..
I didn't understand a single bit of what the original post was saying. Why? Because there was no context!
Now because of it's nature, I don't expect to deeply comprehend every article on
But seriously, would it kill the poster to include the tiny little fact that gcj stands for "Gnu Compiler for Java?" Those words would have established a context for the article, and given TONS of information about what the remaining stuff was all about.
As I said, a minor rant--but a really common problem on
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Why is it that people like to abuse Moore's law as a lame excuse for lousy engineering?
Eclipse may be open source, but it was (and is) developed primarily by IBM software developers as a foundation for the IBM Websphere Studio suite of products. VS.NET is fine, if you are a new programmer who hasn't had a lot of time to experiment with more advanced systems, but the Websphere Studio suite (which, although based on Eclipse are closed source) leaves it in the dust.
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.
Interestingly, Python is a much higher level (as a language, not necessarily libraries) language than Java, yet the Python VM takes no time at all to start up.
A deep unwavering belief is a sure sign you're missing something...
Just getting a program to run under Eclipse is a major undertaking. Visual Studio has a "project file" that identifies the void main() (or Java or C# equivalent) for you, so if somebody gives you a VS project as a bundle, you simply load the project file and build and run. I think there is something going on with Eclipse that not only to you have to put files into the project manager, you have to identify the source module containing the program entry point for Run to be able to do something, and it is confusing because Run has a lot of options that a person keeps trying out, but the problem was back in the project manager.
I am sure that once you get the hang of how to use Eclipse it is the Swiss Army Knife of software development, but Eclipse is different, and the state of the examples, docs, and help files is such that it is going to turn away of people who try it out for a casual inspection. So be it. If Eclipse gains mindshare, those of us on the fringes will buckle down and try to learn it, and if Eclipse fades into the background, we will kind of know why it had failed.
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.
Meaningless nitpick: cd is internalized within the shell. It is impossible to write a "cd" program external from the shell with the Unix model of per-process working directories.
This gets me thinking: what about a shell written in Java? In such a case, if a Java app is run, the JVM is already loaded.
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.
Not necessarily; reflection could do this with any old Object. Admittedly, the interface solution is normally neater, but it's also a better solution for maintenance purposes - too much dynamism makes code easier to write, but can make it much harder to maintain and introduce subtle bugs unless you're very disciplined (and, more importantly, so are every one of your predecessors and colleagues...)
Ceterum censeo subscriptionem esse delendam.
Of course it's not The Ultimate Computer Language, but it's good enough for a lot of applications. OCaml, SML, Haskell, Clean, Dylan, and Scheme are largely academic/research languages with little real world use because their programming models are too hard to deal with, among other reasons.
Smalltalk is one of my favorite languages, and I admire its offshoot Self, but it was in the wrong place at the wrong time, was too expensive, and has problems with nonstandard libraries. Python is nice, but slow, and has an uneven library. C++ is a syntax nightmare. I don't know what to think about Dylan, I still think of it in its prefix form.
I'm sure you understand that programming languages don't gain widespread use due to their theoretical elegance, or Cobol must be brilliant and ML must lack expressive power. I often call Java the Cobol of the 21st century, because I think that is a good analogy for its place in software development.
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.