Java Rocks On Linux
Begonia writes "While we're on the subject of Java, I'm really impressed with its performance on Linux these days. I'm using IBM's latest (1.3) version of the JDK,
which has only been out for a couple of months. And I just stumbled across this latest set of benchmarks for various JDK's on Linux and
Windows here. Not dated, but must be at most a couple of weeks old. Lots
of very interesting food for thought."
I suppose all this affect benchmarks too; most readers today will be more interested in testes that show server-like workloads.
I think if my testes showed server-like workloads they'd rupture.
I would be a paid subscriber if Taco and Hemos weren't such cunts
I'm glad to hear that we now have "Java Rocks". Not that I have the slightest clue how to implement an application or class library on this new development, but it just sounds cool.
:-) I have enough serious rambling yet to finish.
Isn't a cool name the core of any new technology product?
It brings up an image - I see it now! A penguin hurling Java Rocks at stained windows...
Enough pointless rambling
A dingo ate my sig...
Okay, repeat after me:
HARDWARE IS CHEAP. PEOPLE ARE NOT.
HARDWARE IS CHEAP. PEOPLE ARE NOT.
HARDWARE IS CHEAP. PEOPLE ARE NOT.
So, Java's a little slower on the runtime versus native code. Quantify that difference (call it X).
On the other hand, I've heard (and experienced) that writing with Java and its APIs is much faster and easier than learning and writing code to various OSes and their bare-metal system resources. Quantify THAT difference (call it Y).
So, what's the per-unit cost to compensate for X across multiple forms of hardware. What's the per-unit cost to compensate for Y across OSes, people, and systems.
I'd be willing to bet, were this all actually well formulated as an equation, that you'd find we really don't give a shit anymore about how blindingly fast a given programming language can be if you're hacking close to the hardware. Hardware is cheap, just throw another faster CPU at it. People, however, are much harder to upgrade.
hen a programmer just has to know one pretty simple language and API, rather than many OS quirks and tricks and system-resource details that distract from the main task at hand, programmer cost goes down. Make it easy for the people, and it becomes so much cheaper that we accept a margin of performance cost on our easily improved hardware.
Fact is, you can't say Java is fast or slow, it depends a lot on the context.
Uhh... Use the right tool for the right job. I'm not, of course, saying everything should be done in Java. I'm just saying that for many things, Java is great and it has it's place - as does many other languages and technologies.
I just read an article where Linus Torvalds says his siblings and grandparents use Windows cause it has better support for the apps they need. Fair enough. He doesn't jump out the window cause of it or start crying that Linux is the only way to go. The same attitude might be smart when dealing with languages and software platforms. A professional software engineer uses the best tools for the job.
Not only is this not representative of most real-world programming tasks (it checks the gc and allocation code more than anything), but he didn't perform simple optimizations that would have helped him big-time (like loop unrolling). He also apparently didn't read the gcj docs, which point out that gcj's bounds checking is much slower than it should be, so if you don't need it, you can turn it off. Since he does 1.5 million array accesses and does all the bounds checking himself with loop termination invariants, bounds checking is a fairly important -- and unnecessary -- constant multiplier, I'd say. :-)
~wog
What a lot of people fail to realize is that a lot of "java performance problems" are caused by sub-par java programmers who don't understand how costly some operations are. Another entire class of performance problems are caused by bad algorithms. An O(n) algorithm coded in QuickBasic will outperform an O(n^2) algorithm hand-coded in assembly language for most possible inputs.
OK, so all things being equal, using smart algorithms, and not abusing the language, java is still a bit slower than C. Big deal! In most cases, it doesn't matter. Server-side apps are blocking on I/O most of the time anyway; client-side apps are blocking on user interaction most of the time. For projects with hard real-time requirements, you have the RTJ standard; if you're really speed-hungry or are doing serious systems work, then you can write it in C.
However, my employer could buy a middle-range Sun workstation for what he pays for my time in a week, and I'm a lot more productive in Java than I am in C. Furthermore, because I pay attention to engineering and design issues, other engineers can re-use and subclass my code without modifying it. If I've used good algorithms, avoided stepping on the GC, and steered clear of known performance problems (like the + operator for Strings and the unnecessarily synchronized Java 1 collection classes), then my code is probably fast enough. If it's not, then it's a lot cheaper for my boss to requisition a faster machine than it is for him to pay me for an extra two months to chase pointers and re-model object-oriented systems in procedural code.
~wog
On the server side it is different. Java is a very nice language to develop in. The class library is HUGE and having the flexibility to support several platforms at the server is very good and something we surely will take advantage of in the future. It seems to be easier to optimize server side JVMs also.
Java is here to stay, especially at the server. Those who flame Java for its weak points (small client applications) should look closer on the areas where it rocks, before discarding the language as a whole.
I've seen 'real' applications written in Java. I've used Moneydance personally, and several custom apps we've designed at work, and a couple of shrinkwrap apps written in Java, both stand-alone and Web-based. For the most part, they perform very well. Java does indeed rock as a programming language. That, however, is a seperate issue from it's execution speed, and it's speed (or lack thereof) cannot be attributed to the language as a whole, but rather to the implementation of the JVM. A good JVM and/or JIT greatly enhances the Java experience.
People who say that Java is slow are correct, for the most part. Even with the best JVM, Java cannot approach the speeds of a well-designed native-code application. This does not mean that Java is a bad programming language, or inappropriate for mission critical apps. We have several mission critical apps written in Java. They run well, and are stable. The loss of speed in the application, though, was not great enough to outweigh the benefits of the cross-platform execution. We can design the app on AIX, OS/390, OS/2, Windows NT, or Windows 2000, and we can compile that app once, and then we can take that compiled app and run it on AIX, OS/2, Windwos NT, or Windows 2000, or OS/390. The simple fact of 'compile once, run anywhere' so far outweighs the speed loss that it's worth it.
So, you are wrong when you say that "The very fact that someone claims that shows that they are not in the industry and have no idea what's going on in the Real World (tm)". I say that Java is slow, and I work in the "Real World (tm)". It's just that the slowness disadvantage is not near as important as the advantages.
Matthew Vanecek For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting i
*yawn*
Obviously it's fast enough for the couple hundred thousand or so (millions?) of Java coders and companies that use it every day in mission critical applications all over the world.
Seriously, I doubt you have any real world experience with Java if that's still your take on it. Yeah, three years ago, it wasn't fast enough. Things have dramatically changed since then.
Anyone can code a crappy app in C and say "woah! look, it sucks! it's slow!". That doesn't prove that C would be slow - it proves that the code sucks. In the same way, an amateur not knowing what he or she is doing with Java can see slow apps. If you know what you're doing, the situation is different.
I don't know about the rest of you here but I'm getting very tired of the same old "Java is slow" and "I've never seen any real apps in Java" myths here on Slashdot. The very fact that someone claims that shows that they are not in the industry and have no idea what's going on in the Real World (tm).
It isn't pretty. All of the Windows solutions beat all of the linux solutions, inlcuding gcj.
Java may be adequate on linux, but I really don't know how you could conclude that it "rocks".
Javalobby stats should not be trusted - my experience is that Javalobby has the lowest collective IQ of any community tech site on the web, and their articles are typically mindless advocacy with no useful data.