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."

Comments

Startup sure, but how fast does it run?

[iamacat]

From what I heard so far, gcj has problems with garbage collection and doesn't generate very good code. Did I miss any dramatic improvements recently? Also, how complete is the class library?

Re:Startup sure, but how fast does it run?

[Call Me Black Cloud]

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.

Re:Startup sure, but how fast does it run?

[red_gnom]

Of course, I don't see myself as a "Java programmer" or a "carpenter" or a "brick layer". I wouldn't take any pride in that. I have a degree in computer science...

...Because of the size and footprint issues, you can't do embedded with Java.

To further extend your knowledge in computer science, look into the Internet tool called "Google". Using it can save you from ridiculing yourself by publicly posting uneducated statements:

Embedded Java

Re:Startup sure, but how fast does it run?

[iapetus]

I have a degree in computer science. The day you will get a college degree, or at least some formal qualification, you won't need to go around saying: I am a "Java programmer".

What utter garbage. I'd describe myself primarily as a Java programmer, and I've got a college degree, a masters degree and a bucketful of professional qualifications.

Who are you that you can say what can be important in someone else situation?

I don't know. Who are you that you can say the same? There are plenty of cases where Java can be used in shell scripts, or where the same functionality can be achieved using a tool such as Ant (which is very widely used these days). Startup time isn't always the be all and end all of what people need from their programs. If it is, then obviously there are better tools than Java. I'd have hoped that at some point they'd have taught you in your college degree that there are plenty of tools out there and that there's such a thing as picking the right tool for a given job. That tool may be Java, it may be perl, it may be lovingly hand-crafted assembly code.

The fact that you seem to ignore that means that you also ignore the things that you can do with the JDK that you can't do with gcj, and ignore the requirements people may have that your preferred way of working doesn't address. And also, it seems, the fact that some people don't agree with your blanket generalisations.

Re:Startup sure, but how fast does it run?

[Simon Brooke]

There are lots of things you can't do with Java. Little CLI apps like 'ls', 'cd', etc, would be painful to use if they were written in Java, because of the startup costs of the VM. It takes GCC 0.004 seconds (ie: within measurement error) to startup and give me the usage message. It takes javac 0.330 seconds to do the same.

two responses to that.

1. People have no problem with little perl scripts run from the command line, but perl has exactly the same startup overheads as Java.
2. Running commands under bash is running them in, effectively, a C language environment. The basic C language shared libraries are already loaded. If you had a Java shell already running in its own JVM it could invoke instances of Java classes at the same order of cost as a conventional shell starting an ELF executable.

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.

increases the credibility of GCJ

[millenium]

GCJ aka "native Java" now really seems to be ready for its day under the spotlights.

load times

[khuber]

I still don't understand why load times are such a big deal. Do people sit there and start and exit applications continuously?

I leave stuff like mozilla, eclipse, and xemacs running for weeks on end.

Re:load times

[aled]

Yes! I love so much all those modal splash windows, in fact I'm recompiling all my apps to exit inmediately after showing them...

Re:load times

[khuber]

Java was never designed to start up quickly, though they did a lot of work on startup in 1.4.x. Startup time is slow due primarily to what is executed, not the JVM speed.

I wrote a simple JVMPI method tracer. It's mind-blowing what all happens before your code is actually run. Here's a method trace I just ran with 1.4.2 for a simple program.

-Kevin

Modified GCJ Required (for now)

[SilentMajority]

I found this info at http://gcc.gnu.org/java/

"A team of hackers from Red Hat has released RPMS for a version of Eclipse, a free software IDE written in Java, that has been compiled with a modified gcj. You can find more information here. We'll be integrating the required gcj patches into cvs in the near future."

ps

Slashdot preview is buggy today...can't do HTML format preview and links one or more spaces get embedded in URLs (like the one below).

---
My most underrated Slashdot post is http://slashdot.org/comments.pl?sid=68610&cid=6276 748

What is yours?

Another FOSS IDE.

[Black Parrot]

There is another FOSS IDE called gps. They call the unsupported version the "academic edition", but you can download the source, and a peak at a few files shows that it's GPL'd. (Their economic model is to give it away for free and sell support for those who need it.)

It's a cross-platform IDE, with binaries available for Linux, Solaris, and various versions of Windows, and in principle you should be able to build it on any *n*x system where you can get GTK2 to run.

The bad news is that language support is still limited. It has full support for Ada and partial support for C and C++, which are lower priorities for the authors. It comes with instructions for setting up support for your language, but that looks like a non-trivial task.

I've just started playing with it so I can't give a good review, but so far it has been very helpful. The features listed at their Web site are:

