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. "
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!
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.
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...)
Slashdot Mirror
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.
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.
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...)