667481 members! Sign up to stay informed.

Sponsored Links


Resources

Enterprise Java
Research Library

Get Java white papers, product information, case studies and webcasts

News News News Messages: 70 Messages: 70 Messages: 70 Printer friendly Printer friendly Printer friendly Post reply Post reply Post reply XML XML XML

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

Posted by: Dion Almaer on June 16, 2004 DIGG
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 replies

·  Yet Another Benchmark: Claims of Java being faster than C++ by Dion Almaer on Wed Jun 16 09:55:35 EDT 2004
  ·  Interesting but... by Michael Brewer on Wed Jun 16 10:17:24 EDT 2004
    ·  Interesting but... by Stephane TRAUMAT on Wed Jun 16 10:29:19 EDT 2004
      ·  Interesting but... by Guglielmo Lichtner on Wed Jun 16 10:32:43 EDT 2004
      ·  Interesting but... by Rashid Jilani on Wed Jun 16 16:38:36 EDT 2004
    ·  Method Call test by Archimedes Trajano on Wed Jun 16 10:38:14 EDT 2004
    ·  Interesting but... by Dimitri Rakitine on Wed Jun 16 12:07:04 EDT 2004
      ·  Interesting but... Ninja anyone by Suhail M. Ahmed on Wed Jun 16 14:38:25 EDT 2004
        ·  Interesting but... Ninja anyone by Ruslan Zenin on Wed Jun 16 21:24:51 EDT 2004
          ·  Interesting but... Ninja anyone by Suhail M. Ahmed on Thu Jun 17 02:36:07 EDT 2004
    ·  Interesting but... by David Jones on Wed Jun 16 13:01:58 EDT 2004
    ·  A call for new benchmarks by Alejandro Dobniewski on Wed Jun 16 13:35:47 EDT 2004
      ·  C++ 101 by Ted Zlat on Wed Jun 16 13:48:35 EDT 2004
  ·  If you read this article - You must read the feedback. by Mario C on Wed Jun 16 11:04:36 EDT 2004
  ·  Isn't this just a joke? by Aaron Evans on Wed Jun 16 13:19:54 EDT 2004
  ·  Zzzzz! by John Davies on Wed Jun 16 13:44:53 EDT 2004
  ·  Don't bash the author by Mike Miller on Wed Jun 16 14:08:26 EDT 2004
  ·  impossible ?? by shawn spencer on Wed Jun 16 14:23:49 EDT 2004
    ·  impossible ?? by Juozas Baliuka on Wed Jun 16 14:50:55 EDT 2004
    ·  impossible ?? by Jay Sissom on Wed Jun 16 16:02:43 EDT 2004
    ·  sour grapes by Cameron Purdy on Wed Jun 16 16:35:24 EDT 2004
      ·  sour grapes by shawn spencer on Wed Jun 16 17:17:58 EDT 2004
        ·  sour grapes ;-) by Cameron Purdy on Wed Jun 16 17:48:54 EDT 2004
          ·  sour grapes ;-) by Daniel Weinreb on Thu Jun 17 00:13:32 EDT 2004
      ·  sour grapes by Anjan Bacchu on Wed Jun 16 18:47:00 EDT 2004
        ·  sour grapes by Cameron Purdy on Wed Jun 16 22:33:41 EDT 2004
    ·  impossible ?? by Daniel Weinreb on Thu Jun 17 00:08:48 EDT 2004
      ·  impossible ?? by sean decor on Thu Jun 17 01:48:19 EDT 2004
  ·  Yet Another Benchmark: Claims of Java being faster than C++ by Daniel Weinreb on Thu Jun 17 00:06:36 EDT 2004
    ·  why make it more difficult than it is? by Rolf Tollerud on Thu Jun 17 03:14:09 EDT 2004
      ·  why make it more difficult than it is? by a b on Thu Jun 17 04:51:24 EDT 2004
      ·  why make it more difficult than it is? by Dorel Vaida on Thu Jun 17 07:05:05 EDT 2004
        ·  why make it more difficult than it is? by Rolf Tollerud on Thu Jun 17 07:21:46 EDT 2004
          ·  why make it more difficult than it is? by Dorel Vaida on Thu Jun 17 09:52:18 EDT 2004
            ·  why make it more difficult than it is? by Rolf Tollerud on Thu Jun 17 10:19:46 EDT 2004
        ·  just to show that I am no zealot by Rolf Tollerud on Thu Jun 17 12:54:53 EDT 2004
          ·  just to show that I am no zealot by Henrique Steckelberg on Thu Jun 17 14:55:12 EDT 2004
            ·  Excelsior for Linux by Rolf Tollerud on Thu Jun 17 15:18:23 EDT 2004
            ·  with friends like Sun you do not need enemies by Rolf Tollerud on Sun Jun 20 16:29:25 EDT 2004
    ·  Short notice about the code by Janos Zsolt MATYAS on Thu Jun 17 04:37:49 EDT 2004
  ·  Yet Another Benchmark: Claims of Java being faster than C++ by Fyodor Kupolov on Thu Jun 17 03:46:11 EDT 2004
    ·  Oh come on by D Johnson on Thu Jun 17 04:41:42 EDT 2004
      ·  Why why why?? by D Johnson on Thu Jun 17 04:44:12 EDT 2004
      ·  Oh come on by Fyodor Kupolov on Mon Jun 21 04:39:15 EDT 2004
  ·  Most balanced analysis by Dilip Ranganathan on Thu Jun 17 08:56:58 EDT 2004
    ·  Most balanced analysis by Nick Minutello on Thu Jun 17 11:40:41 EDT 2004
      ·  Most balanced analysis by David Jones on Thu Jun 17 13:05:16 EDT 2004
        ·  Most balanced analysis by Dilip Ranganathan on Thu Jun 17 15:21:31 EDT 2004
          ·  Blast from the past by Cedric Beust on Thu Jun 17 22:24:11 EDT 2004
            ·  Blast from the past by Dilip Ranganathan on Fri Jun 18 11:26:13 EDT 2004
              ·  Blast from the past by Cameron Purdy on Fri Jun 18 11:32:15 EDT 2004
  ·  J2EE or RDBMS? by Fuad Efendi on Thu Jun 17 10:03:21 EDT 2004
  ·  The real result. Give a look! by Bruno Vieira on Thu Jun 17 10:24:05 EDT 2004
    ·  The real result. Give a look! by Cameron Purdy on Thu Jun 17 11:01:48 EDT 2004
  ·  Language, or Machine? Everything is Virtual by Fuad Efendi on Thu Jun 17 16:19:38 EDT 2004
  ·  Yet Another Benchmark: Follow up by Stefan Brujin by Dilip Ranganathan on Fri Jun 18 13:29:01 EDT 2004
    ·  Yet Another Benchmark: Follow up by Stefan Brujin by Cameron Purdy on Fri Jun 18 14:39:37 EDT 2004
      ·  Yet Another Benchmark: Follow up by Stefan Brujin by Sartoris Snopes on Fri Jun 18 15:17:55 EDT 2004
        ·  Productivity by Cameron Purdy on Fri Jun 18 17:15:13 EDT 2004
          ·  Productivity by Dilip Ranganathan on Fri Jun 18 18:00:35 EDT 2004
            ·  Productivity by Cameron Purdy on Fri Jun 18 20:15:30 EDT 2004
              ·  there is no sadder than sentences that start with "what if" by Rolf Tollerud on Sat Jun 19 02:14:30 EDT 2004
          ·  Productivity by Kalyan Kolachala on Mon Jun 21 08:06:14 EDT 2004
            ·  Productivity by Cameron Purdy on Mon Jun 21 09:43:06 EDT 2004
            ·  Productivity by Cedric Beust on Mon Jun 21 12:51:20 EDT 2004
              ·  there is something wrong somewhere here by Rolf Tollerud on Mon Jun 21 13:56:45 EDT 2004
                ·  Stupid is stupid does by Jamie Schiner on Mon Jun 21 22:13:07 EDT 2004
                ·  there is something wrong somewhere here by Dorel Vaida on Thu Jun 24 07:38:08 EDT 2004
                  ·  best environment today by Rolf Tollerud on Thu Jun 24 14:23:54 EDT 2004
                    ·  5 000 000 dowloads by Rolf Tollerud on Thu Jun 24 17:17:35 EDT 2004
                    ·  P.S. by Rolf Tollerud on Thu Jun 24 17:19:01 EDT 2004
  Message #126170 Post reply Post reply Post reply Go to top Go to top Go to top

