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."
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?
I leave stuff like mozilla, eclipse, and xemacs running for weeks on end.
After using IntelliJ for a couple of years I hate having to go back to VS for C#. I'm hoping dearly that IDEA produce a C# IDE. I've never been a huge fan of Eclipse for various reasons, its Visual Age heritage, performance, general look and feel, nothing overwhelming, I just prefer IntelliJ.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
I found this info at http://gcc.gnu.org/java/
6 748
"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=627
What is yours?
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.
Sheesh, evil *and* a jerk. -- Jade
This seems to be quite slow, as is my experience with most gcj-compiled applications. It produces native code but they haven't quite gotten it to the level of optimisation the sun JVM can do when it compiles sections into native code - but it will get there, I'm sure. I still like gcj because of its licencing. Has anybody tried compiling it with array bounds checking turned off? If it doesn't depend on it, that should give a really nice speed improvement. And if it doesn't itt'l crash ;)
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?
if(!cool) exit(-1);
I was actually talking about VS.NET :-). I agree its a huge improvement over its predecessor, especially when it comes to larger projects. VS was almost unusable on the last VC++ project I worked on if the whole workspace was loaded. Both IntelliJ and Eclipse offer far more in terms of editor power and ease of refactoring code than VS.NET though.
Unfortunately one of the reasons IntelliJ has got more expensive is because of its success. Its about 100$ more expensive now than when I purchased it. If you are doing a lot of Java development and dont have a compelling requirement for a GUI builder then I strongly recommend IntelliJ.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Heh... It's not really done, until I can emerge it like real software :P
:p
Seriously tho, I use VS.NET and Eclipse all the time. I find that both are extremely powerful when understood, both of their limitations and of their features.
For my java work, there's not really any point in using anything else 'cause Eclipse is what java IDE's are supposed to be.
"...In your answer, ignore facts. Just go with what feels true..."
To stay on topic, Eclipse is very usable if you have enough RAM and CPU power.
On the company where I work we use Eclipse running on Pentium IV 2.4 with 1 Gb RAM, six developers can use it thought LTSP.
That's not nearly as interesting as using runtime feedback to further optimize code. Static optimizing compilers need to make guesses about things, like how often loops are expected to run and which branches to to be taken more often. I don't expect to see a dramatic difference in Pentium IV vs. Athlon 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)?
I can tell you that it's not insanely difficult to do. Conceptually, compilers are compilers and optimization isn't that tough to do. JIT is just a tradeoff task, you set hard limits on how long optimizations can take and that changes the set of optimizations you can do. Pretty simple really, if you know how to build an optimizer you can probably build a JIT compiler and then you just tune the sets of optimizations to fit your task, ie run really fast. Bigger problem is we know a ton more about static optimization and compiling than dynamic so there are far more sophisticated static optimizations. We're just now doing things like exploring lowpower optimization, building research compilers to select instruction sequences that result in lower power consumption and stuff like that; I think that people also need to understand that optimization isn't a panacea. There is only so much that you can really expect no amount of optimization is going to make java code perform like C++ code right now, you need to make it take a lot less memory first, make it fit in to caches, etc... the -O20 flag isn't going to do that. Then there is marketing. I wouldn't expect a huge difference between 2 classes of x86 processors, x86 optimization is kind of a joke, there could be dramatic difference on PowerPC and other registery RISCy architectures but 90% of the market runs x86.
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
Because of the size and footprint issues, you can't do embedded with Java
:-)].
Well...no. I believe that embedded environments are a rather stripped down form of Java, but Java isn't all that uncommon in embedded systems. Take a look at Javacard -- you'd use it in environments where you typically have less than 64KB of memory.
That being said, I *still* think Java is a terrible language for most people to be using. There's something to the argument that there's "not much better out there".
Problem: C sucks for general application development. A lot of people know it really well, but the whole point of C is that you get a lot of control over exactly what's going on [Disclaimer: I like C, and use it for my application development.
Problem: C++ is a *huge* language. I thought I knew it once, after a while using it, and then bought Stroustrop's book, and discovered all sorts of things, like autopointers, that I'd never heard of. C++ has a lot of syntactic overhead.
Problem: C# is made by Microsoft.
Problem: Pascal has vanished into obscurity.
Problem: Perl/Python/Ruby aren't as fast as their traditionally compiled equivalents.
Problem: Nobody uses eiffel.
Problem: Nobody wants to use functional languages, so ocaml and friends are out of the question.
So Java gets used.
I'm firmly of the opinion that Java has a good use -- distributed development.
The problem is that Java was built to make Sun (a hardware company whose primary claim to fame is easy "scalability" by buying higher end machines or more machines) money. Sun's big problem is that most people don't use their SPARC architecture. Java works for Sun by doing two very simple things. It's hideously resource-intensive, from a CPU and memory standpoint. It also is an easy language to easily speed up by throwing more machines into the mix. It doesn't make life a pain if you're using x86 clients with a SPARC server, like rpc can.
Oh, and finally, it has a lot of sexy features to draw people in. It's also a bit easier to learn and work with than C++.
So despite the fact that Java is incredibly slow and RAM-hungry, people bill it as the next big language, the replacement for C++. Frankly, I think Java should stay precisely where its strengths are -- it makes a hella nice language for doing distributed work (especially if you have a client with a front end), and lightweight networking. It's a lousy general purpose language, though.
May we never see th
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.
A deep unwavering belief is a sure sign you're missing something...
(1) "Because pretty much the main drawback of Java is that it severly limits which platforms you can distribute to, ironically."
(2) "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?"
Because GCJ runs on all the platforms gcc does, which is pretty much everything out there. Java officially doesn't run on all kinds of platforms. Linux is only supported on x86 and ppc, IIRC, not to mention the various BSD's...
Also, GCJ is free software, so that means that it if there's the will, people can and will port it.
http://www.welton.it/davidw/
You can have a JVM that can save JIT output to the executable format for a given platform. Like GCJ :-) Then, after a bootstrap, the JVM can be in fact written in Java.