How much fast is C++ than Java?

[Sanny]

I have an app in Java. It works fine. Some people say Java works as
fast as C. Is that true?

C can use assembly language programs. How much faster are they inplace
of calling general routines.

Can C++ directly acess the Registers.

Will the Computation 5-10 times faster than Java?

Is there any benchmark which tell us these things.

Bye
Sanny

C++ Experts Needed: http://www.getclub.com/Experts.php

 

[blmblm]

No. C will typically be about 5-10 times faster than the same application
written in Java, if the bottleneck is in code written in those languages.
That's an important point, because often the bottleneck is the rasteriser on
the grapj=hics card or something similar, in which case C will have no
advantage.

In my (admittedly limited, but more than zero) experience, C
is indeed faster, but not by anything like a factor of 5 to 10.
I'm curious to know what kinds of applications, on what systems,
exhibit such dramatic differences. I just did a quick check
using a toy numerical-integration example for a class I teach,
and the Java version took about 2.9 seconds, while the C version
took about 1.6 seconds. This is on a reasonably fast Intel-based
desktop-class machine running Linux, gcc, and Sun's Java. One of
my colleagues has done a couple of C++-versus-Java performance
comparisons using real code, and while the C++ versions are
invariably faster, the slowdown for the Java versions is usually
on the order of 10 to 25 percent (e.g., if the C++ version takes 1
minute, the Java version takes 1.1 to 1.25 minutes). There was one
exception -- a program that makes extensive use of trig functions,
which in Java are apparently (sometimes?) implemented in a way
that emphasizes portability over performance, or something. Now,
that's C++ and not C, but I have the impression from another
recent discussion in this group that C and C++ give comparable
performance.

Not saying you're wrong, Malcolm, just wondering why your
experience seems so different from mine. Early implementations
of Java were indeed quite slow, but my understanding is that most
current implementations do just-in-time compilation to native code,
and the results are pretty good.

However it rarely matters on modern PCs. The screen now usually updates
within a frame, so for any interactive work either Java or C is acceptable.

This is of course a good point!

 

[Richard]

In my (admittedly limited, but more than zero) experience, C
is indeed faster, but not by anything like a factor of 5 to 10.
I'm curious to know what kinds of applications, on what systems,
exhibit such dramatic differences. I just did a quick check
using a toy numerical-integration example for a class I teach,
and the Java version took about 2.9 seconds, while the C version
took about 1.6 seconds. This is on a reasonably fast Intel-based

It all depends on the applications and on how much time is spent in the
library functions. It really doesn't take a rocket scientist to realise
that C, written by a competent programmer, will generally be faster than
Java.

 

[blmblm]

Try a routine that uses mutli-dimensional arrays, and calculates numbers
based on adjacent elements in each direction.
What you'll find is that the Java indexing rules are nothing like as
efficient, and you'll get quite a considerable slowdown. I must admit I
haven't done my own timings, this is based on hearsay.

I also am not quite interested enough to do my own experiments, at
least right now. Certainly it's plausible that multidimensional
array access isn't as fast, given that conceptually a Java
multidimensional array is an array of array objects.

Your code's bottleneck was probably the trig functions, which may have been
written in assembly even for the Java version.

Nitpick: the code with the trig stuff is a colleague's not mine.

The initial Java version was much, much slower; profiling revealed
that a lot of time was being spent in the Java library trig
functions. I believe he ended up using JNI (Java Native Interface)
to call the C library functions, and that helped considerably.

There was a recent thread in comp.lang.java.programmer on this
subject, and while I didn't follow it carefully, I got the
impression that Java's library functions compare pretty well
with library functions in other languages on some architectures,
but not on others. I think the difficulty may be that the Java
standard imposes restrictions that rule out use of hardware
features other languages can and do make use of. That's vague,
I know, but maybe you also can extrapolate to imagine what some
of the issues might be -- I'm thinking that C leaves some things
unspecified so that implementations can do whatever works best
on particular platforms, and Java doesn't do that so much.

 

[blmblm]

It all depends on the applications and on how much time is spent in the
library functions. It really doesn't take a rocket scientist to realise
that C, written by a competent programmer, will generally be faster than
Java.

Probably so (despite the occasional claims by Java advocates
about the magic that can be worked via JIT compiling). But -- a
factor of 5 or 10? That's entirely plausible if the Java runtime
system is strictly a byte-code interpreter, as I understand the
early implementations were, but these days most of them do that
JIT compiling to native code, and while compiling isn't free,
it seems to me that if the cost of compiling a class is amortized
over many calls to its methods ....