Interesting but...

Posted by: Michael Brewer on June 16, 2004 in response to Message #126158
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)

  Message #126177 Post reply Post reply Post reply Go to top Go to top Go to top

Interesting but...

Posted by: Stephane TRAUMAT on June 16, 2004 in response to Message #126170
I agree... one day of my work will always be more expensibe then 256 MB RAM.

  Message #126180 Post reply Post reply Post reply Go to top Go to top Go to top

Interesting but...

Posted by: Guglielmo Lichtner on June 16, 2004 in response to Message #126177
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.

  Message #126182 Post reply Post reply Post reply Go to top Go to top Go to top

Method Call test

Posted by: Archimedes Trajano on June 16, 2004 in response to Message #126170
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.

  Message #126189 Post reply Post reply Post reply Go to top Go to top Go to top

If you read this article - You must read the feedback.

Posted by: Mario C on June 16, 2004 in response to Message #126158
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...".

  Message #126206 Post reply Post reply Post reply Go to top Go to top Go to top

Interesting but...

Posted by: Dimitri Rakitine on June 16, 2004 in response to Message #126170
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.

  Message #126217 Post reply Post reply Post reply Go to top Go to top Go to top

Interesting but...

Posted by: David Jones on June 16, 2004 in response to Message #126170
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.

  Message #126223 Post reply Post reply Post reply Go to top Go to top Go to top

