Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > java versus C or C++ for number crunching

Reply
Thread Tools

java versus C or C++ for number crunching

 
 
Patricia Shanahan
Guest
Posts: n/a
 
      03-25-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> This is the sort of question that I hope won't start an unhappy
> discussion, but I wanted to know whether there are any well accepted
> tests comparing java to C++ (or C) for doing extensive number
> crunching (e.g. multiplying 100,000 vectors in three space by various
> matrics, and maybe even a lot of trig used to generate those matrices,
> so lots of addition and multiplication). I am using C++ for a number
> crunching intensive project because I have been so insistently
> informed that Java is slow at number crunching and because a discrete
> fast fourier procedure I wrote really did seem surprisely slow in Java
> (but hey, maybe thats my fault, though I did use the fast version of
> the transform). But if Java is not really lagging on number crunching
> I would love to switch as I like Java so much. I could write my own
> little test program easily enough, but everytime someone posts that
> they have done so it seems like there are a lot of explanations posted
> about why whatever they wrote is a bad test. Are there any accepted
> "good tests" on number crunching that have been run recently?


There is only one test that can accurately predict the performance of
your code - running your code.

Here's what I would do in your situation:

1. Extract from a few of your programs pieces of code that are
relatively small but take a high proportion of the run time.

2. Write programs around those pieces of code that set up typical test
data and check the results. These programs should also be dominated by
the code from step 1.

3. Re-implement a step 2 program in Java. Compare the new performance.
If it is good enough for your purposes, repeat for each of the programs.
If one of the jobs does not run well enough, rerun it on each new major
release of Java, but stick with C++.

If, on the other hand, Java does well enough on each of the tests, then
start writing some of your new programs in Java.

This procedure is not designed to answer some great absolute "Is Java
good for number crunching?" question. It is designed to answer the
question of whether you would get performance you like if you switched
to Java for the programs you are writing.

Patricia
 
Reply With Quote
 
 
 
 
Kenneth P. Turvey
Guest
Posts: n/a
 
      03-26-2008
On Tue, 25 Mar 2008 16:35:36 -0700, Peter Duniho wrote:

> I understand that. But that's a special case. For a very broad class
> of algorithms, that caveat doesn't apply and the generalization stated
> -- "C++ will be faster with object creation and destruction" -- would
> not be valid.
>
> Also, while there is overhead associated with collecting objects, it can
> be relatively inexpensive, especially if no heap compaction is required
> (many allocation patterns lend themselves to that situation).
>
> It's certainly true that one can come up with scenarios in which C++
> handles memory management faster than C# (and I guess from your
> comments, Java). But the converse is true as well, and IMHO there's no
> valid generalization that correctly describes the relative performance
> characteristics of those languages. The best one can say is "it
> depends".


I can't really give you the details on why these algorithms work out to
be faster in C, but I can give you my experience. The one thing that
might be an issue is that structures that might have been allocated on
the stack in C, end up in the heap in Java.

In my experience, and I'm strictly talking about code that doesn't really
ever have a time when it isn't doing something here, C++ will be much
faster if the code creates a lot of objects. I can't really give you the
reasons behind this, but only the results. I also can't really say
anything about C#, since I haven't programmed on that platform.

--
Kenneth P. Turvey <(E-Mail Removed)>
 
Reply With Quote
 
 
 
 
Kenneth P. Turvey
Guest
Posts: n/a
 
      03-26-2008
On Tue, 25 Mar 2008 19:14:57 -0400, Arne VajhĂžj wrote:

> All experience show that GC is more efficient than explicit deallocation
> at the cost of poorer real time characteristics.


That may be the consensus, but I know that in my experience (primarily
evolutionary computation and image processing) Java has not performed as
well as C when one starts to create many objects.

There are many good reasons to choose Java, but performance isn't usually
one of them. YMMV

--
Kenneth P. Turvey <(E-Mail Removed)>
 
Reply With Quote
 
Peter Duniho
Guest
Posts: n/a
 
      03-26-2008
On Tue, 25 Mar 2008 18:17:01 -0700, Kenneth P. Turvey
<(E-Mail Removed)> wrote:

> I can't really give you the details on why these algorithms work out to
> be faster in C, but I can give you my experience. The one thing that
> might be an issue is that structures that might have been allocated on
> the stack in C, end up in the heap in Java.


Could very well be. And C# doesn't have that limitation, since it has the
concept of non-reference (value) types, which can be allocated on the
stack.

That said, it seems to me that your original statement could use
refinement. Specifically, you didn't qualify the general "C++ will be
faster" statement with "in my experience". Only the "a lot faster", which
implies to me that you're saying C++ is always faster, and in your
experience it's always faster by "a lot".

I believe in fact, especially given what else others have written here,
that it's likely that it's not true that C++ is always faster. I can
easily believe that for a certain class of algorithms, C++ is always
faster with respect to memory management, but that's a lot different from
saying that it's always faster.

That's all I'm trying to say.

Pete
 
Reply With Quote
 
Peter Duniho
Guest
Posts: n/a
 
      03-26-2008
On Tue, 25 Mar 2008 18:21:14 -0700, Kenneth P. Turvey
<(E-Mail Removed)> wrote:

> [...]
> There are many good reasons to choose Java, but performance isn't usually
> one of them. YMMV


I agree that performance isn't usually the reason one chooses Java. And
especially in the context of this thread, I believe that's true ("number
crunching").

However, there are actually valid performance-based reasons for using an
environment like Java where a framework is provided. It is often the case
that application code spends very little time executing the code delivered
with the application. The API to which the application was written is
where most of the execution is done, and if that API has a
high-performance implementation, then one can often get better performance
using that API than trying to write it oneself (especially for a given
amount of effort).

