Slashdot Mirror
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.
Okay, I can understand being happy when something like NVIDIA's OpenGL (which is very Windows oriented) performs nearly as well on Linux. However, does Linux Java being slower than Win32 Java "rock?"
A deep unwavering belief is a sure sign you're missing something...
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
Not just CPU - but of course it also helps some in making the speed disadvantage less noticable. I have this old texture filler that I coded some years ago to test the speed of Java graphics and on JDK 1.1.4 (or .3 or whatever) it ran with about 8 frames per sec on a given texture on a given polygon on a given app on a given computer. Microsoft's jview clocked around 12 fps.. Then with JDK 1.2.0, it dropped to around 3 (!!) on some color models, but I wrote another version that used a color model without any alpha channel and the speed was now somewhere around 8 fps. Meanwhile, JDK 1.1.8 was clocking up to 15 fps. With 1.2.2, it's up to 17 and 1.3.0 is almost at 20 fps. This is still with the same machine, same texture, same app.. The computer I use for this is my IBM 390 laptop that has a Pentium 233MHz MMX. On my AMD K7 / 500 Mhz, I get over 45 frames per second using 1.3.0.
The speedup is directly visible in apps that use GUI's - Swing in particular.
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.
Java too slow? We've heard that a million times. Boring. It's quick enough for thousands of Java hackers out there.
It's not as quick as C performance-wise, but you get a speed tradeoff in return for platform independence, greater stability etc etc. The vast majority of apps being written today do not need to be blindingly fast. It's much more useful to have them written faster and be easier to mantain, both of which are helped a lot by Java.
I suspect most of the flame I hear against Java is from established C coders who are scared they'll have to learn a new language. Try it, you might like it. I use Java and Perl almost exclusively now. I wouldn't use C now unless I was feeling masochistic or had to do something really low-level.
Saying that Java is hype because you used it to write software which is not its core competency is an instance of a poor worksman blaming his tools
Java's GUI API will always be slower than Native GUI toolkits. In most instances if the app is complex then it'll be almost unusably slow. Heck, even Sun has canned most of its Java GUI tools because they became unusable the larger they became.
Perl is the king of text processing languages (no contest) and C++ gives more fine grained control of sockets than Java.
Now for medium to large scale, cross platform, multithreaded, easily extensible, middleware applications that will need little or no maintainance but are easily maintenable, Java(TM) cannot be beat.
PS: Your rant is similar to someone bitching that C sucks because it is poor at text processing even though C was designed as a portable assembly language.
The Queue Principle
"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."
;)
Funny, that's just what they say on JavaLobby about Slashdot
The survey is here, go and vote. Recently, a petition was put forward to open source javadoc (the Java sourcecode documentation tool), but Sun hasn't responded (possibly due to lack of attention from the media). I think if we really bug Sun about this, we might get an official response (*fingers crossed*).
As to the topic at hand, my primary Linux JDK for development is IBM's. It's excellent, and very fast - I haven't had any problems. Sun's 1.3.0 JDK hasn't even been officially released for Linux or Solaris yet, so there's not really much of an alternative at the moment.
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.