Isn't this just a joke?

Posted by: Aaron Evans on June 16, 2004 in response to Message #126158
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

  Message #126225 Post reply Post reply Post reply Go to top Go to top Go to top

A call for new benchmarks

Posted by: Alejandro Dobniewski on June 16, 2004 in response to Message #126170
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.

  Message #126228 Post reply Post reply Post reply Go to top Go to top Go to top

Zzzzz!

Posted by: John Davies on June 16, 2004 in response to Message #126158
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-

  Message #126231 Post reply Post reply Post reply Go to top Go to top Go to top

C++ 101

Posted by: Ted Zlat on June 16, 2004 in response to Message #126225
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 !

  Message #126237 Post reply Post reply Post reply Go to top Go to top Go to top

Don't bash the author

Posted by: Mike Miller on June 16, 2004 in response to Message #126158
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!

  Message #126243 Post reply Post reply Post reply Go to top Go to top Go to top

impossible ??

Posted by: shawn spencer on June 16, 2004 in response to Message #126158
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.

  Message #126244 Post reply Post reply Post reply Go to top Go to top Go to top

Interesting but... Ninja anyone

Posted by: Suhail M. Ahmed on June 16, 2004 in response to Message #126206
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.

  Message #126246 Post reply Post reply Post reply Go to top Go to top Go to top

impossible ??

Posted by: Juozas Baliuka on June 16, 2004 in response to Message #126243
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 ... .

  Message #126255 Post reply Post reply Post reply Go to top Go to top Go to top

impossible ??

Posted by: Jay Sissom on June 16, 2004 in response to Message #126243
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++.

  Message #126258 Post reply Post reply Post reply Go to top Go to top Go to top

sour grapes

Posted by: Cameron Purdy on June 16, 2004 in response to Message #126243
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!

  Message #126260 Post reply Post reply Post reply Go to top Go to top Go to top

Interesting but...

Posted by: Rashid Jilani on June 16, 2004 in response to Message #126177
<!--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..

  Message #126264 Post reply Post reply Post reply Go to top Go to top Go to top

