|
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++
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
|
|
|
Message #126170
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Interesting but...
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...
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...
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
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 #126206
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Interesting but...
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...
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 #126225
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A call for new benchmarks
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!
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
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
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 ??
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
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 ??
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 ??
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
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...
<!--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
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 ;-)
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
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
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
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++
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 ??
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 ;-)
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 ??
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 #126315
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
why make it more difficult than it is?
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++
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
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
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??
"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?
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?
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?
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
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�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�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 #126365
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE or RDBMS?
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 #126371
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The real result. Give a look!
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!
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
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
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
"(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
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 #126435
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Most balanced analysis
"(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
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
"(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
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 #126630
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Yet Another Benchmark: Follow up by Stefan Brujin
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
"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
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
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
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"
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
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
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
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,
KalyanSartoris: 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
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
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
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 #127286
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
there is something wrong somewhere here
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
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
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
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 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)
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)
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)
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)
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, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
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)
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)
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)
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)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
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)
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)
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)
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)
|
|
