Posted by
Hemos
on from the it's-new-it's-fast dept.
scode writes: "IBM's has finally
released
a preview of their JDK 1.3 for Linux, and it's just as fast as their 1.1.8!
This is great news for Java on Linux, because it's the first Java 2 compliant Linux JVM that's really fast. "
Non-x86 Linux users in the dust, as usual
by
Gepard
·
· Score: 4
Good job, IBM. It's wonderful that support is so forthcoming. Though naturally, when someone says ``available for Linux,'' they really mean ``available for Intel Linux.''
Users of all other Alpha Linux are screwed. PowerPC Linux. UltraSPARC Linux.
Oh well, that's the real world, isn't it? It'd be nice if there at least was some source code to play with on other architectures. But that, naturally, isn't forthcoming.
IBM Native Threads implementation inefficient
by
Leghk
·
· Score: 5
Although IBM's 1.1.8 JDK was by far the fasted VM available for linux [aside from native compiling towerJ] it's native threads' implementation was not nearly as efficient as Blackdown's. IBM uses a mixed-mode JIT, which ends up ( in my experience) considerably faster then even Inprise's JIT plugged into Blackdown's VM for single thread loads. However, under heavy multi-thread loads, IBM's VM acctually underperforms blackdown's vm considerably. You can tell their threads implementation is a bit "funny" because when a system running the IBM JRE is under heavy load, the entire system becomes unusable, --even if the load average is only nearing 2. The mouse becomes extreemly jerky in X, console commands take 3-5 seconds to execute, all this with 5 active threads. Verses with blackdown's VM I've had 40 active running threads, and the rest of the applications run just as responsivly as you would expect linux to. I suspect IBM did a bit of cheating, and toyed iwth the priority threads were being issued, such that IBM VM threads end up being the highest priority to run. This gives them a bit of an edge when it comes to single threaded benchmarking; but once the IBM VM threads start competing against eachother.. it all falls to bits. I wonder if they'll fix that in 1.3.
Just ran some benchmarks, looks like some solid progress on the IBM JVM under threadload. IBM's JVM is now runs just short of TowerJ's performance. If you're not familure with TowerJ, it's a commerical piece of software which given a set of java class files, turns them into C++ code. Then runs GCC over them, producing a native binary. TowerJ [specifically on Linux] is currently ranked in the top slot on the Volano Benchmark. TowerJ under linux even beats TowerJ under NT; apparently in the words of the TowerJ engineers, the linux libraries are just more efficient:)
You can view a JVM graph here of the various Linux JVMs under load. As you can see the old IBM JVM didn't fair very well under threadload, regardless that it generally ran faster for single threaded applications. Good work IBM!
The ability to move a Java program from one platform to the other without having to recompile is overrated. It's not that big a deal to recompile, especially if you know that you don't have to do any system-dependent #defines like you do in C.
I would think that the main reasons to use Java are:
Simplicity
Built-in threading
Garbage collection
A great set of standard libraries
Bounds checking on arrays (really, avoiding the C/C++ pointer overrun problems)
The ability to print a stack trace from an exception (oh how I miss that when I do C++!)
Reflection
I don't see how a compiled, system and arch dependant binary would eliminate any of those reasons.
Kudos to IBM for providing this environment (even if it expires after 90 days). Note: also thanks to the Blackdown team who have done an excellent job in less than excellent conditions to provide excellent tools that I rely on now.
A note on Java: This is actually a huge boon for Linux. Look at it this way...Linux provides an excellent (cheap and stable) platform on which to develop Java applications. I'm not talking about applets here...I'm talking about large / distributed software systems. I'm building one in a research setting right now using CORBA that's up to 40 KLOC.
I develop entirely on Linux using XEmacs, CVS, and make. For everyone who argues that there isn't a good Java development environment for Linux (article seen recently on ZDNet), that talk is for the birds. These are perfectly good tools that have been proven in the trenches writing code for the guts of the internet, UNIX, C/C++, and thousands of other packages / programs. If you want an environment that handles drag & drop JavaBeans, servlets, etc, go buy a fast box with 256 MB memory and JBuilder. The tool works just fine...just put the horsepower behind it. This isn't to say that XEmacs could be useful for the average Joe programmer (VB developers-come-Java programmers). It does take some tinkering, but there are good develoment environments out there. Anyway, what does a good environment provide you that you can't accomplish with a shell, some scripts, and syntax highlighting. Nothing as far as I've seen except bulk, sluggishness, and programmers who don't understand the fundamentals of development and rely on the tools to find their problems (a poor way to program).
Linux provides a great platform for this kind of development, though, and the gains realized are immense. I can run my object servers spread across the network and virtually guarantee that my clients can run on Mac, Solaris, Linux, and even Microsoft as long as the appropriate Java runtime is installed. Remember, this is an application not an applet! The Swing toolkit is slow and has a huge memory footprint, granted, but there are also some fabulous Swing tools out there (NoMagic MagicDraw UML comes to mind).
I'm not getting religious here; I use Perl, Tcl/Tk, and C/C++ when appropriate. All I'm saying is that Java has its place, and a great toolkit like this one from IBM goes a long way to advancing the Java development capabilities of software developers who won't pay for SPARCs or Windows and want a customizable, robust, and fast environment.
So, knock off the hatred of Java, find some good development tools, and use it for what it's good for (use Flash for providing animations in web browsers), as a full featured applications development language with thorough APIs. It's not perfect, but it has its place in a development toolkit.
Kudos to IBM. Keep up the good support.
Very few good C++ programmers out there...
by
rjh
·
· Score: 4
First, your points are spot-on when it comes to C versus Java. When comparing C++ to Java, though, many of your issues go away.
Simplicity: a well-architected C++ solution, which intelligently uses the appropriate features of the language, is just as simple as Java. In fact, Java borrowed most of its simplicity from C++ in the first place.
Threading: Okay, this one is granted.
Garbage collection: Contrary to popular belief, Java's GC isn't exactly the best thing since sliced bread. There's a fairly large industry providing third-party garbage collection tools for Java. Can't remember any of them off the top of my head, but I do know that some of them are wealthy enough to afford full-page ads in Communications of the ACM.
Bjarne Stroustrup has also said that GC will likely be implemented in the next ANSI draft of C++. While that doesn't balance C++ and Java, it does mean that you're comparing no GC in C++ to a somewhat broken GC in Java. Neither one is an optimal solution.
Standard libraries: Are you at all familiar with the STL and free (liberty) C++ libraries? The advantage of Java isn't that it has every function under the sun; it's that the collection which ships with the JDK is very comprehensive. C++'s body of free (liberty) libraries is far superior, but you have to search for them.
I also have a slight objection to your use of the word "standard". There is no Java standard; therefore, there can be no standard library. C++ has been standardized; Java isn't.
Bounds checking on arrays: C++ includes this. It's included this for quite some time. It's not possible to bounds-check a C array, but it's trivial to bounds-check a C++ container (list, vector, etc.).
Printing stack traces from exceptions: Look around the free (liberty) C++ libraries. I'd be extremely surprised if you couldn't find one.
Reflection: C++ includes this. It's called RTTI (run-time type identification).
... I am not trying to denigrate Java or elevate C++. I've used both, and I have no clear favorite between the two. Java borrows very heavily from C++, and it constantly surprises me at just how many Javagrinders say "well, C++ doesn't have features foo and bar!" without realizing that Java borrowed foo and bar from C++.
That said, it is incredibly difficult to become a good C++ programmer. The language is straightforward, but has extremely complex nuances which require years of exposure to fully comprehend. Java is a much more straightforward language, but occasionally the lack of nuance makes it difficult to achieve subtle hackery.
This whole thread is built on a misconception. Modern Java VMs, such has Sun's HotSpot on Windows or IBM's 1.1.8, produce code that is as fast or faster then that produced by static compilers. Some things to understand: (1) Java code IS compiled. Its just compiled at run-time rather then build-time. The result is the same however-- machine code running on your machine. (2) JITs have a number of advantages over static compilers: (a) A static compiler must compile for a lowest common denominator platform (typicly Pentium). A JIT can determine the processor type at run-time and produce processor-tuned code. (b) A static compiler must "guess safe" in situations where code is ambiguous. A JIT can go ahead and take risky optimizations because it can un-optimize if the need arises. One place this occurs a lot is in in- lining. The static compiler can only safely in-line finals. The JIT can try to in-line anything and adjust by how the code actually gets used. (HotSpot calls this "agressive inlining" and you can read about it at the HotSpot section of java.sun.com) Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.) There are some actual experiemntal numbers and a chapter discussing this and other Java v. native code issues in "Java(tm) Platform performance: Strategies and tctics" coming out at JavaOne. (Its already up for pre-order at amazon...)
For anybody listening to this BS, I suggest you actually do some experiments yourself. Java and C++ are close enough that it's quite easy to compile virtually identical code in both. There are too many lies told by both sides and ymmv depending on what you're doing.
I typically find Java runs at 1/5th the speed of C++ (using latest compilers). My own results correlate closely with http://sprout.stanford.edu/uli/java_cpp.html
Listening to what Sun says about Java v C is like listening to what Microsoft says about W2k v Linux.
Your arguments are fine theoretically, they're just false in practise. HotSpot is not nearly that good yet.
-- http://rareformnewmedia.com/
People who like vi like java
by
twdorris
·
· Score: 4
Here's something I thought I'd throw out there. First, a bit of a disclaimer. I'm no MS VB weenie that likes Java because it's simple to use. I prefer coding in assembler and I do so quite often when appropriate (I reprogram the ECU in my car, for example). However, I also happen to really enjoy coding in Java. It's the most "pleasant" coding environment I've ever used in the past 15 years; period.
I'm a big fan of the "learn one thing well and become an expert on it" approach to life. I focus on something that I know is going to be powerful and/or popular in the future and I learn it well. Java is that thing when it comes to coding.
I learned about vi while in college (about 5 years ago). I thought it was weird and awkward to use, but because it was everywhere and because I could focus on honing my skills with that one editor and be proficient on so many different platforms with it all at once, I learned it. Now I know that editor very well and I happily co-develop under Linux, Solaris, HP, AIX, and even windows with it.
Java is the same type of thing. I learned Java, I learned it well, and now I code peacefully on all those same platforms (sans HP and AIX...I just haven't used those in a while). I've written a datalogger in Java using Swing for my car that works in conjunction with the aforementioned ECU reprogramming effort to provide me with real time data gathering while I'm powering around at the track. What's great is that I did ALL my development under Linux. When it was all done, I slapped the exact same jar file under Windows NT for a friend of mine with a similar car (didn't even have to recompile it!) and it ran flawlessly. He prefers Windows, I prefer Linux.
Why on earth would I have ever considered writing that application under anything but Java? If I had used MFC, I would not only still be pulling my hair out trying to figure out what the hell was wrong with it, but I also would be forced to use Windows when I was done. The same is true if I had coded it using Motif or GNOME/Gtk or most any other X-based environment. I could not have shared that application with friends that happen to like Windows.
That's one of the many benefits of Java; and it's one of the benefits of vi. Learn something that's powerful and flexible once, learn it really well, and you end up reaping benefits from it on a variety of different platforms. Java is quite powerful and I'm happy as hell to see IBM doing all the great work they're doing with Java under Linux!
Slashdot Mirror
Good job, IBM. It's wonderful that support is so forthcoming. Though naturally, when someone says ``available for Linux,'' they really mean ``available for Intel Linux.''
Users of all other Alpha Linux are screwed. PowerPC Linux. UltraSPARC Linux.
Oh well, that's the real world, isn't it? It'd be nice if there at least was some source code to play with on other architectures. But that, naturally, isn't forthcoming.
Although IBM's 1.1.8 JDK was by far the fasted VM available for linux [aside from native compiling towerJ] it's native threads' implementation was not nearly as efficient as Blackdown's. IBM uses a mixed-mode JIT, which ends up ( in my experience) considerably faster then even Inprise's JIT plugged into Blackdown's VM for single thread loads. However, under heavy multi-thread loads, IBM's VM acctually underperforms blackdown's vm considerably. You can tell their threads implementation is a bit "funny" because when a system running the IBM JRE is under heavy load, the entire system becomes unusable, --even if the load average is only nearing 2. The mouse becomes extreemly jerky in X, console commands take 3-5 seconds to execute, all this with 5 active threads. Verses with blackdown's VM I've had 40 active running threads, and the rest of the applications run just as responsivly as you would expect linux to. I suspect IBM did a bit of cheating, and toyed iwth the priority threads were being issued, such that IBM VM threads end up being the highest priority to run. This gives them a bit of an edge when it comes to single threaded benchmarking; but once the IBM VM threads start competing against eachother.. it all falls to bits. I wonder if they'll fix that in 1.3.
I would think that the main reasons to use Java are:
Simplicity
Built-in threading
Garbage collection
A great set of standard libraries
Bounds checking on arrays (really, avoiding the C/C++ pointer overrun problems)
The ability to print a stack trace from an exception (oh how I miss that when I do C++!)
Reflection
I don't see how a compiled, system and arch dependant binary would eliminate any of those reasons.
Kudos to IBM for providing this environment (even if it expires after 90 days). Note: also thanks to the Blackdown team who have done an excellent job in less than excellent conditions to provide excellent tools that I rely on now.
A note on Java:
This is actually a huge boon for Linux. Look at it this way...Linux provides an excellent (cheap and stable) platform on which to develop Java applications. I'm not talking about applets here...I'm talking about large / distributed software systems. I'm building one in a research setting right now using CORBA that's up to 40 KLOC.
I develop entirely on Linux using XEmacs, CVS, and make. For everyone who argues that there isn't a good Java development environment for Linux (article seen recently on ZDNet), that talk is for the birds. These are perfectly good tools that have been proven in the trenches writing code for the guts of the internet, UNIX, C/C++, and thousands of other packages / programs. If you want an environment that handles drag & drop JavaBeans, servlets, etc, go buy a fast box with 256 MB memory and JBuilder. The tool works just fine...just put the horsepower behind it. This isn't to say that XEmacs could be useful for the average Joe programmer (VB developers-come-Java programmers). It does take some tinkering, but there are good develoment environments out there. Anyway, what does a good environment provide you that you can't accomplish with a shell, some scripts, and syntax highlighting. Nothing as far as I've seen except bulk, sluggishness, and programmers who don't understand the fundamentals of development and rely on the tools to find their problems (a poor way to program).
Linux provides a great platform for this kind of development, though, and the gains realized are immense. I can run my object servers spread across the network and virtually guarantee that my clients can run on Mac, Solaris, Linux, and even Microsoft as long as the appropriate Java runtime is installed. Remember, this is an application not an applet! The Swing toolkit is slow and has a huge memory footprint, granted, but there are also some fabulous Swing tools out there (NoMagic MagicDraw UML comes to mind).
I'm not getting religious here; I use Perl, Tcl/Tk, and C/C++ when appropriate. All I'm saying is that Java has its place, and a great toolkit like this one from IBM goes a long way to advancing the Java development capabilities of software developers who won't pay for SPARCs or Windows and want a customizable, robust, and fast environment.
So, knock off the hatred of Java, find some good development tools, and use it for what it's good for (use Flash for providing animations in web browsers), as a full featured applications development language with thorough APIs. It's not perfect, but it has its place in a development toolkit.
Kudos to IBM. Keep up the good support.
First, your points are spot-on when it comes to C versus Java. When comparing C++ to Java, though, many of your issues go away.
Simplicity: a well-architected C++ solution, which intelligently uses the appropriate features of the language, is just as simple as Java. In fact, Java borrowed most of its simplicity from C++ in the first place.
Threading: Okay, this one is granted.
Garbage collection: Contrary to popular belief, Java's GC isn't exactly the best thing since sliced bread. There's a fairly large industry providing third-party garbage collection tools for Java. Can't remember any of them off the top of my head, but I do know that some of them are wealthy enough to afford full-page ads in Communications of the ACM.
Bjarne Stroustrup has also said that GC will likely be implemented in the next ANSI draft of C++. While that doesn't balance C++ and Java, it does mean that you're comparing no GC in C++ to a somewhat broken GC in Java. Neither one is an optimal solution.
Standard libraries: Are you at all familiar with the STL and free (liberty) C++ libraries? The advantage of Java isn't that it has every function under the sun; it's that the collection which ships with the JDK is very comprehensive. C++'s body of free (liberty) libraries is far superior, but you have to search for them.
I also have a slight objection to your use of the word "standard". There is no Java standard; therefore, there can be no standard library. C++ has been standardized; Java isn't.
Bounds checking on arrays: C++ includes this. It's included this for quite some time. It's not possible to bounds-check a C array, but it's trivial to bounds-check a C++ container (list, vector, etc.).
Printing stack traces from exceptions: Look around the free (liberty) C++ libraries. I'd be extremely surprised if you couldn't find one.
Reflection: C++ includes this. It's called RTTI (run-time type identification).
... I am not trying to denigrate Java or elevate C++. I've used both, and I have no clear favorite between the two. Java borrows very heavily from C++, and it constantly surprises me at just how many Javagrinders say "well, C++ doesn't have features foo and bar!" without realizing that Java borrowed foo and bar from C++.
That said, it is incredibly difficult to become a good C++ programmer. The language is straightforward, but has extremely complex nuances which require years of exposure to fully comprehend. Java is a much more straightforward language, but occasionally the lack of nuance makes it difficult to achieve subtle hackery.
This whole thread is built on a misconception. Modern Java VMs, such has Sun's HotSpot on Windows or IBM's 1.1.8, produce code that is as fast or faster then that produced by static compilers. Some things to understand: (1) Java code IS compiled. Its just compiled at run-time rather then build-time. The result is the same however-- machine code running on your machine. (2) JITs have a number of advantages over static compilers: (a) A static compiler must compile for a lowest common denominator platform (typicly Pentium). A JIT can determine the processor type at run-time and produce processor-tuned code. (b) A static compiler must "guess safe" in situations where code is ambiguous. A JIT can go ahead and take risky optimizations because it can un-optimize if the need arises. One place this occurs a lot is in in- lining. The static compiler can only safely in-line finals. The JIT can try to in-line anything and adjust by how the code actually gets used. (HotSpot calls this "agressive inlining" and you can read about it at the HotSpot section of java.sun.com) Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.) There are some actual experiemntal numbers and a chapter discussing this and other Java v. native code issues in "Java(tm) Platform performance: Strategies and tctics" coming out at JavaOne. (Its already up for pre-order at amazon...)
For anybody listening to this BS, I suggest you actually do some experiments yourself. Java and C++ are close enough that it's quite easy to compile virtually identical code in both. There are too many lies told by both sides and ymmv depending on what you're doing.
I typically find Java runs at 1/5th the speed of C++ (using latest compilers). My own results correlate closely with http://sprout.stanford.edu/uli/java_cpp.html
Listening to what Sun says about Java v C is like listening to what Microsoft says about W2k v Linux.
Your arguments are fine theoretically, they're just false in practise. HotSpot is not nearly that good yet.
http://rareformnewmedia.com/
Here's something I thought I'd throw out there. First, a bit of a disclaimer. I'm no MS VB weenie that likes Java because it's simple to use. I prefer coding in assembler and I do so quite often when appropriate (I reprogram the ECU in my car, for example). However, I also happen to really enjoy coding in Java. It's the most "pleasant" coding environment I've ever used in the past 15 years; period.
I'm a big fan of the "learn one thing well and become an expert on it" approach to life. I focus on something that I know is going to be powerful and/or popular in the future and I learn it well. Java is that thing when it comes to coding.
I learned about vi while in college (about 5 years ago). I thought it was weird and awkward to use, but because it was everywhere and because I could focus on honing my skills with that one editor and be proficient on so many different platforms with it all at once, I learned it. Now I know that editor very well and I happily co-develop under Linux, Solaris, HP, AIX, and even windows with it.
Java is the same type of thing. I learned Java, I learned it well, and now I code peacefully on all those same platforms (sans HP and AIX...I just haven't used those in a while). I've written a datalogger in Java using Swing for my car that works in conjunction with the aforementioned ECU reprogramming effort to provide me with real time data gathering while I'm powering around at the track. What's great is that I did ALL my development under Linux. When it was all done, I slapped the exact same jar file under Windows NT for a friend of mine with a similar car (didn't even have to recompile it!) and it ran flawlessly. He prefers Windows, I prefer Linux.
Why on earth would I have ever considered writing that application under anything but Java? If I had used MFC, I would not only still be pulling my hair out trying to figure out what the hell was wrong with it, but I also would be forced to use Windows when I was done. The same is true if I had coded it using Motif or GNOME/Gtk or most any other X-based environment. I could not have shared that application with friends that happen to like Windows.
That's one of the many benefits of Java; and it's one of the benefits of vi. Learn something that's powerful and flexible once, learn it really well, and you end up reaping benefits from it on a variety of different platforms. Java is quite powerful and I'm happy as hell to see IBM doing all the great work they're doing with Java under Linux!