sour grapes

Posted by: shawn spencer on June 16, 2004 in response to Message #126258
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 :)

  Message #126269 Post reply Post reply Post reply Go to top Go to top Go to top

sour grapes ;-)

Posted by: Cameron Purdy on June 16, 2004 in response to Message #126264
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!

  Message #126276 Post reply Post reply Post reply Go to top Go to top Go to top

sour grapes

Posted by: Anjan Bacchu on June 16, 2004 in response to Message #126258
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

  Message #126285 Post reply Post reply Post reply Go to top Go to top Go to top

Interesting but... Ninja anyone

Posted by: Ruslan Zenin on June 16, 2004 in response to Message #126244
Sounds really interesting! Thanks!

The only question is: Will it ever make into J2SE or J2EE?

  Message #126290 Post reply Post reply Post reply Go to top Go to top Go to top

sour grapes

Posted by: Cameron Purdy on June 16, 2004 in response to Message #126276
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!

  Message #126295 Post reply Post reply Post reply Go to top Go to top Go to top

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

Posted by: Daniel Weinreb on June 17, 2004 in response to Message #126158
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.

  Message #126296 Post reply Post reply Post reply Go to top Go to top Go to top

impossible ??

Posted by: Daniel Weinreb on June 17, 2004 in response to Message #126243
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.

  Message #126297 Post reply Post reply Post reply Go to top Go to top Go to top

sour grapes ;-)

Posted by: Daniel Weinreb on June 17, 2004 in response to Message #126269
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.

  Message #126307 Post reply Post reply Post reply Go to top Go to top Go to top

impossible ??

Posted by: sean decor on June 17, 2004 in response to Message #126296
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 :).

  Message #126310 Post reply Post reply Post reply Go to top Go to top Go to top

Interesting but... Ninja anyone

Posted by: Suhail M. Ahmed on June 17, 2004 in response to Message #126285
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 ;-)

  Message #126315 Post reply Post reply Post reply Go to top Go to top Go to top

why make it more difficult than it is?

Posted by: Rolf Tollerud on June 17, 2004 in response to Message #126295
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

  Message #126317 Post reply Post reply Post reply Go to top Go to top Go to top

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

Posted by: Fyodor Kupolov on June 17, 2004 in response to Message #126158
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

  Message #126320 Post reply Post reply Post reply Go to top Go to top Go to top

Short notice about the code

Posted by: Janos Zsolt MATYAS on June 17, 2004 in response to Message #126295
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.

  Message #126321 Post reply Post reply Post reply Go to top Go to top Go to top

Oh come on

Posted by: D Johnson on June 17, 2004 in response to Message #126317
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.

  Message #126322 Post reply Post reply Post reply Go to top Go to top Go to top

Why why why??

Posted by: D Johnson on June 17, 2004 in response to Message #126321
"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!!

  Message #126324 Post reply Post reply Post reply Go to top Go to top Go to top

why make it more difficult than it is?

Posted by: a b on June 17, 2004 in response to Message #126315
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

  Message #126339 Post reply Post reply Post reply Go to top Go to top Go to top

why make it more difficult than it is?

Posted by: Dorel Vaida on June 17, 2004 in response to Message #126315
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.

  Message #126340 Post reply Post reply Post reply Go to top Go to top Go to top

why make it more difficult than it is?

Posted by: Rolf Tollerud on June 17, 2004 in response to Message #126339
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

  Message #126354 Post reply Post reply Post reply Go to top Go to top Go to top

Most balanced analysis

Posted by: Dilip Ranganathan on June 17, 2004 in response to Message #126158
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@pixelglow.com (Glen Low) wrote in message
news:<9215d7ac.0406151559.2b45e595@posting.google.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! ]

  Message #126361 Post reply Post reply Post reply Go to top Go to top Go to top

why make it more difficult than it is?

Posted by: Dorel Vaida on June 17, 2004 in response to Message #126340
shrug

  Message #126365 Post reply Post reply Post reply Go to top Go to top Go to top