• Language-sensitive editor
  
• Automatic generation of body files
  
• Source code reformatting
  
• Intelligent source code navigation
  
• Context-sensitive search and replace
  
• Application builder
  
• Automatic code fixing
  
• Version control (CVS, ClearCase, etc.)
  
• Visual file comparison
  
• Graphical source-level debugger
  
• Project and program entities explorer
  
• Project wizard
  
• Types and program entities graphs
  
• Call graphs
  
• File dependency graphs
  
• Project dependency graphs

You can use the built-in editor or make it pop up your favorite editor. If you use the gnuclient Emacs interface you get the same kind of language-sensitive pop-up menus you get with the built-in editor.

Screenshots are available at the link above.

Plugins?

[connsmythe96]

The eclipse IDE is supposed to be extremely pluggable. How does natively compiling it affect that? Do you have to compile the plugins with the IDE? Or can you still just drop the .class files somewhere?

Re:Plugins?

[Anonymous Coward]

I believe run-time loading works. GCJ also includes a bytecode interpreter, so it will use that (it'll be slower than a normal JVM, but if you know you'll be loading it, you can compile the plugin natively, I think).

That was the case last time I looked at GCJ about a year ago. I ended up being unable to use it because of lack of windowing toolkit support. Anyone know the status on all that?

Re:Plugins?

[Per Bothner]

That was the case last time I looked at GCJ about a year ago. I ended up being unable to use it because of lack of windowing toolkit support. Anyone know the status on all that?

Eclipse uses its own SWT toolkit, which works well under GCJ. SWT is a combination of native code and Java, and is said to both be fast and integrate well with other window systems, as it uses native widgets when available.

The implementation of AWT (including applets) is coming along very quickly, but it isn't complete yet.

Total GCJ performance

[jfengel]

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?"

Re:Total GCJ performance

[Anonymous Coward]

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.

Oh, but there are a few fallacies associated with that.

The first and bigggest one, a pet peeve of mine, is that people claim that they can reoptimize the application repeatedly on the fly to make it run faster (your It can even (conceptually) optimize the same program differently at different times depending on usage). yes, while this is theoretically possible, the end result will be slower than a normal compilation. Why? Because since you want to check that the usage hasn't changed, you basically have to be running a profiled version all the time. Yes light-weight profiling exists, but it'll be slower than a fairly generic optimized version with no profiling.

Second, You don't need JIT to optimize for your specific setup. Think Gentoo. You can use all of the GCC optimization flags with GCJ and optimize for whatever flavor of processor you have. Of course, that makes hardware upgrades a pain, as you have to recompile everything, but whatever.

Third, I doubt any JIT compilers nowadays do anything different for different processor families, simply to keep complexity down. Heck, I'd be surprised if they used any streaming instructions or anything like that.