Well. I don't mean to incite a flame war here -- I use and like
both Java and C -- but .... I wouldn't disagree with "Java is
generally slower, sometimes by a lot", but "Java is generally 5
to 10 times slower" seems to me to be too strong a claim. But I
admit that my perception is based more on anecdote and hearsay
than careful research.

 

[Robert S]

I also am not quite interested enough to do my own experiments, at
least right now. Certainly it's plausible that multidimensional
array access isn't as fast, given that conceptually a Java
multidimensional array is an array of array objects.

Time spent accessing 3D arrays on a modest wintel laptop:

C: 301 ms, Java: 731 ms, Size: 250*250*250
C: 171 ms, Java: 430 ms, Size: 200*200*200

Which fits in with what I've read about recent benchmarking: Java is
around about 2 to 3 times slower than C at most things.

Nowhere near 5 - 10 times.

Dev-cpp source:

#include <stdio.h>
#include <stdlib.h>
#include <sys/timeb.h>

#define size 250
int a[size][size][size];

int main(int argc, char *argv[])
{
struct timeb time1, time2;
time_t TimeMS; /*millisecond difference*/
time_t TimeS; /*time in seconds*/
time_t Elapsed_MS; /*elapsed time, milliseconds*/

ftime(&time1); /* starting time */

int i, j, k;

for(i=0; i<size; i++)
for(j=0; j<size; j++)
for(k=0; k<size; k++)
{
a[j][k] = i + j + k;
}

ftime(&time2); /* ending time */

TimeS = time2.time - time1.time; /*difference in seconds*/
TimeMS = time2.millitm - time1.millitm; /*millisecond
adjustment*/

Elapsed_MS = TimeS*1000 + TimeMS; /*elapsed time,
milliseconds*/

printf("%ld, %ld\n", time2.millitm, time1.millitm);
printf("Elapsed time in ms is: %ld\n", Elapsed_MS);
system("PAUSE");
return 0;
}

Java:

class testCvsJava
{
public static void main(String args[])
{
long m1;
long m2;
m1 = System.currentTimeMillis();

int size = 250;
int a[][][] = new int[size][size][size];
int i, j, k;

for(i=0; i<size; i++)
for(j=0; j<size; j++)
for(k=0; k<size; k++)
{
a[j][k] = i + j + k;
}

m2 = System.currentTimeMillis();

System.out.println("Execution time, ms: " + (m2 - m1));
}
}

 

[santosh]

Probably so (despite the occasional claims by Java advocates
about the magic that can be worked via JIT compiling). But -- a
factor of 5 or 10? That's entirely plausible if the Java runtime
system is strictly a byte-code interpreter, as I understand the
early implementations were, but these days most of them do that
JIT compiling to native code, and while compiling isn't free,
it seems to me that if the cost of compiling a class is amortized
over many calls to its methods ....

Well. I don't mean to incite a flame war here -- I use and like
both Java and C -- but .... I wouldn't disagree with "Java is
generally slower, sometimes by a lot", but "Java is generally 5
to 10 times slower" seems to me to be too strong a claim. But I
admit that my perception is based more on anecdote and hearsay
than careful research.

In my experience I have found that Java programs are about 2 to 4 times
slower than equivalent C programs. However their start-up time is _far_
slower compared to their C counterparts, which may be one reason why
many people think they are 5 to 10 times slower. This is of course due
to the overhead of loading the VM and all the necessary classes.

Also speed isn't the only consideration. Java programs consume much more
memory than C or C++ programs. Each Java program, no matter how
trivial, must run with it's own instance of a VM, so if you run several
Java programs simultaneously, you'll find that virtual memory
consumption reaches very high levels, though I'll admit that physical
memory consumed is not so much, though still significantly larger than
what roughly equivalent C/C++ programs would take up.

 

[Robert S]

In my experience I have found that Java programs are about 2 to 4 times
slower than equivalent C programs. However their start-up time is _far_
slower compared to their C counterparts, which may be one reason why
many people think they are 5 to 10 times slower. This is of course due
to the overhead of loading the VM and all the necessary classes.

