Slashdot Mirror
IBM Releases Fastest SDK For Java 6
IndioMan writes "IBM is releasing an SDK for Java 6 and is sponsoring an Early Release Program to gather feedback from the Java community. Product binaries and documentation are available for Linux on x86 and 64-bit AMD, and AIX for PPC for 32- and 64-bit systems. In addition to supporting the Java SE 6 Platform specification, IBM's SDK also focuses on platform stability, performance, and diagnostics. It's tops on every benchmark."
Sun didn't want to delay the launch of Java 6, so it's Java 7 that's open source.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I forgot to include my sources for that:
Behind the scenes -- from Mark Reinholds Blog.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Funny, but even Sun's JDK blows Perl out of the water.
1998 called, and they want their joke back.
Hasn't been funny or true for a long time...
This was originally released back in the middle of November 2006!
h read.jsp?forum=367&thread=142364&cat=10
http://www-128.ibm.com/developerworks/forums/dw_t
Why did the parent modded as troll? It's quite true. For example, look at The Computer Language Shootout. Sun's JVM is much faster than Perl in almost every benchmark except for startup times. Perl's memory consumption is somewhere better, but not even close to the same degree that Java is faster.
Those benchmarks are based on Java 1.5, too. 1.6 is even faster.
Karma: Terrifying (mostly affected by atrocities you've committed)
FTA
Systems Affected
Sun Java Runtime Environment versions
* JDK and JRE 5.0 Update 9 and earlier
* SDK and JRE 1.4.2_12 and earlier
* SDK and JRE 1.3.1_18 and earlier
Fortune favors the bold.
There are 2 ways to get a 32-bit Java plugin running under a Linux/AMD64 environment (BTW, AMD64 is the official arch name implemented by AMD and Intel, x86-64 has been officially abandonned):
Of course, since Sun has open sourced Java, a 64-bit Java plugin is likely to appear soon.
Scimark wasn't even close:
IBM java6:
Composite Score: 482.8282568762099
FFT (1024): 551.8002634079949
SOR (100x100): 568.7588552216857
Monte Carlo : 64.62096017621073
Sparse matmult (N=1000, nz=5000): 219.84569330460474
LU (100x100): 1009.1155122705532
Sun java6:
Composite Score: 617.5119705454583
FFT (1024): 510.7586118547276
SOR (100x100): 829.8686416193439
Monte Carlo : 118.25350583943022
Sparse matmult (N=1000, nz=5000): 470.6355733620428
LU (100x100): 1158.0435200517468
Higher scores are better. Both run on AMD X2 5000+
Sun VM stomped on IBM's. That wasn't true with earlier VM's. IBM used to smoke Sun on scimark. Maybe there's more development to be done.
Client side, that is true. Server side, its just as fast or sometimes faster. See http://kano.net/javabench/ and http://www.aceshardware.com/Spades/read.php?articl e_id=153
That's not true. The source code has already been opened as a project:
https://jdk.dev.java.net/
The fact that they haven't made their first release from that product changes nothing.
But the fact that only parts are Free Software (or "Open Source" as they call it) yet does.
https://openjdk.dev.java.net/
The slow performance of Eclipse is not due to the JVM, it's about the SWT library and it's bindings with the native libraries. There was an SWT port called SWT Fox that quickened things up a bit. It doesn't seem to be maintained anymore, but the performance speedup was very noticable. Changing the VM probably won't make the slightest of difference.
That cost me two moderations. Why aren't moderations in a discussion depended on the *branch* of the discussion? Oh well...
In the meanwhile, we've still got customers stuck on 1.3, because our "write once, run anywhere" code doesn't run on 1.4, and it's too much effort to puzzle out why because Sun's runtime is just such a mess.
h tml
There could be several reasons why Java 1.3 code won't run on 1.4. One is if you use sun.* or com.sun.* packages directly, which is funcamentally against portability guidelines. Another could be real incompatibilities. There are very few incompatibilities between 1.3 and 1.4. They are listed here:
http://java.sun.com/javase/compatibility_j2se1.4.
If you keeping customers from using Java 5.0 or Java 6.0 because you can't sort this out, you are keeping them from major performance and functional improvements.
we've still got customers stuck on 1.3, because our "write once, run anywhere" code doesn't run on 1.4, and it's too much effort to puzzle out why
... that can be tweeked however by forcing the 1.4 compiler to generate 1.3 compatible byte code.
... you should be able to rewrite your code to use my.working.repalcement.of.MyClass very simple.
Sorry, but I don't believe that. You probably have problems to run 1.4 java on a 1.3 VM
1.3 byte code must by definition run on a 1.4 machine, and if there is indeed a problem in the class libraries a simple look at the exception trace should show you where. Even if you have used the same faulty class often, e.g. a com.sun.faulty.MyClass
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Well, you're probably not a Ruby developer then :-) Ruby's switching to a new VM in the next release, it's part of the mainline CVS sources. I've not benchmarked it myself, but it's supposed to be 2x faster already.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Doesn't seem to be the case here. I'm doing some pretty heavy numerical stuff with java these days. The Sun java6 VM definitely outshines others at the moment. That used to be the case with the IBM VM. Maybe once it comes out of early release it'll be back to it's former glory.
That's being a wise-ass for the sake of being a wise-ass. wise-ass? I think not - you explicitly stated servlets, not JSPs when in truth JSPs are for all intents and purposes servlets. There is no way to predict _how_ a JSP will be compiled into a servlet (it's engine specific, after all), ergo no way to compare the outcome. For all I care the engine encodes a JSP to go to sleep for a second or so before it produces any output. Wouldn't violate the spec, but I wouldn't be able to tell. The end result is a class file on every single system I've worked on. The conjecture that spurious crap happens is an empty strawman at best. Some engines may be more efficient than others, but that's true of any set of compilers. And I was trying for a bare-bones comparison, because anything beyond bare-bones is equally unpredictable; You're missing my point: the application server within which servlets run typically contain far more plumbing than Apache web servers. They were also designed for different tasks. You'll note that my originally statement was that your "'benchmark' wholly slanted to the 'lightness' of C++.". That statement is true, and even more true in light of the above sets of statements. what do you want to test - database access ? How can you possibly tell what it is you're waiting for ? Well, in my experience, you're waiting for network latency, no matter what you program your client in. So you're admitting that the performance of your application layer is largely irrelevant? Then what's the argument about? I want the bare-bones comparison precisely because it tells me what I can expect in terms of primary throughput from a webserver. which is irrelevant for an application layer. Let the webserver serve web pages, let the application tier do its job. As for programmability (which, I suspect, is really your point) then I guess your conjecture is as good as mine. The fact that there are more java programmers out there, or that business people use java programmers more doesn't necessarily mean that java is better for the job; it might just mean that java is more comprehensible to stupid people. Perhaps C++ programmers are so set in their ways of making buggies.... (just in case you don't get the double entendre, as you seem to be intentionally dense, that's a direct reference to the buggy manufacturers in the early 1900s as those new-fangled motor vehicles started taking over. It's also a reference to how C/C++ programmers continually produce the same common bugs, over and over again in their code - buffer overflows, bad pointer math, etc. Not that Java programmers don't do their own versions of these things, they just get there faster.;)
But seriously - you're either an elitist snob C++ programmer or a troll - I don't really care to figure out which. I personally think C++ has grown into an abomination of its initial intent, which was a clean concise OO version C. Either way, I've met folks in both that are unfit for coding. It just so happens that in C/C++, those that are unfit are generally filtered out pretty quickly because continuous crashes are hard to hide. (Yes, Java is more forgiving.)
Meanwhile maybe I'll go checkout the latest releases of Smalltalk or Ruby, or perhaps even Eiffel.
The cesspool just got a check and balance.
Maybe you should look at an actual benchmark instead of assuming servlets would be slow. Yes, it depends on the platform, JDK, and servlet container. Resin with the IBM JDK did 510 'Hello, world' pages per second while mod_perl/Apache did only 324. The 'Hello, world' servlet even been mod_php on Apache's static page rate of 497 requests per second. With a 'Hello, world' implementation, you really have to look at the web server overhead. Where did you think the overhead was going to be in writing to a stream? What made you assume a servlet would be slower? It really depends on how the web server performs.
Hmm...interesting...this article says that there are 64-bit VMs with JIT. And this one talks about "beta versions for Windows 2000 and Linux on the Itanium platform (the virtual machine being a true 64-bit application)." Now it may be that these JITs are just compiling to x86 code, which then runs on an Itanium, so maybe it wouldn't be quite as fast as code that was specifically generated for the Itanium instruction set, but still I would think the performance would be plenty good enough for running applets in a web browser, which is what the OP was talking about. AFAICT, the issue is simply that nobody has put the work into packaging the existing 64-bit VMs as browser plugins.
Find free books.