J2EE or RDBMS?

Posted by: Fuad Efendi on June 17, 2004 in response to Message #126158
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.

  Message #126369 Post reply Post reply Post reply Go to top Go to top Go to top

why make it more difficult than it is?

Posted by: Rolf Tollerud on June 17, 2004 in response to Message #126361
I am looking forward to your next post! :)

  Message #126371 Post reply Post reply Post reply Go to top Go to top Go to top

The real result. Give a look!

Posted by: Bruno Vieira on June 17, 2004 in response to Message #126158
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>

  Message #126385 Post reply Post reply Post reply Go to top Go to top Go to top

The real result. Give a look!

Posted by: Cameron Purdy on June 17, 2004 in response to Message #126371
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!

  Message #126392 Post reply Post reply Post reply Go to top Go to top Go to top

Most balanced analysis

Posted by: Nick Minutello on June 17, 2004 in response to Message #126354
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?

  Message #126404 Post reply Post reply Post reply Go to top Go to top Go to top

just to show that I am no zealot

Posted by: Rolf Tollerud on June 17, 2004 in response to Message #126339
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

  Message #126408 Post reply Post reply Post reply Go to top Go to top Go to top

Most balanced analysis

Posted by: David Jones on June 17, 2004 in response to Message #126392
"(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?

  Message #126431 Post reply Post reply Post reply Go to top Go to top Go to top

just to show that I am no zealot

Posted by: Henrique Steckelberg on June 17, 2004 in response to Message #126404
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?

  Message #126434 Post reply Post reply Post reply Go to top Go to top Go to top

Excelsior for Linux

Posted by: Rolf Tollerud on June 17, 2004 in response to Message #126431
JET 3.6 Release Candidate 2 for Linux

  Message #126435 Post reply Post reply Post reply Go to top Go to top Go to top

Most balanced analysis

Posted by: Dilip Ranganathan on June 17, 2004 in response to Message #126408
"(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..)

  Message #126449 Post reply Post reply Post reply Go to top Go to top Go to top

Language, or Machine? Everything is Virtual

Posted by: Fuad Efendi on June 17, 2004 in response to Message #126158
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?

  Message #126489 Post reply Post reply Post reply Go to top Go to top Go to top

Blast from the past

Posted by: Cedric Beust on June 17, 2004 in response to Message #126435
"(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

  Message #126583 Post reply Post reply Post reply Go to top Go to top Go to top

Blast from the past

Posted by: Dilip Ranganathan on June 18, 2004 in response to Message #126489
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?

  Message #126587 Post reply Post reply Post reply Go to top Go to top Go to top

Blast from the past

Posted by: Cameron Purdy on June 18, 2004 in response to Message #126583
Dilip - I'm as confused as you are: Was that sincerity or sarcasm?

Peace,

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

  Message #126609 Post reply Post reply Post reply Go to top Go to top Go to top

Yet Another Benchmark: Follow up by Stefan Brujin

Posted by: Dilip Ranganathan on June 18, 2004 in response to Message #126158
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/

  Message #126630 Post reply Post reply Post reply Go to top Go to top Go to top

Yet Another Benchmark: Follow up by Stefan Brujin

Posted by: Cameron Purdy on June 18, 2004 in response to Message #126609
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!

  Message #126633 Post reply Post reply Post reply Go to top Go to top Go to top

Yet Another Benchmark: Follow up by Stefan Brujin

Posted by: Sartoris Snopes on June 18, 2004 in response to Message #126630
"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++.

  Message #126660 Post reply Post reply Post reply Go to top Go to top Go to top

Productivity

Posted by: Cameron Purdy on June 18, 2004 in response to Message #126633
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!

  Message #126669 Post reply Post reply Post reply Go to top Go to top Go to top

Productivity

Posted by: Dilip Ranganathan on June 18, 2004 in response to Message #126660
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"?

  Message #126684 Post reply Post reply Post reply Go to top Go to top Go to top

Productivity