Also speed isn't the only consideration. Java programs consume much more
memory than C or C++ programs. Each Java program, no matter how
trivial, must run with it's own instance of a VM, so if you run several
Java programs simultaneously, you'll find that virtual memory
consumption reaches very high levels, though I'll admit that physical
memory consumed is not so much, though still significantly larger than
what roughly equivalent C/C++ programs would take up.

Yeah, but of course you can compile java programs to native executable
code with Jet, and produce exe's that run at pretty much the same
speed as C/C++ ones (maybe slightly slower on average), and which
don't need the JRE.

So, the normal byte-code/VM implementation of Java programs is slower,
especially the start-up-time, but the language itself isn't
necessarily (or at least, not by much).

 

[blmblm]

[ snip ]

In my experience I have found that Java programs are about 2 to 4 times
slower than equivalent C programs. However their start-up time is _far_
slower compared to their C counterparts, which may be one reason why
many people think they are 5 to 10 times slower. This is of course due
to the overhead of loading the VM and all the necessary classes.

Start-up time is indeed a significant factor.

Also speed isn't the only consideration. Java programs consume much more
memory than C or C++ programs. Each Java program, no matter how
trivial, must run with it's own instance of a VM, so if you run several
Java programs simultaneously, you'll find that virtual memory
consumption reaches very high levels, though I'll admit that physical
memory consumed is not so much, though still significantly larger than
what roughly equivalent C/C++ programs would take up.

Yes .... It seems to me, though, that it would be feasible for a
JVM implementation to make use of something like shared libraries
in the UNIX world, or DLLs in the Windows world, to reduce memory
use. Whether any actually do -- I guess this group isn't really
the place to ask, is it?

 

[blmblm]

[ snip ]

[ snip ]

Time spent accessing 3D arrays on a modest wintel laptop:

C: 301 ms, Java: 731 ms, Size: 250*250*250
C: 171 ms, Java: 430 ms, Size: 200*200*200

I ran your programs (size 250 only) on a modest Linux desktop and
got -- well, actually they're *not* similar results, but a difference
more in line with the original claim (5 to 10 times slower):

C: 128 ms
Java: 635 ms

I noticed, though, that your Java code includes the allocation
of the array in the time being measured. If I time just the
part of the code that changes the array, I get:

Java, computation only: 121 ms

Whether it's "fair" (whatever that means in context) to include
allocating the array for the Java program but not the C program --
I'm not sure. But it does seem like the difference in overall
runtime isn't related to array access.

I am a bit curious, though, about why you made the array a
global variable in your C program. ?

(I tried making it a local variable in main() and -- as best
I could tell, gcc optimized it out of existence! which makes
a certain amount of sense, since the values placed in the array
are never used. Changing the program to instead use the array
values as input to some meaningless computation got around that,
but I wondered whether you had a similar experience, or your
reason for making it global was something else.)

Which fits in with what I've read about recent benchmarking: Java is
around about 2 to 3 times slower than C at most things.

Nowhere near 5 - 10 times.

Dev-cpp source:

#include <stdio.h>
#include <stdlib.h>
#include <sys/timeb.h>

#define size 250
int a[size][size][size];

int main(int argc, char *argv[])
{
struct timeb time1, time2;
time_t TimeMS; /*millisecond difference*/
time_t TimeS; /*time in seconds*/
time_t Elapsed_MS; /*elapsed time, milliseconds*/

ftime(&time1); /* starting time */

int i, j, k;

for(i=0; i<size; i++)
for(j=0; j<size; j++)
for(k=0; k<size; k++)
{
a[j][k] = i + j + k;
}

ftime(&time2); /* ending time */

TimeS = time2.time - time1.time; /*difference in seconds*/
TimeMS = time2.millitm - time1.millitm; /*millisecond
adjustment*/

Elapsed_MS = TimeS*1000 + TimeMS; /*elapsed time,
milliseconds*/

printf("%ld, %ld\n", time2.millitm, time1.millitm);
printf("Elapsed time in ms is: %ld\n", Elapsed_MS);
system("PAUSE");
return 0;
}

Java:

class testCvsJava
{
public static void main(String args[])
{
long m1;
long m2;
m1 = System.currentTimeMillis();

int size = 250;
int a[][][] = new int[size][size][size];
int i, j, k;

for(i=0; i<size; i++)
for(j=0; j<size; j++)
for(k=0; k<size; k++)
{
a[j][k] = i + j + k;
}

m2 = System.currentTimeMillis();

System.out.println("Execution time, ms: " + (m2 - m1));
}
}