Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / October 2005

Tip: Looking for answers? Try searching our database.

Server app speed - Java vs C++

Thread view: 
Davey - 02 Oct 2005 13:18 GMT
Which is typically faster - a Java server application or a C++ server
application?
Jeff Schwab - 02 Oct 2005 15:38 GMT
> Which is typically faster - a Java server application or a C++ server
> application?

Faster at what?  C++ run-time performance is generally superior,
regardless of the current zeitgeist that "nobody should be avoiding Java
for performance reasons."  But if you're talking about a long-running,
multithreaded, I/O-bound application, e.g. a web server, the Java
application might actually be faster, and almost certainly will be
faster to develop.
Davey - 02 Oct 2005 17:10 GMT
>> Which is typically faster - a Java server application or a C++ server
>> application?
>
> Faster at what?  C++ run-time performance is generally superior,
> regardless of the current zeitgeist that "nobody should be avoiding Java
> for performance reasons."

Thanks for the answer.

> But if you're talking about a long-running, multithreaded, I/O-bound
> application, e.g. a web server,

Yes, I'm talking about the server-side component of a client-server
application. It will involve reading data from a database and sending the
information to clients apps depending on requests from those apps.

> the Java application might actually be faster, and almost certainly will
> be faster to develop.

OK, thanks.
Wibble - 02 Oct 2005 19:57 GMT
>>>Which is typically faster - a Java server application or a C++ server
>>>application?
[quoted text clipped - 16 lines]
>
> OK, thanks.

When C++ behaves badly, it crashes.  When java behaves badly, its
not hard to make it local or recoverable.

Java is fast enough on the server side, especially where the database is
likely to be the bottleneck.

The difference in speed doesn't make up for the added safety of java.
Jeff Schwab - 02 Oct 2005 21:31 GMT
>>>> Which is typically faster - a Java server application or a C++
>>>> server application?
[quoted text clipped - 19 lines]
> When C++ behaves badly, it crashes.  When java behaves badly, its
> not hard to make it local or recoverable.

Poorly written C++ code crashes.  Poorly written Java code crashes, e.g.
with a NullPointerException.  Well written code in either language does
not crash.

> Java is fast enough on the server side,

That depends what's being done.

> especially where the database is
> likely to be the bottleneck.

True.

> The difference in speed doesn't make up for the added safety of java.

The added speed may or may not be worth trading away for Java's
mandatory run-time checks.  C++ provides better static safety checks,
and makes many Java-like run-time checks available, just not mandatory.
Roedy Green - 03 Oct 2005 01:23 GMT
>Poorly written C++ code crashes.  Poorly written Java code crashes, e.g.
>with a NullPointerException.  Well written code in either language does
>not crash.

Consider how large programs are now.  If you have  probability p
(expressed as number between 0 and 1 e.g. 1/1,000,000) that a given
line contains an error, then the odds of a program N lines long being
perfect is:

         N
(1-p)

You see how the math works against you because  N, the size of the
program is in the exponent.  So in other words, no matter how careful
your programmers, in large programs, errors are unavoidable.

C++ was designed back when programs were small and it was possible to
avoid error with sufficient skill and care.

Java takes a more realistic view that there will inevitably be errors
in large programs no matter who wrote them.

How can you find them? (avoiding  pointers, null pointer and array
bounds checks)  How can you keep doing even when they happen? (catch)
How can you flush them out? (assertions)

How could we do even better? (design by contract).

see http://mindprod.com/jgloss/designbycontract.html
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Ben Pope - 03 Oct 2005 01:43 GMT
> C++ was designed back when programs were small and it was possible to
> avoid error with sufficient skill and care.
[quoted text clipped - 3 lines]
>
> How can you find them? (avoiding  pointers,

...you can do that in C++, if you like, or use smart pointers such as std::auto_ptr, or boost::shared_ptr

> null pointer

Use references instead of pointers.

> and array bounds checks)

std::vector.

> How can you keep doing even when they happen? (catch)

...like in C++.

> How can you flush them out? (assertions)

Yeah.

> How could we do even better? (design by contract).
>
> see http://mindprod.com/jgloss/designbycontract.html

I fail to see what your first 2 sentances above are about.

Ben
Signature

I'm not just a number. To many, I'm known as a String...

Roedy Green - 03 Oct 2005 04:43 GMT
>...you can do that in C++, if you like, or use smart pointers such as std::auto_ptr, or boost::shared_ptr
>
>> null pointer
>
>Use references instead of pointers.

Yes you can make C++ safer with extra effort, but normally you are
running without any safety net.  In Java the net is mandatory.  

There is nothing in C++ to ensure you scrupulously avoided pointers or
invalid casts..
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Ian - 03 Oct 2005 05:47 GMT
>>...you can do that in C++, if you like, or use smart pointers such as std::auto_ptr, or boost::shared_ptr
>>
[quoted text clipped - 7 lines]
> There is nothing in C++ to ensure you scrupulously avoided pointers or
> invalid casts..

