The Artima Developer Community
Sponsored Link

Weblogs Forum
Optimization: Me versus Guy Steele

31 replies on 3 pages. Most recent reply: Nov 5, 2005 4:10 AM by Bob Dobalina

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 31 replies on 3 pages [ « | 1 2 3 | » ]
Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Speed Java vs C++ (Re: Optimization: Me versus Guy Steele Posted: Oct 1, 2005 9:58 PM
Reply to this message Reply
Advertisement
You can think "C++ is faster than Java" and you will find plenty of smart programmers who agree with, but you would be wrong.

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.

I have reimplemnted a number of C++ applications in Java and seen significant improvements in scalability. Of course there are still some very important points wher Java lags (e.g. complex arithmetic ) but in general, Java will be faster.

One of these reasons is neatly described in
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Speed Java vs C++ (Re: Optimization: Me versus Guy Steele Posted: Oct 2, 2005 8:04 AM
Reply to this message Reply
> I have reimplemnted a number of C++ applications in Java
> and seen significant improvements in scalability. Of
> course there are still some very important points wher
> Java lags (e.g. complex arithmetic ) but in general, Java
> will be faster.
>
> One of these reasons is neatly described in
> http://www-128.ibm.com/developerworks/java/library/j-jtp092
> 75.html

Great article.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Speed Java vs C++ (Re: Optimization: Me versus Guy Steele Posted: Oct 3, 2005 1:21 PM
Reply to this message Reply
/* 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 threads and implemented in terms of them.

* 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.

* 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.

/* 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.

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.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: memory management Posted: Oct 3, 2005 1:31 PM
Reply to this message Reply
The optimization regarding memory management is old hat for C and C++ programmers. Stroustrup makes the suggestion in "The C++ Progamming Language" before saying "I suspect most C++ implementations will do this automatically." Apache offers this as part of the APR. It's one of the basic reasons given for writing your owd std::allocator, ...

It's available in C++, and when used it puts C++ out ahead of Java programs that use it.

Again, reminds me of optimized microkernels vs. unoptimized monolithic kernels.

Mike Petry

Posts: 34
Nickname: mikepetry
Registered: Apr, 2005

Re: Optimization: Me versus Guy Steele Posted: Oct 3, 2005 5:11 PM
Reply to this message Reply
If someone has a performance concern, I usually ask for quantification. I also have been raised to believe that preoptimization is a sin. Most of the opportunities for optimization lay outside the domain of the programming langauges. Today most badly performing software is poorly designed.
One problem is UI refresh. The app must update UI after one field is updated and also update UI when a host of fields are updated due to a transaction. Typically the same logic is employeed that updates the one field but is executed multiple times. Sit and watch the screen flicker.
Another problem is database connections. Do we need to establish a connection for each operation or can we hold on to one connection for a series of operations. This will take a little more design up front but will have a huge impact on the user experience. More sophisticated applications can take advantage of connection pools, and thread pools. Threads are another resource that is expensive to create. Software and system designs are where optimization can be achieved.
The "you can take my C++ away when you pry it from dead cold fingers - because it performs well" is getting a little stale. C++ UI code is like having a souped up tractor. C++ database access code is like having a high-performance skooter. I know someone who insisted on coding up a web-browser plug-in in C++ for performance reasons. I was hoping to point out the most of the waiting would be based on internet traffic but I don't always get to make my point.
I am not a advocate for code bloat or poor programming practices. I think the good "ilities" are more relevent today. BTW I updated my blog after several months:
http://mikepetry.blogspot.com/

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Optimization: Me versus Guy Steele Posted: Oct 3, 2005 6:18 PM
Reply to this message Reply
> If someone has a performance concern, I usually ask for
> quantification. I also have been raised to believe that
> preoptimization is a sin.

I am totally sympathetic with this viewpoint. Many application developers don't realize that software performance is like that of a car: it is irrelevant how fast you were going when you burst into flames.

Several respondants to my blog post seem to have missed the point that I was trying to make which is that in a language it should be possible for professionals to write highly optimized domain specific libraries.

JIT optimization is great for many applications, but you aren't going to see it outperform optimized libraries based on Generative Programming techniques.

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: Speed Java vs C++ (Re: Optimization: Me versus Guy Steele Posted: Oct 3, 2005 9:02 PM
Reply to this message Reply
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"

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Speed Java vs C++ (Re: Optimization: Me versus Guy Steele Posted: Oct 4, 2005 9:11 AM
Reply to this message Reply
/* I am not trying to start a "Java is better than C++ thread"
*/

Sorry. I know I shouldn't go there, especially not on a blog regarding neither Java nor C++.

/* 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.
*/

That is a good point. OTOH my copy of "Multithreaded Prgramming With Java Technology" (http://www.amazon.com/exec/obidos/tg/detail/-/0130170070/104-9879591-2445539?v=glance) is based on a previous book named "Multithreaded Programming with Pthreads" (http://www.amazon.com/exec/obidos/tg/detail/-/0136807291/qid=1128432848/sr=1-1/ref=sr_1_1/104-9879591-2445539?v=glance&s=books), and even includes a chapter on shared memory -- or rather says "shared memory is not available in Java." Why? Because that chapter was in the previous book.

My point is that the concepts are easily implemented in either language.

/* 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.
*/

To be honest, I haven't spent much time learning the improvements in Java 1.5. But this post may get me looking again.

/* 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
*/

Boost.Unit.

/* OptimizeIt: ... It's better than gprof, Quantify and the like
*/

I'm not trying to suggest that gprof is state of the art, just that I find it hard to believe that better tools than gprof aren't available. Much like I don't mean to imply that gdb is the most usable debuger out there.

Additionally, the most respected tools appear to not be language dependant. For instance, Plan 9's Spin still holds its own (and I think there is a lot of room for improvement).

/* The productivity numbers I have seen from empirical studies suggest a factor of 2 or 3.
*/

That's fair. Unfortunately, many studies I have seen pre-date the C++ spec (1998), and don't take the STL into account. Yes, that sounds like nitpicking, but what about studies showing Java 1.1 pales in comparison to C++? If we're going to compare modern Java, we need to compare it to modern C++.

/* My personal experience suggests that C++ has a higher barrier to entry ...
*/

That's also fair. I know the standards committee is trying to change this, but I'm not expecting all that much.

/* There is no C++ equivalent to the Thread Debugger in OptimizeIt. No equivalent to the Wily Introscope "dynamic production profiling" tool.
*/

Hmm. Sounds like I need to get acquainted with a few Java tools. Thanks.

Andrew McKinlay

Posts: 2
Nickname: amckinlay
Registered: Oct, 2003

Re: Optimization: Me versus Guy Steele Posted: Oct 6, 2005 7:01 PM
Reply to this message Reply
> So far, the world in general has declined to use
> big complicated gui applications written in java

That may be changing - Eclipse is doing pretty well

Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: Optimization: Me versus Guy Steele Posted: Oct 7, 2005 1:48 AM
Reply to this message Reply
> > So far, the world in general has declined to use
> > big complicated gui applications written in java
>
Which world are you talking about??

Define a big complicated GUI application??
What would you call a Point of Sales System??
I don't mean a POS at your local convinience store,
I mean a POS running in chain stores, wholesale
spots and the list goes on. If that were the case
why would a bunch of large retail outlets link up
with Tech industry giants (IBM, Epson, Fujitsu) link
up with the likes of KMart and JCPenny to try to
standardise Java POS - which from my experience
involves building large scale apps? Unless you
clarify what you mean by a "big complicated application"
I'm afraid your claim does not hold.

damien morton

Posts: 15
Nickname: dmost
Registered: Jan, 2004

Re: Optimization: Me versus Guy Steele Posted: Oct 7, 2005 11:42 PM
Reply to this message Reply
No - Im not thinking POS systems. I guess I'm thinking word processors, financial information systems, and so forth. I guess Im also including IDE's in that list.

A POS system could pretty much be written in javascript and HTML. Nothing taxing going on there, at the client end, anyway.

Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: Optimization: Me versus Guy Steele Posted: Oct 10, 2005 3:19 AM
Reply to this message Reply
>
> A POS system could pretty much be written in javascript
> and HTML. Nothing taxing going on there, at the client
> end, anyway.

You would write a POS System (Rich-Client Application)
in Java Script and HTML? I guess it wouldn't have
much functionality and efficiency to it then. In that
case I can make an argument for all the other listed
apps to be written in JavaScript and HTML. There are
a lot large GUI apps. written in Java (off the top of
my head, POS apps aside I can think of Limewire)

Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: Optimization: Me versus Guy Steele Posted: Oct 10, 2005 6:16 AM
Reply to this message Reply
> A POS system could pretty much be written in javascript
> and HTML. Nothing taxing going on there, at the client
> end, anyway.

BTW, I'm sure if you gave Wal Mart a Point of Sale system that ran
via a Browser they'd be over the moon.

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: Optimization: Me versus Guy Steele Posted: Oct 10, 2005 10:39 AM
Reply to this message Reply
It would appear that, with the notable exception of Visual Studio, most of the IDEs and devlopment tools that have significant market share today are written in Java: Eclipse, IntelliJ Idea, NetBeans, jEDIT, JProfiler, OptimizeIt, JProbe are all written in Java - collectively theres a few million users of these tools, so clearly Java is being used widely for nontrivial GUI applications.

bug not

Posts: 41
Nickname: bugmenot
Registered: Jul, 2004

Re: Optimization: Me versus Guy Steele Posted: Nov 4, 2005 6:45 PM
Reply to this message Reply
>
> JIT optimization is great for many applications, but you
> aren't going to see it outperform optimized libraries
> based on Generative Programming techniques.

Your info is outdated.

If your app is highly concurrent (say a thousand simultaneous users or so) then the Java based solutions are going to beat you hands down.

Some reasons:

- Threading: Java makes threading EASY so programmers take full advantage of it. You also have this to consider http://www.ibm.com/developerworks/java/library/j-jtp10185/index.html. So you can thread your apps all you want.. add synchronization as much as you like, then the JIT removes the synchronization you don't need.. Wow! That's pretty good!

- Memory: memory handling for Java can be extremely efficient. See http://www.ibm.com/developerworks/java/library/j-jtp09275.html. In fact Java 1.6 will allocate on the stack just like C++, but without all the implicit copies (careful! or C++ will copy that), without messy memory handling

- And the usual JIT stuff

The best part is that over time your code gets faster without having to recompile or do anything.. just change the VM.

Ref counting, explicit malloc/delete is very hard to get right especially for server apps.

However, I think you always should be aware of what you're doing. Also, Java's GUI libraries ARE slow, ARE hard to get right in spite of everything.. But lets not confuse GUI libs and little apps with the powerhouse web apps people are using Java for.

Flat View: This topic has 31 replies on 3 pages [ « | 1  2  3 | » ]
Topic: The Trouble with Searching for Open-Source Code Previous Topic   Next Topic Topic: Generics: Bounds Puzzle


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us