I can't speak to any specific decision anyone's made along those lines
with respect to Java (I'm far too inexperienced with Java to have any
first-hand exposure to that sort of thing), but I have experience with
other APIs in which counter-intuitively it improved performance to code to
a framework/API that at first glance seems to add overhead. Because the
performance advantage from use thoroughly tested and optimized
implementations of costly operations exceeds the overhead of whatever's
required in order to use the framework/API, the net is a gain.

Again, I'm not sure any of that is relevant in this thread. It's just
that your comment brought it to mind, and I can't help but mention it.

Pete
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      03-26-2008
"Peter Duniho" <(E-Mail Removed)> writes:
>for a certain class of algorithms, C++ is always
>faster with respect to memory management,


Quotations regarding memory management:

»Your essay made me remember an interesting phenomenon I
saw in one system I worked on. There were two versions of
it, one in Lisp and one in C++. The display subsystem of
the Lisp version was faster. There were various reasons,
but an important one was GC: the C++ code copied a lot of
buffers because they got passed around in fairly complex
ways, so it could be quite difficult to know when one
could be deallocated. To avoid that problem, the C++
programmers just copied. The Lisp was GCed, so the Lisp
programmers never had to worry about it; they just passed
the buffers around, which reduced both memory use and CPU
cycles spent copying.«

<XNOkd.7720$(E-Mail Removed)>

A lot of us thought in the 1990s that the big battle would
be between procedural and object oriented programming, and
we thought that object oriented programming would provide
a big boost in programmer productivity. I thought that,
too. Some people still think that. It turns out we were
wrong. Object oriented programming is handy dandy, but
it's not really the productivity booster that was
promised. The real significant productivity advance we've
had in programming has been from languages which manage
memory for you automatically.

http://www.joelonsoftware.com/articles/APIWar.html

Regarding the topic of this thread:

»Java running faster than C«

http://paulbuchheit.blogspot.com/200...er-than-c.html

»Java theory and practice: Urban performance legends,
revisited Allocation is faster than you think, and getting
faster«

http://www.ibm.com/developerworks/ja...-jtp04223.html

»Java vs. C benchmark«

http://www.stefankrause.net/wp/?p=4
http://www.stefankrause.net/wp/?p=6

»Performance of Java versus C++«

http://www.idiom.com/~zilla/Computer...benchmark.html

»The Computer Language Benchmarks Game«

http://shootout.alioth.debian.org/

»How many times faster or smaller are the Java 6 -server
programs than the corresponding C GNU gcc programs?«

http://shootout.alioth.debian.org/debian/java.php

 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      03-26-2008
Kenneth P. Turvey wrote:
> In my experience, and I'm strictly talking about code that doesn't really
> ever have a time when it isn't doing something here, C++ will be much
> faster if the code creates a lot of objects. I can't really give you the
> reasons behind this, but only the results. I also can't really say
> anything about C#, since I haven't programmed on that platform.


Have you actually measured these speed differences, or is this just a fuzzy
feeling you have?

--
Lew
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      03-26-2008
Mark Thornton wrote:
> It depends. Java can often be faster with multi threaded code --- the
> standard C/C++ allocators have to use locking around every alloc/free
> whereas Java allocators are often lock free even on multiprocessors. If
> your storage structure (and object lifetime) is sufficiently complex
> that your C++ code uses reference counting, then Java's garbage
> collector can be a lot faster (reference counting with locking is
> relatively slow).


To which of Java's several garbage collectors does your comment apply?

Young generation collections in Java are very fast, influenced only by the
number of live objects; dead ones do not add to the GC time.

--
Lew
 
Reply With Quote
 
Kenneth P. Turvey
Guest
Posts: n/a
 
      03-26-2008
On Tue, 25 Mar 2008 21:51:22 -0400, Lew wrote:

> Have you actually measured these speed differences, or is this just a
> fuzzy feeling you have?


I haven't measured them, but they are clearly apparent in the algorithms
I've worked on. Usually the Java program takes longer than the C program
by a multiple greater than 2.

Now, if you program in Java in much the same way you would in C, that is
you don't create any objects, Java is actually faster much of the time.
If however, you program in a way that is natural in Java and best
describes the algorithm you are implementing, you'll find that Java is
much slower than C.

This should all be prefaced with, "In my experience.. ".


--
Kenneth P. Turvey <(E-Mail Removed)>
 
Reply With Quote
 
Mark Thornton
Guest
Posts: n/a
 
      03-26-2008
Peter Duniho wrote:
> On Tue, 25 Mar 2008 16:09:29 -0700, Mark Thornton
> <(E-Mail Removed)> wrote:
>
>> In big computational tasks you don't have idle moments and eventually
>> you do have to clean up.

>
> I understand that. But that's a special case. For a very broad class
> of algorithms, that caveat doesn't apply and the generalization stated
> -- "C++ will be faster with object creation and destruction" -- would
> not be valid.
>


The original question related to "Number Crunching" which usually falls
into that special case.

Mark Thornton
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is Java 1.6 number crunching slower than 1.5? Kevin McMurtrie Java 35 08-22-2009 11:39 PM
Java ready for number crunching? jhc0033@gmail.com Java 40 06-23-2008 01:38 AM
Using c++ template metaprogramming for high performance number crunching? Ted C++ 5 09-24-2007 05:34 PM
EJB + number crunching Martin Ankerl Java 8 08-23-2005 12:08 AM
big number crunching in C Shuo Xiang C Programming 3 09-26-2003 06:04 AM



Advertisments