Fourth, how much time are you willing to give the JIT compiler to do its thing? With a compile-once system, you can let the compiler crunch on your large a pplication for hours if you want, and then distribute the binary to your clients. That is just not feasible in a JIT context, so the optimizations that can be done are limited (unless you do it in parallel with the app, which introduces profiling (see 1), and adds complexity to the JIT compiler (see 3).

Fifth, the only two situations where you care about speed are
- Batch programs, where theprogram runs continuously and you want it to finish quickly, so you don't want to waste any time on profiling and/or reoptimizing anyway.
- GUI responsiveness, where optimization is not as important as the desing of the GUI toolkit (For some reason every java app I've ever touched seems more sluggish than a similar (or any) windows app).
The third place where speed is important is games, but we're talking java here :-)

Sixth, if you're interested in optimizing towards your personal usage style (which loops will be executed more often depends of which features you use, and how, etc) you still don't need JIT. Look up information on profiled-directed optimization. Basically you build a version of the app with -fprofiler-arcs and use it for a while (it'll be slow) then recompile by feeding those profiles to the compiler (I forget the flag) and voila. The compiler knows the real probabilities of each branch being taken and can optimize accordingly. This works on gcc and g++, but I'm not sure whether gcj can do it yet (last time I tried using -fprofile-arcs with gcj it crashed because internally the profiling code in the back end tried to add a function with a variable parameter list (...), which java doesn't have, so the front end crashed).

There are more objections I had to the whole "JIT is the best ever" mentality, but this rant has grown too long, and I forgot the rest already.

(oh, yeah. Seventh, every program has bugs, and some only show up under certain very specific circumstances (using system.identityHashCode() will make the program depend on the memory layout to the point that some bugs will appear only some times. also race conditions and resource leaks). If you have a different version of your executables, you will hve bugs appearing only under certain configurations of processor, memory, etc. and dissapear suddently as the program reoptimizes, which makes it hell to track down or even come up w

Re:Troll...Troll...Troll...

[gumpish]

And [Java] continues to be hyped, and is being used less and less, as the speed continues to hamper it.

Java is still some 40 times faster than Python. As hardware speed continues to obey Moore's law, performance per clock cycle becomes less important. (For many areas of computing anyway.)

obligatory pun

[1nv4d3r]

Thanks to the expected slashdotting, this is just one more eclipse I can't look directly at.

Re:Annoyed with the post

[roystgnr]

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.

Branch prediction and OO languages

[Earlybird]

• On modern processors, the performance of a program is affected greatly by the success of the branch-prediction system, which gets hints from the compiler.

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.

Re:Microsoft's IDEs? You have GOT to be kidding

[WhoDaresWins]

Using Microsoft's IDEs - I have VC++ both 6 and 7 - is like pounding nails with my fists. Have you used Metrowerks Codewarrior? Now there's an IDE. It's a joy to use.

While IDEs can be quite a personal preference thing, you don't quite mention anything specifically about what is so good about the Metrowerks IDE other than it being cross platform and easy to author web pages in(!). I mean come on neither of those are core IDE functionality. I would have given you more credit if you had any pointed things to say about how the Metrowerks IDE is better but as it stands now you aren't very convincing.

If you prefer makefiles, there are command line tools that provide the same compiler.

Huh? This is not a big deal. Almost every compiler in the world can do this including VC++.

Visual C++ can't compile it because of its poor compliance to the standard.

Its quite obvious that you haven't tried VC++ 7.1 (Visual Studio.Net 2003). Its has close to 95% plus ISO C++ compliance. The only major feature missing is "export" which has now been almost officially labelled as a misfeature by the C++ gurus on the standards comittee and no major compiler will implement it. You mentioned having VC++ 6 and 7 and yet you being totally unaware of the fact the most VC++ programmers were long aware that VC++ 7.1 would have close to full compliance, leads me to think that you aren't much a VC++ user and perhaps only use it because you have to.

Why JVM?

[be-fan]

I never really understood the whole point of the JVM. Why load this big program at every application launch? JIT still has more overhead than AOT compilation, in the real world, and most importantly, the huge memory footprint of the VM wreaks havoc on your caches.

What's the purpose of the JVM?

Dynamicity? No. Java is a aggressively static language. Meanwhile, highly dynamic languages like Lisp, Dylan, and Scheme (among others) can be efficiently compiled to native code.

Speed? While in theory a JIT can be faster, its not the case in practice. In the "Great Computer Language Shootout" (which isn't bad, as far as these things go) Java has an average CPU rank of 14, behind other static languages like C, C++, Ocaml, and SML, and behind dynamic languages like Scheme and CL as well! In reality, Java can only get within 90% of the speed of C for inner-loop numeric-type stuff (which lends itself to JIT optimization).

Flexibility? Java is highly inflexible. Its almost as as inflexible as C. It requires you to manually specify pretty much everything. You even have to do manual boxing/unboxing! Java is so highly structured, it should be compilable to native code that hits 90% the speed of C, without a very smart optimizer at all.

Safety? Given Java's lack of pointer types, it shouldn't need a JVM monitoring it to be safe. Again, there are lots of safe languages (Haskell, Clean, and the aforementioned dynamic languages) that don't require a runtime monitor.

Actually, I don't see much of a point in Java at all. Its got statically typed, but can't use that advantage to be as fast as C++. It runs in a VM, but can't use that advantage to be as dynamic as Python. Its syntax isn't any easier to use than something like Dylan (kinda like Lisp with a Pascal syntax) or Python. It doesn't have the development environment advantages of Smalltalk. Heck, its not even a very good compromise language ---- Dylan is as easy, often faster, and more powerful, Python is much easier (and thanks to Psyco) often as fast, C++ is much more powerful, as well as much faster, etc.

Re:Why JVM?

[the eric conspiracy]

Dynamicity? No. Java is a aggressively static language.

Static types perhaps, but very dynamic when it comes to linking. Java has a lot of support for things like dynamic class loaders that lead to a very nice plug-in architecture, and extreme flexibility when it comes to deployment of code updates to a running application. Not to mention fun with diddling bytecodes on the fly.

Please Read Parent!!!

[0x0d0a]

It is extremely important that *all* developers read the parent post. This IDE may have the most groundshaking features *ever*!

Let's take a look:

Automatic generation of body files

Hot *damn*! It writes my code for me!

Source code reformatting

Then it reformats it to fit whatever standard I need!

Automatic code fixing

Then it *debugs* the code!

Application builder

Finally, it *builds* the program I'm working on!

All this, from a piece of software that the ignorant layman might consider no more than a wrapper for an editor and a compiler.

Truly, a groundbreaking achievement. :-)

load times *do* matter in the real world (tm)

[mccrew]

Do people sit there and start and exit applications continuously?

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.

Re:load times *do* matter in the real world (tm)

[ChannelX]

I still dont get why you need to restart Eclipse to go into another editor. Run them both at the same time. IIRC the Eclipse editor will detect the new file changes.

GCJ performance is a myth. Benchmarks inside.

[lokedhs]

In general, GCJ compiled code is slower than the smae code running in the JVM. The only speed advantage comes from the startup times.

Often the JVM will out-perform GCJ with a factor of 3. Check out the numbers on this page.

I fail to see why people want to run a GCJ compiled evrsion of a development tool and run at at one third of the speed of the JVM, just in order to save a few seconds of startup time.

Re:GCJ performance is a myth. Benchmarks inside.

[Tom7]

I checked out the numbers, but GCJ seems to be just barely edged out by Hotspot in most cases. Considering that GCJ is free and allows you to distribute native binaries, that's pretty good.

They don't have figures for memory usage, installation profile, etc., and I bet in those areas GCJ beats Hotspot for end-users. And you can't beat an install with no library dependencies.

Re:GCJ performance is a myth. Benchmarks inside.

[lokedhs]

Because pretty much the main drawback of Java is that it severly limits which platforms you can distribute to, ironically.

Let's assume for a second that you are correct, and Java limits the platforms you can distribute to. Tell me again exactly how GCJ improves on that?

The only other option is distributing a 50 meg JVM with every app

The JRE is 13 MB last I looked. And you only have to download it once and it works for all your Java apps. Most Java applications are offered in a package both with and without a JRE. For example DbVisualizer (I wholeheartly recommend this database tool, very good and supports pretty much all databases) and IntelliJ IDEA (the best development environment ever).

and increasing support costs by having to walk people through tedious installation procedures, for the JVM and your app.

The apps I showed as examples are one-click installable. Most others are too. Your statement was completely wrong and should have had a huge FUD warning sign all over it.

If you can compile a native binary, you can distribute it to any binary compatible platform, regardless of what other software they have installed.

GCJ requires the GCJ runtime libs last I messed with it. Exactly how is this different from installing JRE?

You don't have to explain CLASSPATH to your users.

Read the documentation on the Java site. Use of the CLASSPATH environment variable has been stringly discouraged ever since the 1.2 days. I hardly ever use it myself, although it's nice to have if I need it (mainly when developing and trying out different libraries).

You don't have to explain why they can't type "java filename.class", but instead must type "java filename".

I have a better solution: Just double-click on the app! Yes, can you believe it? Ever since 1.2 there has been support for executable JAR's. When you install Windows .jar files are automatically associated with the Java runtime so that you can double-clik on the app to start it. If you have the stupid "hide extensions" feature enabled it looks just a normal app. I believe MacOSX does the same (although I haven't tried). Enabling the same in Nautilus is just a couple of mouse clicks away. From the command like you do have to type "java -jar the_application.jar".

GCJ is the only hope Java has of actually being more than an acedemic curiosity, and "something that Sun used for a few apps".

Maybe you should leave the academic environment for a while and realise that Java is heavily used for developing very real and existing applications in Java. Also check out the statistic on programming language usage with PostgreSQL. I'm not so sure I should believe your asstertion that Java isn't used oustide of academic institutions.

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.

Re:Memory Usage vs Eclipse Running in JVM

[thimo]

A quick test (using an Eclipse 2.1.1 from eclipse.org):

Eclipse 2.1.1 with JVM
- Second start: 13 seconds
- Memory Eclipse: 80 MB
- Memory JVM: 65 MB

Eclipse 2.0.1 without JVM
- Second start: 9 seconds
- Memory: 96 MB

The download page seems to indicate you're downloading an Eclipse 2.1.0 version, but the about dialog says 2.0.1. Which one is it?

Cheers,

Thimo (back to coding in Eclipse 2.1.1 :)

Re:GCJ slower than IBM JDK

[__Reason__]

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.

Fast. Was:Startup sure, but how fast does it run?

[atgreen]

Eclipse contains a java compiler which you can also compile as a standalone app with with gcj (see http://sources.redhat.com/rhug). The gcj-compiled compiler is almost three times faster than the latest IBM JRE run version.