Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

IBM Releases Fastest SDK For Java 6

Posted by kdawson on Tue Jan 23, 2007 10:30 PM
from the early-start dept.
IBM Java Programming Software Linux
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."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

IBM Releases Fastest SDK For Java 6 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • x86-64 isn't just for AMD anymore you know!

      • Re: (Score:2, Funny)

        by Anonymous Coward
        Yeah, but I run your mom, and man, she runs *hot*.
  • Whatever happened to all that "Open Source Java" thingie?

  • x86_64 plugin = Heros (Score:5, Interesting)

    by baptiste (256004) <mike.baptiste@us> on Tuesday January 23 2007, @10:42PM (#17733022) Homepage Journal
    If they include a x86_64 browser plugin they'll be heros. It's 2007 and Sun still refuses to release a 64-bit browser JRE plugin because..... why?

    • Re:x86_64 plugin = Heros (Score:5, Interesting)

      by bcrowell (177657) on Wednesday January 24 2007, @12:54AM (#17734258) Homepage
      By March, 100% of Java will be available under GPL, right? So at that point, I would think that anybody who has the skills and time will be able to clean up any code that's not 64-bit clean, and compile a 64-bit browser plugin. I'm looking forward to seeing some really good things happen in OSS with Java, now that all the licensing impediments are going away.

      • Re: (Score:3, Insightful)

        by Jeff DeMaagd (2015)
        Personally, I understand why 64 bit isn't necessarily supported, but then, they support Linux and AIX on 64 bit PPC. I don't know if the 64 bit on PPC is because they've had it working for longer, because of its POWER heritage or just because it's their architecture. I also wonder if there is something about the x86 implementation that makes porting to 64 bit pretty hard.

        With respect to the browser plug-in, I don't really know that many people that are running 64 bit computers, using 64 bit aware operatin
        • I don't really know that many people that are running 64 bit computers, using 64 bit aware operating systems and 64 bit software

          In my case, that's because of a lack of support from the vendors. I can have a 64 bit OS *or* wireless networking, for example (thank you, Netgear).

        • Re: (Score:3, Insightful)

          by bwt (68845)
          I don't really know that many people that are running 64 bit computers, using 64 bit aware operating systems and 64 bit software./i>

          I do, except I run a 32-bit firefox that I install by hand because I need a java plugin that works. You have to remove the barriers before people will use it, and once you do remove the barriers, they will come.
      • > to clean up any code that's not 64-bit clean

        Usually that would be sufficient, but for a just in time compiler, 64-bit clean is not enough. It also has to be *rewritten* to produce 64-bit code. So I think there is a long way to go for Java before it catches up with the hype.

        • Re: (Score:3, Informative)

          by bcrowell (177657)
          Hmm...interesting...this [onjava.com] article says that there are 64-bit VMs with JIT. And this [devlib.org] 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
      • Hehe,

        and I'm looking forward that nothing at all is happening.

        The few people having the skills and the need to have the plug in likely have no time to do it.

        The people having the time, likely lack the skills or the motivation. I really doubt that there are programmers out there who have the feeling: Wow, today java is GPL, lets hack it better, I start immediately! Ma! Coffee!! Fast!

        angel'o'sphere

    • Re:x86_64 plugin = Heros (Score:5, Informative)

      by this great guy (922511) on Wednesday January 24 2007, @01:13AM (#17734410)

      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):

      • Use the Blackdown Java plugin, they provide a 64-bit version (it works ok, but I have come across at least 1 applet able to crash it).
      • Use nspluginwrapper [beauchesne.info] that allows you to load 32-bit plugins in 64-bit browsers.

      Of course, since Sun has open sourced Java, a 64-bit Java plugin is likely to appear soon.

      • BTW, AMD64 is the official arch name implemented by AMD and Intel, x86-64 has been officially abandonned

        Yes, x86-64 has been abandoned by both parties. However, Intel according to this FAQ article [intel.com], and this article [intel.com] is using the name Intel64, which according to the second article is just the EMT64 stuff renamed and enhanced by Intel. EMT64 was basically Intel's rip-off of AMD64; and according to the second article Intel64 is EMT64 with the SSE3, HT, and other Intel specific technologies. (I could be wron

    • Amen brother!

      • Re:x86_64 plugin = Heros (Score:4, Informative)

        by Anonymous Coward on Wednesday January 24 2007, @12:15AM (#17733932)
        maybe because the JIT compiler has to convert the java instructions to x86-64 instructions, so it's not just a simple recompile.
        Right, because that's so different when it's running under a browser than under the standalone VM that ALREADY EXISTS FOR X86-64.
      • Blackdown [skynet.be] provides 1.4.2 with a 64-bit plugin, so what's really keeping Sun from doing the same with 1.5 or 1.6?

  • What benchmarks? (Score:3, Insightful)

    by Anonymous Coward on Tuesday January 23 2007, @11:31PM (#17733484)
    It would be nice to see a few links uphold that claim.
      • It seems like ./ eds or submitters making up crap to spice up headlines again.

        Actually, IBM's JVMs have always had a reputation for very good performance. Years ago, I found IBM's Java 1.3 routinely beat equivalent code in gcc for many numeric algorithm benchmarsks.

  • This was released back in November of 2006! (Score:2, Informative)

    by Anonymous Coward
    This was originally released back in the middle of November 2006!

    http://www-128.ibm.com/developerworks/forums/dw_th read.jsp?forum=367&thread=142364&cat=10 [ibm.com]

  • Not all benchmarks better (Score:5, Informative)

    by greg_barton (5551) * <greg_barton@@@yahoo...com> on Wednesday January 24 2007, @02:00AM (#17734710) Homepage Journal
    Scimark [nist.gov] 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.
    • It still makes me wonder. Sun has been known to do crass benchmarketting before.

      E.g., when Hotspot first came around, it claimed to accelerate some benchmarks thousands of times, which was already suspect. It turns out that in one popular benchmark at the time, it completely elliminated the loop. Which in and by itself would be a valid optimization, if it were on the general case. But it turned out that as little as changing an "if (A == B)" to "if (B == A)" was enough to disable that optimization. Sun's sm

      • Re: (Score:3, Informative)

        by greg_barton (5551) *
        It still makes me wonder. Sun has been known to do crass benchmarketting before.

        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'd be nice. At the moment, eclipse has this sluggish performance when it comes to swt on linux. The VE project on my ubuntu box is much slower than in windows, and if this new jvm can perform better in this aspect, then I'm happy to read this. (there are alternatives to ve, and overall performance is fine, but again, faster is better...)

    • Re:Does this mean a faster Eclipse? (Score:5, Informative)

      by owlstead (636356) on Wednesday January 24 2007, @06:46AM (#17736118)
      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 [sourceforge.net] 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...
      • This isn't to prove, per se, that the fox toolkit is any faster than gtk but that the corresponding translation to Java is.

        The SWT binding directly accesses gtk through JNI. This may have suited IBMs purposes of accessing gtk through the SWT API but might not be the most optimal binding of gtk to Java.

        The java-gnome [sourceforge.net] project produces java bindings for gtk. They are in the process of being re-written from scratch using 2007 best practice JNI binding techniques. I suspect that an SWT implementation using t

  • Where are the sources ? (Score:3, Interesting)

    by mritunjai (518932) on Wednesday January 24 2007, @09:25AM (#17737158) Homepage

    SUN has released the sources to it's compiler and JDK.

    IBM where are thou the benefactor and promoter of Open Source ? Show us the GPL sources to your JDK and compiler!

    • Re:The Fastest JDK? (Score:5, Informative)

      by Anonymous Coward on Tuesday January 23 2007, @11:04PM (#17733204)
      Funny, but even Sun's JDK blows Perl out of the water.

      • Re:The Fastest JDK? (Score:5, Informative)

        by Yosho (135835) on Wednesday January 24 2007, @12:16AM (#17733944) Homepage
        Why did the parent modded as troll? It's quite true. For example, look at The Computer Language Shootout [debian.org]. 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.

        • Re:The Fastest JDK? (Score:5, Funny)

          by Tim C (15259) on Wednesday January 24 2007, @03:37AM (#17735194)
          Why did the parent modded as troll?

          Because this is slashdot, and perl is one of the Chosen Few Languages, along with C, Ruby, Python and PHP. Java, being both closed (for the moment) and slow (5 years ago on the client side) is not. Therefore, any statement that compares Java favourably with one of the Few Chosen Languages must be either a troll or flamebait.

          It's easier when you stop fighting the groupthink.

          • Re:The Fastest JDK? (Score:5, Insightful)

            by kv9 (697238) on Wednesday January 24 2007, @04:51AM (#17735534) Homepage

            Because this is slashdot, and perl is one of the Chosen Few Languages, along with C, Ruby, Python and PHP. Java, being both closed (for the moment) and slow (5 years ago on the client side) is not.

            I believe you mean "Chosen-Few-Languages-for-Slamming". they all get it from the slashcrowd, in no particular order:

            • Java - slow, bloaty
            • C - old and krusty, pointers baaaad, get with the times
            • Ruby - it's the new Visual Basic
            • Python - haha whitespace
            • PHP - insecure, noobs
            • Perl - gruesome syntax and readability

    • Re:The Fastest JDK? (Score:5, Insightful)

      by thule (9041) on Tuesday January 23 2007, @11:39PM (#17733570) Homepage
      I know the statement was tagged as funny, but Java is quite fast these days. Java7 will only get faster with some really spiffy JVM ideas. I don't see Python, Perl, and Ruby catching up for a while.

      It seems to me that once Java is opened up and is included with every Linux distro out there, Java will not be perceived as large and slow anymore. It will be a simple apt-get, yum, etc away. It will just work.

      • Re: (Score:2, Insightful)

        by badfish99 (826052)
        Java7 will only get faster
        Yes, and Java 53 will be really good, and everyone will like it.
        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.

        • Re: (Score:3, Interesting)

          by jrumney (197329)

          Are your "write once, run anywhere" applications using internal APIs, or are they relying on bugs in the 1.3 class libraries to run? Personally I've only ever come across code that DOESN'T run properly on 1.3, due to bugs introduced between 1.2 and 1.3, and fixed in 1.4.

        • Out of interest, are you using AWT or Swing?

        • Re:The Fastest JDK? (Score:5, Informative)

          by Decaff (42676) on Wednesday January 24 2007, @07:47AM (#17736380)
          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.

          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.h tml [sun.com]

          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.

        • Re: (Score:3, Informative)

          by angel'o'sphere (80593)
          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

          Sorry, but I don't believe that. You probably have problems to run 1.4 java on a 1.3 VM ... that can be tweeked however by forcing the 1.4 compiler to generate 1.3 compatible byte code.

          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

      • Re: (Score:2, Informative)

        by Anonymous Coward

        1998 called, and they want their joke back.

        Hasn't been funny or true for a long time...

        • Re: (Score:3, Insightful)

          by Anonymous Coward
          Hasn't been funny or true for a long time...

          I think you're wrong. Even today, over 15 years since Java was first announced, we see little use of it for client-side development. There are only a handful of consumer-grade applications written in Java, with the most popular being Azureus and RSSOwl. Even then, one of the chief complaints against them is their lack of responsiveness and their excessive memory consumption. And keep in mind that they use SWT for their GUIs, which is in fact far lighter and more r

          • Re: (Score:3, Informative)

            by Time_Ngler (564671)
            Client side, that is true. Server side, its just as fast or sometimes faster. See http://kano.net/javabench/ [kano.net] and http://www.aceshardware.com/Spades/read.php?articl e_id=153 [aceshardware.com]

            • Re: (Score:3, Interesting)

              by badfish99 (826052)
              It's certainly possible for Java code to run fast, once it's been through the just-in-time compiler, i.e. once it has been compiled to native code. That would surely be true for any language. But that means that you have to load up the whole of the compiler into memory in order to run your program. This is fine on a server, so long as you don't care about the cost of memory. It's a disaster on a client machine.
            • The links you provide have nothing to do with 'server side' and have headings like 'Why the(!) java is fast and C++ sucks'. Such a heading is obviously not indicative of bias. Furthermore, 'serverside', people compare code which is linked into a webserver (java) with external scripting languages like PHP and perl. I want to see a benchmark of a servlet pushing a simple http 'hello world' versus an apache module doing the same thing. And then with a thousand requests per second. I'm sure that you're sur

                    • Re: (Score:3, Informative)

                      by jgoemat (565882)

                      And I was trying for a bare-bones comparison, because anything beyond bare-bones is equally unpredictable; 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. I want the bare-bones comparison precisely because it tells me what I can expect in terms of primary throughput from a webserver.

                      Maybe you should look at an actual benchmark [caucho.com] instead of assuming

          • It's in the best interest of the Java community for us to admit that Java is indeed quite slow. Only after we have admitted this fact will we truly be able to improve the situation.

            Sorry, but this is simply wrong. Java is as fast as anything else. If you feel Azureus is slow and unresponding the reason is its written by an unexperienced programmer. Java is a simple language, in relation to C, and with modern IDEs it is as simple to hack code together as with Visual Basic.

            The only reason Java has obtained so

          • Re: (Score:3, Insightful)

            by samkass (174571)
            As someone who writes client-side Java, I can say that Swing is actually fairly responsive these days. However, it often suffers from a "first click is slow" problem, where the very first time you do something it's slow, then it's fast after that. So a cursory glance at Java apps often show them in the worst possible light.

            In any case, the meme that it's impossible to write a fluid, responsive UI in Java is just as wrong as it is on the server-side.

      • Re: (Score:3, Insightful)

        by try_anything (880404)
        If you work on commercial software, the type of license may determine whether you can use the code in your product.
          • I guess in my experience, the license is totally irrelevant as I am providing services, and not distributables. I suppose it would be much better for end-user programs... but I find the idea of using Java for end-user programs generally unappealing, not to mention that Sun always provided a freely distributable JRE....

            You're a little confused. The license that javac and the jvm are to be released under has nothing to do with the JRE.

    • Re: (Score:2, Informative)

      by jerkface.us (1022871)
      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

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.