Posted by: Cameron Purdy on June 18, 2004 in response to Message #126669
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!

  Message #126695 Post reply Post reply Post reply Go to top Go to top Go to top

there is no sadder than sentences that start with "what if"

Posted by: Rolf Tollerud on June 19, 2004 in response to Message #126684
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

  Message #126745 Post reply Post reply Post reply Go to top Go to top Go to top

with friends like Sun you do not need enemies

Posted by: Rolf Tollerud on June 20, 2004 in response to Message #126431
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

  Message #126759 Post reply Post reply Post reply Go to top Go to top Go to top

Oh come on

Posted by: Fyodor Kupolov on June 21, 2004 in response to Message #126321
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.

  Message #126771 Post reply Post reply Post reply Go to top Go to top Go to top

Productivity

Posted by: Kalyan Kolachala on June 21, 2004 in response to Message #126660
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!


  Message #126782 Post reply Post reply Post reply Go to top Go to top Go to top

Productivity

Posted by: Cameron Purdy on June 21, 2004 in response to Message #126771
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!

  Message #126801 Post reply Post reply Post reply Go to top Go to top Go to top

Productivity

Posted by: Cedric Beust on June 21, 2004 in response to Message #126771
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

  Message #126806 Post reply Post reply Post reply Go to top Go to top Go to top

there is something wrong somewhere here

Posted by: Rolf Tollerud on June 21, 2004 in response to Message #126801
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

  Message #126851 Post reply Post reply Post reply Go to top Go to top Go to top

Stupid is stupid does

Posted by: Jamie Schiner on June 21, 2004 in response to Message #126806
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 :)

  Message #127286 Post reply Post reply Post reply Go to top Go to top Go to top

there is something wrong somewhere here

Posted by: Dorel Vaida on June 24, 2004 in response to Message #126806
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.

  Message #127347 Post reply Post reply Post reply Go to top Go to top Go to top

best environment today

Posted by: Rolf Tollerud on June 24, 2004 in response to Message #127286
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

  Message #127372 Post reply Post reply Post reply Go to top Go to top Go to top

5 000 000 dowloads

Posted by: Rolf Tollerud on June 24, 2004 in response to Message #127347
Azureus - Java BitTorrent Client just reached 5 000 000 dowloads milestone.
http://azureus.sourceforge.net/changelog_v2.php

Based on SWT of course.

  Message #127373 Post reply Post reply Post reply Go to top Go to top Go to top

P.S.

Posted by: Rolf Tollerud on June 24, 2004 in response to Message #127347
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.

New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com

Dependency Injection in Java EE 6 - Part 1

Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6. (November 2, Article)

SAML: It's Not just for Web services

SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options. (September 28, Article)

Programming is Also Teaching Your Team

Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team. (September 22, Article)

Can Java EE Deliver The Asynchronous Web?

Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies. (July 14, Article)

JSF Flex

JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags. (June 29, Article)

The Rules of SOA - A Road to a Successful SOA Implementation

In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project. (June 23, Tech Talk)

Ari Zilka Talks About Terracotta 3.1

Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now. (June 15, Tech Talk)

Enterprise Application Integration, and Spring

In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements. (June 15, Tech Talk)

Google Web Toolkit: An Introduction

In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls. (June 4, Tech Talk)

Just Enough Early Architecture to Guide Development

Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable. (May 28, Tech Talk)

Productive Programmer: On the Lam from the Furniture Police

This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work. (May 26, Tech Talk)

Auto-Scaling Your Existing Web Application

Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers. (May 21, Tech Talk)

Automating Hibernate Mapping and Queries For Java Web Development

Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application. (May 19, Article)

Auto-Scaling Your Existing Web Application

In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources. (May 19, Tech Talk)

Free Book: Jakarta-Struts Live

Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)

Application Server Matrix

The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)

News | Blogs | Discussions | Tech talks | Patterns | Reviews | White Papers | Downloads | Articles | Media kit | About
Java Solutions
All Content Copyright ©2007 TheServerSide Privacy Policy
Site Map