Your coding standards.

Ian
Roedy Green - 03 Oct 2005 06:01 GMT
>> There is nothing in C++ to ensure you scrupulously avoided pointers or
>> invalid casts..
>
>Your coding standards.

But there is nothing to enforce the standard, so you are back to
relying on your own skill and care.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Kai-Uwe Bux - 03 Oct 2005 07:47 GMT
>>> There is nothing in C++ to ensure you scrupulously avoided pointers or
>>> invalid casts..
[quoted text clipped - 3 lines]
> But there is nothing to enforce the standard, so you are back to
> relying on your own skill and care.

Well, my personal coding standards decree that raw pointers are not to be
used. Instead, my code uses smart pointers or wrapers that support memory
leak detection. This rule, which is a real time saver, happens to be rather
simple to enforce:

bits> wc graph_002.cc
1363  4644 36840 graph_002.cc
bits> grep delete graph_002.cc
bits> grep new graph_002.cc
         // new label:
bits>

(Admittedly, there was a false positive. But that was easy to spot.)

Now, I agree that there are other gotchas for C++ and more sophisticated
tools would be needed to catch those. On the other hand, I found that it
takes very little discipline to avoid these dark corners: most of the time
you simply don't have a reason to go there anyway.

Best

Kai-Uwe Bux
Shezan Baig - 03 Oct 2005 10:10 GMT
> >Your coding standards.
>
> But there is nothing to enforce the standard

And thankfully so.

> so you are back to relying on your own skill and care.

Again, we're talking about C++ here, not C.

-shez-
Shezan Baig - 03 Oct 2005 02:51 GMT
> C++ was designed back when programs were small and it was possible to
> avoid error with sufficient skill and care.
>
> Java takes a more realistic view that there will inevitably be errors
> in large programs no matter who wrote them.

This is a common misconception made by people who think of C++ as "a
new C".  They are two very different languages (even though they
somehow manage to work really well together).  IMO, this is good.

You maybe need sufficient skill and care with C, but not with C++.

There is little point comparing Java with C++ (again!) - they, also,
are completely different languages and people use each one based on the
circumstances.

To the OP: use something that you are most comfortable with.

Hope this helps,
-shez-
Roedy Green - 03 Oct 2005 01:06 GMT
>Java is fast enough on the server side, especially where the database is
>likely to be the bottleneck

or the datacommunications.  You can find out which by comparing how
the app behaves on a LAN compared with out there on the web.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Ian - 02 Oct 2005 22:12 GMT
>>But if you're talking about a long-running, multithreaded, I/O-bound
>>application, e.g. a web server,
>
> Yes, I'm talking about the server-side component of a client-server
> application. It will involve reading data from a database and sending the
> information to clients apps depending on requests from those apps.

In this case, run time performance is a secondary consideration, use the
 environment you are most familiar with.

Ian
Roedy Green - 03 Oct 2005 01:05 GMT
>Which is typically faster - a Java server application or a C++ server
>application?

I don't think there would be any contest in who has the better chance
of getting a bug free program first.  Java is much better designed for
that.

I would say that a C++ server app, if you allowed say 10 years to
polish the code would do better than the equivalent server app given a
similar length of time, but that does not happen in real life.

What happens in real life is, you have a fixed time budget.  The C++
programmer spends it coding. The Java programmer has some time left
over to test and optimise and refactor.

As systems get more complex, it does not matter if they can deliver
wrong answers more quickly.  What counts is getting the right answer
in an acceptable length of time.

When I started out, CPUs rented for well over $100 per hour. It thus
made sense to spend considerable programmer to reduce CPU time.  Today
the roles are reversed. It pays to spend CPU time to save programmer
time.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

James McIninch - 03 Oct 2005 04:43 GMT
That depends on what you are doing and how well the Java and C++ are
written. Different circumstances will yield different results.

The only thing you can say in general is that there's overhead in
initialization of JVM that you are not going to see in C++. If the program
runs for only a few seconds, that time can be significant. If the program
runs for a longer period of time, less so.

> Which is typically faster - a Java server application or a C++ server
> application?

Signature

Remove '.nospam' from e-mail address to reply by e-mail

raxitsheth@gmail.com - 03 Oct 2005 12:00 GMT
responding to Davey...

I think following link can give you Good Answer...!!!

Presented at Sun Microsystems Laboratories,by Matt

http://www.eecs.harvard.edu/~mdw/proj/old/jaguar/sunlabs-talk/

Regards
Raxit Sheth
Drazen Gemic - 03 Oct 2005 18:04 GMT
> Which is typically faster - a Java server application or a C++ server
> application?

It is likely that network or database would be a performance bottleneck,
so, it does not matter. Annother question is design, if you choose bad
server side application design, there will be problem in both cases.

C++ will execute the same sequence of simple operations faster.

There has been a lot of similar questions in this group, so, please,
don't post souch questions in the future.

DG


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.