Peter Booth
Posts: 62
Nickname: alohashirt
Registered: Aug, 2004
|
|
Re: Speed Java vs C++ (Re: Optimization: Me versus Guy Steele
|
Posted: Oct 3, 2005 6:02 PM
|
|
I'll address them in turn. And please note - I am not trying to start a "Java is better than C++ thread" I can guarantee that if you pickup any code I wrote you would be able to improve it in five nontrivial ways. It makes sense that Java learned from C++ just as C# learned from Java and Fortress will learn from all of them ... C++ had its moment in teh SUn and soon enough Java will be a prehistoric language that us old fogies still prefer.
> /* Most non-trivial applications, when written by an
> experienced team, will exhibit better performance in Java
> than C++. This is a result of:
>
> * better high level concurrency constructs,
> * better development tools,
> * better profiling tools,
> * increased developer productivity and more high quality
> libraries mean more time left over to do performance work
> * and of course, the HotSpot compiler.
> */
>
> Taking these in turn:
> * concurrency -- what do you think about Boost.Threads
> (www.boost.org)? How about CAS/CAS2/DCAS (lock free/wait
> free concurrency)? And what's wrong with POSIX threads?
> I understand Java's threading model is based on POSIX
> X threads and implemented in terms of them.
There's nothing wrong with Posix threads - though they are quite different to Java threads in that Java threads work at a higher level of abstraction with different platforms use different implementations to map Java threads to native threads. For example Solaris 5 through 8 uses libthread which means a MxN map of Java threads to native threads (which are then mapped to lwps and then kernel threads - like fleas ontop of ladybugs, ontop of dung beetles ontop of something else ..)
The high level constructs I refer to are the executors, atomic variables, and the like created by Doug Lea that are now part of Java 1.5. These are usable concurrent data structures / classes rather than just core constructs. Very different from Java thread library or posix or Boost threads.
> * dev tools -- really? Are you just talking about
> Eclipse? Eclipse does have a C++ environment. If you're
> talking about something else, I'm pretty sure C++ dev
> tools exist on par with it.
They don't - not for technical reasons but commercial ones. Sure Eclipse is a great IDE but I am referring to a bunch of value added tools that don't have a C++ equivalent:
Junit - yes there a few CppUnit implementations - but they are much less usable than Junit
OptimizeIt: This is still the best of the dozen or so Java profilers. It's better than gprof, Quantify and the like because it came later and because Java is an easier platform to tool for.
Easymock, mockhelper, httpunit, sqlunit, grinder - an assortment of free test tools each of which fills a small important niche
ONE EXCEPTION : there are many static analysis tools for C++ (PCLint QA C++) that are just as good as the Java equivalents (findbugs, pmd) although it is much harder to find free C++ tools
> * profiling tools -- again, really? I know gcov/gprof
> offer profiling, and I'm sure better profilers exist out
> there.
>
> * dev productivity/better libraries -- without something
> to back this up, I'm inclined to say this is a matter of
> opinion.
That's fair. The productivity numbers I have seen from empirical studies suggest a factor of 2 or 3. These studies are weak in that they use college students who are not a good proxy for experienced developers. I can't recall authors and three minutes in CiteSeer failed to find one. My personal experience suggests that C++ has a higher barrier to entry (in terms of intelligence, and perserverance) an dthat conversely Java makes it easier to write reams of bad code.
> /* I have reimplemented a number of C++ applications in
> Java and seen significant improvements in scalability. Of
> course there are still some very important points where
> Java lags (e.g. complex arithmetic ) but in general, Java
> will be faster.
> */
>
> I can see your basic point that the level of abstraction a
> Java programmer uses is different than that of a C++
> programmer, and as such more productive. I can also see
> the claim that a Java program will, in general, be better
> syncronized.
There is no C++ equivalent to the Thread Debugger in OptimizeIt. No equivalent to the Wily Introscope "dynamic production profiling" tool. These are expert focused niche tools that help with availability an deprformance of large systems.
> However, if we go back to that, "Most non-trivial
> applications, when written by an experienced team" part, I
> would be inclined to say that an experienced C++ team
> would get the Java abstraction just fine, and would then
> add on to that with abstractions available in C++ but that
> do no exist in Java.
The generic programming of C++ is very powerful and has no equivaent in Java. WHen I weigh that against slow build times lack of free tools, the inconsistencies in the language, overloading of word and symbols I would not work with C++ for an extra $50k. A few multiples of this then I'd happily acceptg and tell myself "It's good for the soul, like cold showers"
|
|
Previous Topic
