Discussions

News: Yet Another Benchmark: Claims of Java being faster than C++

  1. Benchmarks always stir debate. We all know that a micro-benchmark can never claim that "X is faster than Y" in all cases. This latest benchmark by Keith Lea makes claims on the speed of Java, and shortly after Kirk Pepperdine stepped in to discuss the benchmark.

    Summary
    "I was sick of hearing people say Java was slow," says Keith Lea, "so I took the benchmark code for C++ and Java from the now outdated Great Computer Language Shootout (Fall 2001) and ran the tests myself." Lea's results three years on? Java, he finds, is significantly faster than optimized C++ in many cases.
    Discussion

    The original article: Java vs C++ "Shootout" Revisited

    Kirk Pepperdine in JDJ publishes yet another language comparison

    Joseph Ottinger in Yet Another Language Comparison

    Slashdot reports

    Threaded Messages (70)

  2. Interesting but...[ Go to top ]

    It is speed of development that is important to businesses.
    A week saved in development time can buy you a very nice server and overcome the performance issues (Obvious does not mean you should code without performance in mind).

    With small differences in performance it is not important if the development time is going to be longer. (Of course if there is a massive different in speed then you do have problem)
  3. Interesting but...[ Go to top ]

    I agree... one day of my work will always be more expensibe then 256 MB RAM.
  4. Interesting but...[ Go to top ]

    I agree blah blah etc., but I am interested to see the details because actually passing C++ in performance means that you can use Java for things other than online transaction processing.
  5. Interesting but...[ Go to top ]

    <!--I agree... one day of my work will always be more expensibe then 256 MB RAM. -->

    Yes but don't save lot of days either becuase after some days it doesn't worth any more:-)Besides that not all the performance problem can be solved by putting extra RAM..
  6. Method Call test[ Go to top ]

    The most glaring difference between C++ and the Java was the MethCall test. Looking through the code I noticed what I think is the reason why.
    Unlike Java, the C++ explicity frees up the memory used by the test every single iteration. The Java version like most other Java programs uses the garbage collection mechanism. And just because the memory is not being used, it does not automatically get deallocated on the spot.

    I think if you see the maximum memory usage for the test you'd notice that Java is orders of magnitude larger than the C++ version which cleans up after itself. Its like the difference between quick sort and merge sort in the end.
  7. Interesting but...[ Go to top ]

    Guy quoted on slashdot thread (The Java is Faster than C++ and C++ Sucks says:
    Some of the C++ tests would not compile. I've never been very good at decoding GCC's error messages...
    I wouldn't trust any benchmarks or their interpretations made by a guy who wasnt able to compile them in a first place.

    IMHO, I do not see any point in numerical Java benchmarks until it implements Fortran-like-efficient arrays. Until then simple matrix-multiplication will be dead slow when implemented in Java.
  8. in a first place.IMHO, I do not see any point in numerical Java benchmarks until it implements Fortran-like-efficient arrays. Until then simple matrix-multiplication will be dead slow when implemented in Java.
    IBM has been working on just the thing for a while now. You can find more information on "Numerically Intensive Java" @ http://www.research.ibm.com/ninja/ and an implementation of Nija can be gound @ http://alphaworks.ibm.com/tech/ninja.
  9. Sounds really interesting! Thanks!

    The only question is: Will it ever make into J2SE or J2EE?
  10. Will it ever make into J2SE or J2EE?
    Well they have been at it since 2000 over at JCP http://www.jcp.org/en/jsr/detail?id=83. Any day now ;-)
  11. Interesting but...[ Go to top ]

    Very true. For business applications speed of development is always going to win over a small win in perfomance especially with hardware these days being so inexpensive. As long as performance is ok and the thing scales then most people will be happy.

    Of course for "real time" applications things are very different. Having done no "real time" java development I can not speak on this issue but I beleive there are people out there.
  12. This kind of news comes every few weeks. A student with too much time does some benchmarks and nobody is happy about the results.
    What we need is to define a specification of what the benchmarks should do and make a call to arms to top C hackers and Java programmers to do their best effort. Otherwise the result are called biased. Let's make it a contest just to be sure.
  13. C++ 101[ Go to top ]

    Hmmm.

    Very nice work !
    Makes me proud to be a developer.

    I think that everyone making a statement like this should first take a drug test.
    The code alone is a reason for convection.

    Cheers !
  14. I believe the 100+ comments, all pointing to the flaws in this benchmark, speak for themselves. http://sys-con.com/story/feedback.cfm?storyid=45250. I appreciate Dion titling this article as "Claims...".
  15. Isn't this just a joke?[ Go to top ]

    The original "benchmark results" (not listed) at http://www.kano.net/javabench/ reads like typical juvenile humor found on sites like http://www.realultimatepower.net
  16. Zzzzz![ Go to top ]

    I'm just waiting for my friend Rolf to come in on this one. We all know this is obviously true but Rolf always seems to have an interesting alternative.

    :-)

    -John-
  17. Don't bash the author[ Go to top ]

    The title makes for interesting reading but what I find even more interesting is that the author is a CS student doing this on his spare time, not a professional being paid to run these test for a specific vendor.

    Let's give Keith credit for the initiative he took to research and run these test and post his results. In addition to this article, I have also seen Keith's Instant Messenger project, JOscar on his website (http://kano.net). Impressive work!
  18. impossible ??[ Go to top ]

    C++ which talks to the os layer directly VS java which has a whole layer of byte code ( platform independent ) before hitting the OS level.
    what would be faster ? two layers or just one ???

    Besides benchmarks are as reliable as a politician.
  19. impossible ??[ Go to top ]

    C++ which talks to the os layer directly VS java which has a whole layer of byte code ( platform independent ) before hitting the OS level. what would be faster ? two layers or just one ??? Besides benchmarks are as reliable as a politician.
    Probably it is a good time to drop C code from JVM implementation too ... .
  20. impossible ??[ Go to top ]

    Mr. shsh shshs doesn't realize that the JVM has a hotspot compiler which compiles byte code into machine code once and reuse that code. An optimizer in the JVM can look at runtime information and optimize the code on the fly. The C++ compiler can't look at how the code will run so it has a disadvantage.

    Yes, it is possible that Java with it's layer of byte code can outperform C++ which talks directly to the OS level.

    Again, I agree with most folks here. Java is fast enough for our applications and the savings in development and maintenance times make Java win hands down over C++.
  21. sour grapes[ Go to top ]

    C++ which talks to the os layer directly VS java which has a whole layer of byte code ( platform independent ) before hitting the OS level.
    what would be faster ? two layers or just one ???
    I don't know what you're talking about. C++ compiles through an IL just like Java and C#. In fact, if you think that MS completely threw away their "back end" (the part that turns their C++ IL to machine code) when doing .NET then you're crazy. You could make the claim that the various C++ ILs are better for producing x86 machine code than the Java IL, and you would probably be correct, but that isn't what you said, is it?

    Further, I'm not sure what you mean by "layer of byte code." There is no layer of byte code; Java code is run as x86 machine code just like C++ is on x86 machines (e.g. running Windows or Linux or Solaris-x86.) I'm not sure what you mean by "before hitting the OS level" either, because if your C/C++ uses the C runtime library, then it's got layers and layers of stuff before you get anywhere near the hardware or OS, just like Java (which, BTW, typically uses the C runtime library.)
    Besides benchmarks are as reliable as a politician.
    Those grapes were probably sour anyway ;-)

    (As an aside, my background does include C and C++ systems programming, so I am not speaking for pure ignorance, just partial.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  22. sour grapes[ Go to top ]

    C++ which talks to the os layer directly VS java which has a whole layer of byte code ( platform independent ) before hitting the OS level.what would be faster ? two layers or just one ???
    I don't know what you're talking about. C++ compiles through an IL just like Java and C#. In fact, if you think that MS completely threw away their "back end" (the part that turns their C++ IL to machine code) when doing .NET then you're crazy. You could make the claim that the various C++ ILs are better for producing x86 machine code than the Java IL, and you would probably be correct, but that isn't what you said, is it?Further, I'm not sure what you mean by "layer of byte code." There is no layer of byte code; Java code is run as x86 machine code just like C++ is on x86 machines (e.g. running Windows or Linux or Solaris-x86.) I'm not sure what you mean by "before hitting the OS level" either, because if your C/C++ uses the C runtime library, then it's got layers and layers of stuff before you get anywhere near the hardware or OS, just like Java (which, BTW, typically uses the C runtime library.)
    Besides benchmarks are as reliable as a politician.
    Those grapes were probably sour anyway ;-)(As an aside, my background does include C and C++ systems programming, so I am not speaking for pure ignorance, just partial.)Peace,Cameron PurdyTangosol, Inc.Coherence: Clustered JCache for Grid Computing!
    Good to know.
    My question is about runtime - java in run time dealing with .class file - the byte code VS a C ++ compiled class. Do u think they run exactly the same way and there is no difference in overhead. ( considering the grapes )

    Forget about hotspot and other stuff to optimize it - when benchmarking its very difficult to take into account all those details and in real life not everything is optimizied[ some grapes are really sour. ]
    ------------------------
    p.s. good to know ur backgroud :)
  23. sour grapes ;-)[ Go to top ]

    My question is about runtime - java in run time dealing with .class file - the byte code VS a C ++ compiled class. Do u think they run exactly the same way and there is no difference in overhead. ( considering the grapes )
    Well, there is a difference between most C++ implementations (static compilation) and most Java implementations (dynamic compilation, either JIT or adaptive.) Most C++ implementations produce the IL and then produce the machine code (sometimes with an intermediary assembly language step) as part of the compilation process. That is very rare in Java (there are only a handful of static Java compilers.)

    In Java, the IL is Java byte code, as defined by the JVM specification. This is purposeful, since it provides the portability that Java is well known for (and sometimes derided for.) It does imply though that for the Java code to be executed, it has to be either interpreted (which is how it was done 8-9 years ago) or compiled down to machine code at runtime (which is how it is done on most platforms) or pulled from a native machine code cache (a la the .NET JIT/cache model.)

    So it is definitely not the same; there is substantial overhead to bootstrap a simple Java program compared to a simple C++ program, and much of that is due to the fully dynamic nature (bindings, etc.) that the Java byte code supports.

    However, that isn't "inside the big O," and so only makes Java look ridiculously bad (which it does in this case) for repeated short-duration runs of small programs.
    Forget about hotspot and other stuff to optimize it - when benchmarking its very difficult to take into account all those details and in real life not everything is optimizied[ some grapes are really sour. ]
    Hotspot is very clever technology. Like most Sun software, it leaves a lot of potential performance on the table; if Sun were working with Microsoft and Intel on Hotspot, it would really be amazing.

    The thing is, for well architected OO code, the levels of inheritance and indirection and the raw number of method calls are amazing. Hotspot is fast for a lot of projects because of its ability to un-OO that OO code based on runtime profile information, similar to how Intel profiling compilers work (you test run the program using a "profile build" for a while, then it spits out a profile, which you use as input for a second optimizing build, which inlines lots of stuff.) In this case, Java can be much faster than C++ because Hotspot can optimize things that C++ can't (because the C++ compiler cannot be 100% sure of what indirection will be used up front.)

    For certain types of computations, Java isn't comparable though. Everyone mentions matrix math. OK, good point, you can do faster matrix math in a different language. I never had to do matrix math, but if it had to be really fast, I wouldn't use Java for it I guess. I'd buy a commercial library that has been optimized for 30 years to do it. ;-)

    There are lots of other examples. Java is not a one-size-fits-all, but it's pretty darn good for many problems that people used to use C++ for and that C++ is way overkill for.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  24. sour grapes ;-)[ Go to top ]

    Actually, there have been some compilers that take a whole Java program and grind out a great big machine-language executable. They can't do a few things, like dynamically load classes (that would not be impossible to implement in theory, but obviously it would be a lot of work, and the particular ones I saw didn't do it). I don't know what ever became of any of these. I don't know of any that are being maintained and kept up to date with the latest improvements to Java. I just wanted to mention that it is not only theoretically possible but has actually been done.

    As you point out, this strategy would not necessarily result in better runtimes, since dynamic optimization based on information available only after some running has occurred can be taken good advantage of. You might want a compiler like the Intel (and probably other) one that take in data from real runs, as you described.

    The whole thing is less attractive for architectures in which one plans to keep a JVM alive for a "long time" and dynamically deploy applications in it.
  25. sour grapes[ Go to top ]

    C++ which talks to the os layer directly VS java which has a whole layer of byte code ( platform independent ) before hitting the OS level.what would be faster ? two layers or just one ???
    I don't know what you're talking about. C++ compiles through an IL just like Java and C#. In fact, if you think that MS completely threw away their "back end" (the part that turns their C++ IL to machine code) when doing .NET then you're crazy. You could make the claim that the various C++ ILs are better for producing x86 machine code than the Java IL, and you would probably be correct, but that isn't what you said, is it?Further, I'm not sure what you mean by "layer of byte code." There is no layer of byte code; Java code is run as x86 machine code just like C++ is on x86 machines (e.g. running Windows or Linux or Solaris-x86.) I'm not sure what you mean by "before hitting the OS level" either, because if your C/C++ uses the C runtime library, then it's got layers and layers of stuff before you get anywhere near the hardware or OS, just like Java (which, BTW, typically uses the C runtime library.)
    Besides benchmarks are as reliable as a politician.
    Those grapes were probably sour anyway ;-)(As an aside, my background does include C and C++ systems programming, so I am not speaking for pure ignorance, just partial.)Peace,Cameron PurdyTangosol, Inc.Coherence: Clustered JCache for Grid Computing!
    Sure, the bytecodes are converted to ASMx86 but there are other overheads(mostly CPU usage) when using java.
    a) On Windows 2k/XP, we observe that
           there are minimum 8 threads that are created for a
           Hello World Java program.
    b) The CPU time(and memory) required for running the HOTSPOT compiler.
    c) The overheads of using the GC.
    d) No EASY way to reduce/replace the runtime library.

    Other disadvantages of java include inability to change file attributes.

    (I've been doing mostly Java for more than 4 years. Previously, I did a lot of Systems Programming using C++/C/ASM.)

    But then, Java is improving and I'm looking forward to the Java Generics -- hope the error messages with generics are lot better than the VC++/STL.

    Peace,

    Anjan
  26. sour grapes[ Go to top ]

    Anjan: Sure, the bytecodes are converted to ASMx86 but there are other overheads (mostly CPU usage) when using java.
    a) On Windows 2k/XP, we observe that there are minimum 8 threads that are created for a Hello World Java program.


    That's a particular JVM, and it's obviously not an attempt to optimize for "Hello World." You run Windows, right? Well, to run a "Hello World" Windows program you need windows, which is 1GB (install footprint) using 100+MB (boot up memory utilization) and a consistent and significant CPU overhead. I'm not bashing Windows (or other bloated desktop OS's like Mac OSX and various Linuxes) -- I think it's an acceptable trade-off.

    So for little programs that need to start up, run for a thousandth of a second, then die, Java is a poor fit (today, and probably for some time to come.)

    Anjan: b) The CPU time(and memory) required for running the HOTSPOT compiler.

    Other than the slower start-up, I haven't seen any CPU issues there. Yes, it definitely uses CPU, but (a) that gets used in bits over time and (b) that cost is paid for many times over by the optimizations (unless the program only runs for a very short period of time.)

    Anjan: c) The overheads of using the GC.

    This is one of the areas with the widest variance. You can have .5GB heaps now with no noticeable pause for GC whatsoever, if tuned correctly, etc.

    The problem is that you should not have to tune the GC .. it should figure that out, just like Hotspot figures out what to optimize. It's getting there, though.

    As for the GC cost, it doesn't seem to be any worse than the sum of the free() costs in C, and malloc() (in Java, new) is often implemented very efficiently as the result of GC being the model.

    Anjan: d) No EASY way to reduce/replace the runtime library.

    True. I think that's purposeful ;-)

    Anjan: Other disadvantages of java include inability to change file attributes.

    Surprising if true, but well beyond my area of expertise.

    Anjan: (I've been doing mostly Java for more than 4 years. Previously, I did a lot of Systems Programming using C++/C/ASM.)

    I liked Java immediately when I first used it. It was exactly what C++ should have been ;-)

    So just like B.S. used to say that C++ is just a better C, I say that Java is a better C++.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  27. impossible ??[ Go to top ]

    It seems that the argument you're using is "I have a theory, so we need not bother to look at the facts."

    It really doesn't matter whether your theory is right or not. If the Java implementation is outperforming the C implementation on one of these microbenchmarks, no amount of your theorizing is going to make it slower.
  28. impossible ??[ Go to top ]

    It seems that the argument you're using is "I have a theory, so we need not bother to look at the facts."It really doesn't matter whether your theory is right or not. If the Java implementation is outperforming the C implementation on one of these microbenchmarks, no amount of your theorizing is going to make it slower.
    I think when u benchmark u dont think of one or two specific cases. then u become a marketing king not a techy. So when u say that someone can make a java program run faster than anyhting else in the world , - yeah sure why not - but not always. that why i put my thoughts in the thread. Thinking of a general use of java and the way its been used most widely what do u think ? may be u can run a hello world faster in java compared to c ++ but then what good is ths result - and is it worth calling a bench mark.
    I m not trying to argue here on a theory - we are talking about a language - computers which use electircity to run and show results. we know how it works and that why the statement. and nor do want to extend the thread anymore. i have huge objection against these small scale specific case kind of bench marking. i m sure not all will agree. doesnt matter :).
  29. These results are interesting but it's important not to read more into
    them than they are really telling us. Many of the caveats that must
    be noted are exactly the same as the ones that applied to the "How
    fast is Lisp?" issue over twenty years ago: plus ca change, plus
    c'est la meme chose:

    -- Microbenchmarks are often not good predictors of the performance of
       serious, large programs. Also, the performance of programs run
       in benchmark situations is often quite different from their
       performance in real situations. For example, in real life they
       may be competing for resources with other programs running at
       the same time.

    -- When you translate a benchmark from one language to another, you
       make a lot of decisions. For example, strings in C and C++ are
       very different from String's and StringBuffer's in Java, and
       notice that one benchmark was fixed to avoid silly over-allocation
       of StringBuffer objects. So is the benchmark measuring the
       langauge or the quality of the coding ability of the translator?

    -- There are many implementations of each language running around, so
       is the benchmark measuring the langauge or the implementation?
       I have seen benchmarks saying that code produced by Intel's best
       compilers significantly outperform GCC. My own personal
       experience is that BEA's JRockit way outperforms Sun's JVM on
       every case I've tried.

    These are very hard problems to solve. They're not just technical
    problems, but problems with the very definition of what a benchmark is
    really supposed to be.

    Of course, what everybody wants is the magic number X, for which we
    can say "If it's written in Java it will run in X times the time that
    it would have run had it been written in C++." But for all these
    reasons, there's no such thing as this magic number.

    As always, some people say that performance doesn't matter anyway,
    because what really matters is development time. Maybe I'm being
    unfair, but I suspect that the people saying this are developers,
    rather than customers receiving the final product. Let me put it this
    way: when I buy a new car, what I care about is its milage,
    acceleration, safety test result, etc. Sure, had it taken longer to
    design I might not have even had the chance to buy it, but hearing
    that the designers of the car had a CAD system that let them design
    faster is not going to influence my purchasing decision.

    On the other hand, sometimes even when runtime performance is utterly
    critial, the decision whether to write an application in C/C++ versus
    Java makes no difference, because very little of the actual time is
    being spent executing the lines of code of the application. Time
    might be spent in runtime libraries (which, in the Java case, could be
    "native"), waiting for the file system, in database management
    systems, in waiting for an SAP or PeopleSoft back-end system, in
    waiting for some really overloaded Web server, etc.

    So these results aren't meaningless or valueless, but their meaning
    and value should not be overestimated either.
  30. But why do I make this stupid question? I already know the answer. The Java guys is infamous for "not seeing the forest because of all the trees".

    It is not necessary with any complicated procedure to lay down which language is faster. Just as I quite accurately can estimate the performance of a computer just by open Word and/or Excel and play around with it a couple of minutes, in the same way the "performance quality" of a language will emerge as soon as you open and use a desktop application made by it. Most people don't realize how much incredible amount of work is needed for a GUI Windows/Linux application to work.

    So in this unscientific way I notice the C is fastest, C++ is no 2, Java/SWT no 3, and Java no 4. The reason that Java/SWT is faster is of course because it "cheats" by using C behind the scenes. C# is similar to Java/SWT for the same reason.

    Most serious providers of benchmarks put in disclaimers, warning to take results with a grain of salt, and indeed it are difficult to make fair and just performance benchmarks.

    Nevertheless, The Great Win32 Computer Language Shootout is the most serious, ambitious and extensive comparison between programming languages I have seen, and the results confirms exactly the "manual" observations. So IMO, this discussion is dead.

    Of course there is another problem for Java, its broken memory model. Java always needs much more memory to achieve the same speed as C# and that creates a whole nest of other problems.

    But that is another chapter.

    Regards
    Rolf Tollerud
  31. Using word / excel is equal to using OpenOffice with one significant diffrence , you have OpenOffice everywhere for free but
    you should pay to use Ms Office in one platform.



    In enterprise managers and developers dont mind about a few second delay in starting an application
    indeed they think about time to market and stability , extedability of aplications
    not about c# use less memory than java or Plain old C operate faster on math calculation and
    less useable string manipulation.
    -if some day in mythic we have VS.Net running on linux ,BSDs,AIX,... and used less memory than websphere / eclipse then you

    talk about memory footprint and memory managing-

    The importance in enterprise is

    1-Time to Market : java do it in the best way , there are alot of opensource frameworks, librarys, tools ,...with high quality wich

    can be used in developing applications in the shortest time and lesser price.

    2-extendablility : java do it in the best way its interface base rather than concret class base , SDKs like Eclipse are available wich

    you can use them as a stable base for extendable large scale appllications.

    3-technical support : Ask IBM for all kind of technical support for Websphere / Oracle for Oracle AS ...

    4-Security , reliability : just think about what is going on windows its Worms home ? maybe a safe heaven for worm developer to

    test what they done. .NET will be like other Microst Stuffs are

    5..
    6..

    Masoud Kalali
  32. The reason that Java/SWT is faster is of course because it "cheats" by using C behind the scenes.
    Have you talked lately to someone that is using SWT on Linux ? No. You bothered to test it yourself ? No. Because than you would know how much it sux. So it's obvious that once again you don't know the truth, you know "your" truth. You know SWT uses native support to render it's widgets thus it must be faster that swing. You know that Java is build upon whatever C even ++ thus it should be slower. But benchmarks tell you otherwise. Also practice and testing tells otherwise.

    But you're not interested in that. Continue to blame the Java "guys" for what stupid behavior they have, and cry for somewone to port some Java marvels to your .NET (aka Spring) instead doing it yourself or at least contributing, and cry how idiots we are while using "the big J2EE container" while you prise Resin. In the meantime Java and it's community goes ahead and you remain with your lame "self". hah.
  33. Dorel: In the meantime Java and it's community goes ahead

    Is that so? I invite you to try "Whidbey".

    I know nothing about Java/SWT on Linux. As far as I know the majority of Java programmers develops on Windows and deploy on Unix/Linux, like Cameron.

    Is there someone else that can cast some light on the SWT implementation on Linux and ev. why it is so lousy?

    Regards
    Rolf Tollerud
  34. shrug
  35. I am looking forward to your next post! :)
  36. Dorel,

    I'll give you a tip!

    Goto Excelsior JET Solutions. They have a Java/SWT compiler that generates runtimes as small as 1-2 MB in size. Apps compiled with Excelsior starts on one(1) second and run as fast as C++.

    It will only take you 2 minutes to go to their site and try the demo application. It comes in a zip file that contains only the .exe and a 272K runtime dll. Nothing else is installed. The JRE is not needed.

    C# too have a native compiler (Remotesoft's Salamander), but the smallest runtime will be at least 10MB!

    Regards
    Rolf Tollerud
  37. Dorel, I'll give you a tip!Goto Excelsior JET Solutions. They have a Java/SWT compiler that generates runtimes as small as 1-2 MB in size. Apps compiled with Excelsior starts on one(1) second and run as fast as C++. It will only take you 2 minutes to go to their site and try the demo application. It comes in a zip file that contains only the .exe and a 272K runtime dll. Nothing else is installed. The JRE is not needed.C# too have a native compiler (Remotesoft's Salamander), but the smallest runtime will be at least 10MB!RegardsRolf Tollerud
    I think I missed your point in this post, since Dorel was talking about running SWT in Linux, and this tool helps nothing in this regard. Care to explain?
  38. Excelsior for Linux[ Go to top ]

    JET 3.6 Release Candidate 2 for Linux
  39. Maybe you wonder why it is not possible to compile to native exe with Swing? The answer is that it is indeed possible and only ship the windows dlls with the application. But unfortunately there is a great but: Sun does not allow it, if you ship the windows dlls you have to ship the whole JRE (even if you don't use it), defeating the whole purpose. :(

    What can be the rationale behind Sun's behavior?

    I do not know but,
    Never attribute to malice that which can be adequately explained by stupidity. -Hanlon's Razor
  40. First of all I'm a JAVA developer but I have a note to add about the C code.
    Let's take the matrix example: you're not creating a matrix that way in a dynamic manner only if you want to make it slow :).

    In the original code because the memory allocation is in a for cycle (row by row) it makes it slower, and even more the rows of the matrix can be everywhere in the memory - not in a compact block. You should allocate once - that will ensure a compact memory block.
    This will speed up a little bit the C code. Once again, micro benchmark doesn't prove anything...
    M.
  41. Unfortunately, Java applications and applets run by default in the client VM," Lea observes. "The Server VM is much faster than the Client VM, but it has the downside of taking around 10% longer to start up, and it uses more memory.
    I absolutely disagree with this point of view. The main feature of server VM is minimal/acceptable "stop-the-world" GC pauses, so the response time is more stable. Server VM mode decreases performance for typical algorithm problems, especially single threaded. I'd better recommend to use client VM mode with -XX:+AggressiveHeap and parallel GC for algorithms benchmarks.

    Regards,
    Theodore Kupolov
  42. Oh come on[ Go to top ]

    What possible outcome can be got from these sort of benchmarks? The decision to use C++ or Java will never be made on the basis of speed alone.

    I dont see any reason why people would just carry out these benchmarks just because they were 'sick of hearing that java was slow'!

    Best solution for your project, based on relative factors in the decisin making process....worthless benchmarks are of no use to any of us.
  43. Why why why??[ Go to top ]

    "Most serious providers of benchmarks put in disclaimers, warning to take results with a grain of salt, and indeed it are difficult to make fair and just performance benchmarks."


    So why do we need them, if the people running these benchmarks wont even be bound by their findings...waste of time!!
  44. Oh come on[ Go to top ]

    What possible outcome can be got from these sort of benchmarks? The decision to use C++ or Java will never be made on the basis of speed alone.I dont see any reason why people would just carry out these benchmarks just because they were 'sick of hearing that java was slow'!Best solution for your project, based on relative factors in the decisin making process....worthless benchmarks are of no use to any of us.
    Agreed. I just wanted to say that author of this particular benchmark explains problems easier then they are. As for me I never worried about java being faster than C++ (or vice versa). I realize that Java/J2EE increases my productivity and fits the needs of the most projects I participated in.
  45. Most balanced analysis[ Go to top ]

    This is one of the most balanced analysis of the shootout I've read so far. Since google groups has not yet started displaying this thread over at comp.lang.c++.moderated (I was able to get it out of my news reader), I am copying it verbatim here:

    glenlow at pixelglow dot com (Glen Low) wrote in message
    news:<9215d7ac dot 0406151559 dot 2b45e595 at posting dot google dot com>...
     > Another Java vs C++ performance shootout:

     > http://kano.net/javabench/

     > Anyone care to comment about the appropriateness of his C++ code and
     > compiler settings?

    When I'm benchmarking for speed, I use -O3 with g++, not -O2. That's
    definitly an error on his part.

    I glanced at a few of the tests. For the most part, they are pretty low
    level; it's hard to say what significance they have with regards to real
    code.

    The hash code tests actually test how good the hashing function is. The
    default algorithm used by g++ is definitly bad for large numbers of
    short strings (it will cluster near the front of the table), but I've
    not done enough analysis to be able to say exactly what is too large or
    too short.

    It would be interesting to see what happens with more complex data
    structures, like std::vector (and push_back) vs. java.util.Vector. Java
    has a decided advantage in array handling, because of the absense of
    aliasing. As soon as you use any data structure other than an Array of a
    built-in type, however, you need to dynamically allocate each element in
    the structure. Relocating garbage collection generally results in much
    faster allocation than you can get with operator new in C++, but even
    the fastest allocation can't compete with no allocation.

    Note too that while garbage collection allocation is typically much
    faster than manual allocation (perhaps an order of magnitude or so),
    this is partitially offset by the time you spend collecting. His
    programs allocate little enough that he probably never needs to collect.

    The small size of the programs are a definite advantage for Java's
    runtime optimizer. A run-time optimizer can't spend forever optimizing,
    but it has access to actual run-time data, AND can specialize its
    optimization for the specific processor. (G++, and most other C++
    compilers, have flags to allow this as well.) Given the small size, a
    complete analysis of the program is possible in the limited time
    available, and given the other additional data, I would find it rather
    worrisome if Java didn't do better. I'm more sceptical with regards to
    real programs, however. If there really is one small critical loop,
    Java should win; that's not the case for most of my programs, however.

    And of course, g++ is far (very far) from state of the art optimizing,
    especially (so I've been told) for Intel architectures.

    All that said, however, for many applications, there will be little or
    no difference in speed between Java and C++. Java has a number of
    advantages which make life easier for the optimizer, and for most
    applications, garbage collection will be faster than manual memory
    management, but the fact that everything has to be dynamically allocated
    can cost a lot.

    In the end, of course, performance isn't necessarily the key argument.
    For most of the work I do, safety is. And that is a criteria where C++
    is a clear winner; it is very, very difficult to write correct programs
    of any significant size in Java. (It's not really that easy in C++, but
    at least the language never actively prevents you from doing the right
    thing.)

    --
    James Kanze GABI Software
    Conseils en informatique orient&#65533;e objet/
                        Beratung in objektorientierter Datenverarbeitung
    9 place S&#65533;mard, 78210 St.-Cyr-l'&#65533;cole, France, +33 (0)1 30 23 00 34

          [ See http://www.gotw.ca/resources/clcm.htm for info about ]
          [ comp.lang.c++.moderated. First time posters: Do this! ]
  46. Most balanced analysis[ Go to top ]

    In the end, of course, performance isn't necessarily the key argument.
    For most of the work I do, safety is. And that is a criteria where C++
    is a clear winner; it is very, very difficult to write correct programs
    of any significant size in Java. (It's not really that easy in C++, but
    at least the language never actively prevents you from doing the right
    thing.)
    Eh?
  47. Most balanced analysis[ Go to top ]

    "(It's not really that easy in C++, but
    at least the language never actively prevents you from doing the right
    thing.)"

    So what in Java prevents you from doing the right thing?
  48. Most balanced analysis[ Go to top ]

    "(It's not really that easy in C++, butat least the language never actively prevents you from doing the rightthing.)"So what in Java prevents you from doing the right thing?
    You guys should really scoot over to comp.lang.c++.moderated at http://tinyurl.com/yw9aj
    and ask your questions there. I am sure you will find the original author of that post (James Kanze) a lot more knowledgeable than you guys seem to be giving credit him for.. (like that Nick Minutello "Eh?" post for example..)
  49. Blast from the past[ Go to top ]

    "(It's not really that easy in C++, butat least the language never actively prevents you from doing the rightthing.)"So what in Java prevents you from doing the right thing?
    You guys should really scoot over to comp.lang.c++.moderated at http://tinyurl.com/yw9ajand ask your questions there. I am sure you will find the original author of that post (James Kanze) a lot more knowledgeable than you guys seem to be giving credit him for.. (like that Nick Minutello "Eh?" post for example..)
    I actually know James Kanze from the days when we were both on the C++ committee and I can vouch for him as a smart and objective individual. It was actually quite funny to see he authored this very balanced post. Some things never change.

    --
    Cedric
  50. Blast from the past[ Go to top ]

    I actually know James Kanze from the days when we were both on the C++ committee and I can vouch for him as a smart and objective individual.
    I suspected as much. Being from France and all you guys should've bumped into each onetime or the other.
    It was actually quite funny to see he authored this very balanced post. Some things never change.-- Cedric
    OK. I am just curious here -- why is it funny that he "authored this very balanced post"? Looking at most of the posts he has made in the past few years he does seem to have more than a passing knowledge of Java?
  51. Blast from the past[ Go to top ]

    Dilip - I'm as confused as you are: Was that sincerity or sarcasm?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  52. J2EE or RDBMS?[ Go to top ]

    Smile!

    Why can't we compare Oracle9i Database and WebLogic 8 SP2 AS?

    Why not?

    A lot of commercial software companies try to avoid dependance on underlaying database, they don't want to use stored procedures, packages, embedded optimization routines, they don't want to use even TYPE 2 JDBC! They use "Dynamic SQL" as a dynamically generated String object in Java! And don't forget about
    "WHERE LTRIM(RTRIM(...)) = "+firstName
    - I saw a lot of such universally stupid staff.

    But some of them make good profit, and it is the best benchmark.
  53. The real result. Give a look![ Go to top ]

    First I would like to say that when I read this article a had a laugh crisis.

    I downloaded the code you used on your analysis and java is clearly slower than C++.
    Only your method-call was tested.


    Give a look on this terminal out:

    henrique@swap:~/Desktop/download/bench/javabench/bin/cpp/i386> time ./methcall-3 false
    true

    real 0m0.004s
    user 0m0.001s
    sys 0m0.003s
    henrique@swap:~/Desktop/download/bench/javabench/bin/cpp/i386> cd ../../java/
    henrique@swap:~/Desktop/download/bench/javabench/bin/java> time java methcall 1
    false
    true

    real 0m0.128s
    user 0m0.115s
    sys 0m0.009s
    henrique@swap:~/Desktop/download/bench/javabench/bin/java>
  54. The real result. Give a look![ Go to top ]

    Bruno,

    You forgot to include the time that it took the operating system to boot and shut-down. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  55. Smile!

    How to compare speed/performance of a language?

    Do not forget about Machine, including underlaying services such as OS, Messaging, DBMS, etc!

    What about C++ for Windows NT, for instance? In fact, it runs in a Virtual environment provided by OS, and OS runs without any recompiling on almost any CPU, it runs in a Virtual Machine! (it needs to change "hardware" layer only)

    So, how to compare Languages?
  56. Just to muddy the waters a little bit here is an attempt at cleaning up the original posters C++ code.
    http://cpp.student.utwente.nl/benchmark/
  57. Hi Dilip,

    That post doesn't muddy the waters .. in fact, it's impressive that hand-optimized C++ doesn't win much more often. If developers knew that Java were on average anywhere near as fast as C++, Java would have passed C++ in popularity. ;-)

    All kidding aside, anyone who would code in C++ today when they could do it in Java (as usual, I am including C# in Java) is a lunatic. I am personally at least 10x as productive in Java as I was in C++, and back then I actually coded for a living (i.e. I was coding all the time.) Other than as a replacement for C, which I think it is good as, C++ has no reason to exist anymore.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  58. "I am personally at least 10x as productive in Java as I was in C++"

    Does this include the time to target different OSs? Or the time to do things that are a part of the Java platform and not in the C++ standard 'platform'?

    Or are you saying that you are 10x more in general?

    If the latter I would have to conclude that you were/are unaware of the many thinga in C++ that are not in Java.

    I agree in general that Java has a good platform on which to build certain types of applications/service but as a language it is a far cry from C++.
  59. Productivity[ Go to top ]

    Sartoris: Does this include the time to target different OSs?

    Yes. It used to be hard to even support different versions of Windows with C++. That was as much the Windows API's fault as it was something to do with the language, unless you consider that you had to use the Windows API for a lot of things because the standard libraries for the language were so primitive and incomplete. In the Windows case, you often had to use MFC as a class library, or the Windows "C" API directly, or some proprietary third-party framework.

    Sartoris: Or the time to do things that are a part of the Java platform and not in the C++ standard 'platform'?

    Yes, that too, but remember that I'm comparing Java with an older view of C++. When we switched over to using primarily Java, we saw the promise in Java and had largely given up hope that C++ would ever advance at more than a snail's pace.

    Sartoris: If the latter I would have to conclude that you were/are unaware of the many thinga in C++ that are not in Java.

    I'm not terribly interested in things that _are_ in C++ today; my own decision was based on what was actually available at the time, and it basically sucked if you were building apps in C++. The fact that I never had to go back to C++ is also a pretty good indicator to me of how complete Java is (or was or has become or something. ;-)

    Sartoris: I agree in general that Java has a good platform on which to build certain types of applications/service but as a language it is a far cry from C++.

    It's not a one-size-fits-all world. I'd like to see the next VB or PB (whatever that is) take the place of a lot of the business programming that is done in Java today. Java, like C++, is not a natural language for doing business programming, despite the fact that most big business apps are being built in Java now, just like (for some insane reason) people used to build business apps in C++.

    IMHO Device drivers and operating systems and truly time-sensitive things like the real-time parts of 3d games remain the sole purvey of C/C++. Beyond that, the cost per working LOC or per completed project is just too high to warrant the use of those languages.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  60. Productivity[ Go to top ]

    Cameron:Yes. It used to be hard to even support different versions of Windows with C++. That was as much the Windows API's fault as it was something to do with the language, unless you consider that you had to use the Windows API for a lot of things because the standard libraries for the language were so primitive and incomplete. In the Windows case, you often had to use MFC as a class library, or the Windows "C" API directly, or some proprietary third-party framework.
    Helloo..? I have used MFC extensively. You can start an argument on the way OO methodology was used to wrap Win32 APIs in MFC but in what way were they "primitive" or "incomplete"?
  61. Productivity[ Go to top ]

    Slow down Dilip ;-)

    MFC is not a standard C++ library .. it's a Microsoft library that had to exist because to do C++ in Windows (and Windows only) they needed some sort of library!

    MFC was relatively good (depending on which major re-write we're talking about -- but I personally learned quite a bit about Windows internals just from reading the MFC sources.) However, imagine Java without a .util and .sql and .awt and [so-on] package .. and that is what C++ was without MFC. I couldn't take a C++ application from Windows that used MFC and use it anywhere else, not even older versions of Windows (sometimes.)

    Anyhow, I'm not deriding MFC, although it does have its own set of detractors. I'm talking about C++, and the fact that it didn't have any of that functionality standardized, and Java does.

    Hope that makes more sense ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  62. Java with SWT and static compiler is certainly fast enough, what if Sun had done that, and left it to ISO too. The real value of languages like Java and C# is their standard libraries. As long as you can count on the same libraries on all platforms, you don't mind recompiling.

    Regards
    Rolf Tollerud
  63. Productivity[ Go to top ]

    Cameron,

    Your comments are quite misleading. While it is true that the C++ standard was deliberately kept light, you could always use proprietary libraries (commercial and open source) to fill the gap (RogueWave, ACE, USL, ObjectSpace many more specialized ones etc.). If you had made appropriate use of the available IDEs, libraries, and frameworks, I would be surprised how your productivity would be so low (compared with Java) unless you were a novice programmer at that time. E.g. I can't think of anything as powerful or elegant as STL in the Java world.

    I believe C++ that came out of the ANSI/ISO committee was very well designed language. While it is more complex (and powerful/flexible) than Java, it is not as complex as is made out to be. I suspect that the perception has a lot to do with the rabid anti-C++ campaigning by Sun and others in the early days of Java. So much so, it has become fashionable to criticize C++ without any substance (particularly for those Java programmers who like to parrot propaganda despite little or no C++ experience).

    Having said that, I feel that the C++ community would have been better served with more of best practices/blueprints (similar to what exists in the Java world) instead of highlighting complex/obfuscated coding. Also, the C++ standard was kept lean and focused on general purpose building blocks. In retrospect, that was a mistake (BS has acknowledged as much) and is being fixed, albeit belatedly, in the upcoming 200x standard.

    Regards,
    Kalyan
    Sartoris: Does this include the time to target different OSs?Yes. It used to be hard to even support different versions of Windows with C++. That was as much the Windows API's fault as it was something to do with the language, unless you consider that you had to use the Windows API for a lot of things because the standard libraries for the language were so primitive and incomplete. In the Windows case, you often had to use MFC as a class library, or the Windows "C" API directly, or some proprietary third-party framework.Sartoris: Or the time to do things that are a part of the Java platform and not in the C++ standard 'platform'?Yes, that too, but remember that I'm comparing Java with an older view of C++. When we switched over to using primarily Java, we saw the promise in Java and had largely given up hope that C++ would ever advance at more than a snail's pace.Sartoris: If the latter I would have to conclude that you were/are unaware of the many thinga in C++ that are not in Java.I'm not terribly interested in things that _are_ in C++ today; my own decision was based on what was actually available at the time, and it basically sucked if you were building apps in C++. The fact that I never had to go back to C++ is also a pretty good indicator to me of how complete Java is (or was or has become or something. ;-)Sartoris: I agree in general that Java has a good platform on which to build certain types of applications/service but as a language it is a far cry from C++.It's not a one-size-fits-all world. I'd like to see the next VB or PB (whatever that is) take the place of a lot of the business programming that is done in Java today. Java, like C++, is not a natural language for doing business programming, despite the fact that most big business apps are being built in Java now, just like (for some insane reason) people used to build business apps in C++.IMHO Device drivers and operating systems and truly time-sensitive things like the real-time parts of 3d games remain the sole purvey of C/C++. Beyond that, the cost per working LOC or per completed project is just too high to warrant the use of those languages.Peace,Cameron PurdyTangosol, Inc.Coherence: Clustered JCache for Grid Computing!
  64. Productivity[ Go to top ]

    Kalyan: Your comments are quite misleading. While it is true that the C++ standard was deliberately kept light, you could always use proprietary libraries (commercial and open source) to fill the gap (RogueWave, ACE, USL, ObjectSpace many more specialized ones etc.). If you had made appropriate use of the available IDEs, libraries, and frameworks, I would be surprised how your productivity would be so low (compared with Java) unless you were a novice programmer at that time. E.g. I can't think of anything as powerful or elegant as STL in the Java world.

    Interesting points. I'm certain if C++ seems an obvious first choice of language to you, then by comparison I must be a novice. I first learned C++ as "a better C" (as B.S. is fond of saying) and later learned the OO aspects of C++, including building a few class libraries and using a couple of the ones that you mention.

    I always knew that C++ wasn't quite right, kind of like that feeling you get when you think about the crazy old lady down the street that would yell at you if you so much as stepped on her lawn. It wasn't obvious to me what was "wrong" (in quotes, because it's really "what's not quite right") with C++ until I started using Java. Then I realized that Java was all the benefits of the OO part of C++, but without the C cruft.

    While C++ has since evolved (both the standard as well as various implementations and libraries) to be much more Java-like, it's still C++ under there, and it still has all of the problems and limitations that it inherited from C. Frankly, once you work in Java for a while, you will wonder how you ever did anything in C or C++. (That's my experience, anyway.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  65. Productivity[ Go to top ]

    Cameron,Your comments are quite misleading. While it is true that the C++ standard was deliberately kept light, you could always use proprietary libraries (commercial and open source) to fill the gap (RogueWave, ACE, USL, ObjectSpace many more specialized ones etc.). If you had made appropriate use of the available IDEs, libraries, and frameworks, I would be surprised how your productivity would be so low (compared with Java) unless you were a novice programmer at that time. E.g. I can't think of anything as powerful or elegant as STL in the Java world.
    I agree. I have seen the development of the STL over the years and the end result was quite amazing in elegance and power.
    I believe C++ that came out of the ANSI/ISO committee was very well designed language.
    Agreed again but I would add something to your sentence: "C++ was very well designed within the constraints that were set on it".

    The main problem with C++ which explains the poor shape it eventually reached is that backward compatibility was among the top priorities. The number of compromises that were made in that name are numerous.

    The Java creators should be commanded for coming up with such a nice language, but we must keep in mind that it's much easier to design a language when you can start absolutely from scratch.

    --
    Cedric
    http://beust.com/weblog
  66. It is almost as you have convinced yourself that Just In Time Compiled Java is really as fast as C++. How come then that thousands of C++ successful shrink-wrapped desktop applications exist, but no Java ones except some IDEs that demands a smaller nuclear power station to run?

    How come those applications compiled with Excelsior Jet feels so fast and snappy when the benchmarks show little or no difference?
    I can think of no other explication that memory management.

    But whatever it is, a C++ desktop application beats Java hands down.

    Regards
    Rolf Tollerud
  67. Stupid is stupid does[ Go to top ]

    Some cool java client apps

    http://www.thinkfree.com/products/pd_office20.jsp ..better than M$ office :)
    http://azureus.sourceforge.net/screenshots_v2.php Java bittorent client
    http://eclipse.org/
    http://www.evermoresw.com/weben/index.jsp another M$ office killer :)
    http://www.goes.noaa.gov/GSSLOOPS/ecir.html weather reports running on applets

    There are tons more. Due M$ mischief of monoply we could jave seen more Java clients but now that Linux Desktops such as JDS, Mandrake , Suse desktops are taking market share we will see more Java Client apps.

    http://www.eweek.com/article2/0,1759,1614767,00.asp
    http://www.linuxinsider.com/story/34625.html


     There are lot of java client apps in Handheld devices since it is not in M$ monopoly.

    enjoy :)
  68. But whatever it is, a C++ desktop application beats Java hands down.
    How about when comes about productivity ? Better expect customers to buy 256M RAM (they must do that anyways if they want to run the wonderful Windows on it) than build a big desktop app in c++.

    However I won't start another Java vs C++ dog bullshit here. My point all along was/is that you are not allways best informed when you make an opinion. And you are allways strongly bised towards cXX and against Java. Do you earn something from bashing Java and it's community with everything that seems appropriate ? Or you are doing it for fun ?

    Now think how much has Java came along. Just think. From some little applets to an enterprise platform. Why's that ? Because some people realized that programming doesn't all the time mean extreme speed but sometimes better productivity ? And definately fulfilling customer's needs ? Your "against Java" rants are completely pointless. However I don't have anything against criticism as long as it well backed up with facts. Good criticism is constructive. But it seems that's what you miss facts all the time.
  69. best environment today[ Go to top ]

    Dorel: How about when comes about productivity ?

    Of course Java beats C++ hands down when it comes to productivity. Nobody says otherwise. But this thread is about speed. In any case productivity is something you care about in contract programming. If you shall publish a product, you better take the time that is needed to get it right. Quality takes time and patience in our field as elsewhere in art and life.

    are you are doing it for fun?

    Yes, but I also think I am a little useful. Left for yourself you disappear up in the sky among the clouds somewhere. If I was such a zealot as you seem to hint, why is it then that I say:

    "The best environment for desktop application development at the moment is Eclipse/SWT with the Excelsior compiler".

    Regards
    Rolf Tollerud
  70. 5 000 000 dowloads[ Go to top ]

    Azureus - Java BitTorrent Client just reached 5 000 000 dowloads milestone.
    http://azureus.sourceforge.net/changelog_v2.php

    Based on SWT of course.
  71. P.S.[ Go to top ]

    Azureus - Java BitTorrent Client (based on SWT) just reached 5 000 000 dowloads milestone.

    http://azureus.sourceforge.net/changelog_v2.php

    Based on SWT of course.