Why use C++ instead of Java?

[fdm]

I have a few years of experience with java and c++. I have read that java is
slower than c++ and thats why c++ is often used in eg. graphics applications
instead of java.

But what is it that makes c++ faster and is it really so much faster
(considering how fast the hardware has developed in the last few years)?

I know a lot of current code/libraries are written in c++ but if we neglect
this fact and only look at which language to use for future applications.

 

[fdm]

I have a few years of experience with java and c++. I have read that java
is slower than c++ and thats why c++ is often used in eg. graphics
applications instead of java.

But what is it that makes c++ faster and is it really so much faster
(considering how fast the hardware has developed in the last few years)?

I know a lot of current code/libraries are written in c++ but if we
neglect this fact and only look at which language to use for future
applications.

I have read that:

interpreted Java runs something like 20 times slower than C.

but what is the iterpretation and why does it make java so much slower?

 

[Krice]

But what is it that makes c++ faster

Magic. No, really, you have to try both and see which one is
faster.

 

[Christof Donat]

Hi,

I have a few years of experience with java and c++. I have read that java
is slower than c++ and thats why c++ is often used in eg. graphics
applications instead of java.

But what is it that makes c++ faster and is it really so much faster
(considering how fast the hardware has developed in the last few years)?

Java needs to be interpreted or JIT compiled, while C++ is compiled directly
into machine code. At compile time the compiler with knowledge of the CPU
can heavily optimize the code which is not possible in a JIT, that has much
stricter run time requirements.

It depends on what you compare.

There are shootouts that compare C++ code compiled for a 386 with 387 FPU
with Suns Hot Spot engine on a current CPU. Since the java engine knows the
CPU that it is running on, it can optimize for the MMX and SSE units and the
more subtle issues of that specific CPU. Those shootouts are usually used to
"prove" that java was faster than C++.

If your compiler optimizes your C++ code for the CPU it will be running on,
the compiler still can do more sophisticated optimizations that a Java JIT
never will be able to do in the short time it has for compilation.

There are also some things in the languages. Java is a more dynamic language
than C++. A C++ compiler can e.g. do heavy inlining of non virtual methods.
In java all methods are what a C++ virtual method would be. Templates are
completely interpreted at compile time, where generics are more or less a
feature for mass casting, which needs run time support in Java. there are
many more sometimes subtle differences in the languages, where well written
C++ code is better for compiler optimizations than java code can ever be
without loosing the promises the language gives to the programmer.

Of course last, not least C++ lets the programmer decide about memory
management. That makes things more complicated for the programmer, but on
the other hand he can decide for the memory management that is optimal for
his code. A small shell util that uses a fixed block of memory every time it
runs may need no memory management at all. There is no way to do that with
Java, the GC is always there. Another application may be best of with pooled
memory management - no chance with Java.

I know a lot of current code/libraries are written in c++ but if we
neglect this fact and only look at which language to use for future
applications.

It depends on the application. There is no universal answer to your
question. There are applications that are best written in Python, or in
Perl, others are better in C++, C, or even in Assembler. Does your
application need the performance, C++ delivers? Is the Platform it runs on
known at compile time, or can there be a reasonable guess? What is the
environment it should run in? Can it profit from things like a EJB Container?
What kind of developers do you have at hand?

Christof

 

[Christof Donat]

Hi,

I have read that:

interpreted Java runs something like 20 times slower than C.

I'm pretty sure, that that is wrong. Maybe if you use what C++ gives you you
can gain a factor of 2 compared to a modern java engine, but not much more.
those numbers can only come up when the java engines needs too much memory
and the system starts swapping. Java typically needs more memory than equal
C++ code.

but what is the iterpretation and why does it make java so much slower

Maybe you should start learning the basics before trying to decide about the
programing language for a project. There are basically three types of
language implementations.

1. compiled languages like C++: The compiler creates machine code which is
then run directly every time the program starts.
2. interpreted languages like e.g. Python: every time the program is
started, the original code in the programming language is loaded, parsed and
then transferred to Machine code. Simple implementations execute the code
along the lies as they read it. More sophisticated once use a "just in time"
Compiler, that compiles the code at the start to machine code and executes
that.
3. Hybrid languages like Java: The Compiler generates an intermediate code
that is optimized for fast interpretation instead of readability for humans.
that intermediate code is then run in an interpreter for that intermediate
language.

When a language is compiled, it runs as fast as possible on the machines it
has been compiled for. On the other hand, interpreter languages can run on
any platform an interpreter exists. Python code runs with no recompilation
or any other change on a mainframe as well as on a mobile phone. Hybrid
systems (Java, .Net, Pascal p-code, etc.) are faster than usual
interpreters, because they can rely on a code that is close to typical
machine codes, but keep the advantage of being portable. Still they can not
reach the performance of a compiled program that is optimized for that
platform.

Of course there are languages with different implementations available. There
are e.g. Pascal compilers as well as the p-code system. With gcj there is
also a java compiler that generates machine code instead of the intermediate
code. Even for interpreter languages like Python I have seen Compilers and I
remember to have read about a C++ interpreter (whoever wants that). With
llvm there exists a interpreter for an intermediate code that can be used
with C++ as well.

The distinction I gave is not really as strict as it might seem. e.G. llvm
is AFAIK much closer to the machine as the java or the .Net virtual
machines. On the other hand there are languages that are designed to be
interpreted and typical programs don't gain too much performance when a
compiler is used. So sometimes using an interpreter that knows the machine
at run time can be faster than compiled code. The distinction is more a
guideline than a strict distinction.

Christof

 

[Juha Nieminen]

Java needs to be interpreted or JIT compiled, while C++ is compiled directly
into machine code. At compile time the compiler with knowledge of the CPU
can heavily optimize the code which is not possible in a JIT, that has much
stricter run time requirements.

One factor which makes C++ faster is that it's an "unsafe" language.
This means that clock cycles are not spent on boundary checks and other
such checks which, in a bug-free program, are 100% useless overhead.

Of course many people don't like to program in an "unsafe" language,
so your mileage may vary.

C++ is not faster than Java in everything. Memory allocation in most
systems is considerably slower in C++ (and C) than in java. (OTOH Java
lives on constant memory allocation due to how the language works, while
most C++ programs don't.)

It depends on what you compare.

There are shootouts that compare C++ code compiled for a 386 with 387 FPU
with Suns Hot Spot engine on a current CPU. Since the java engine knows the
CPU that it is running on, it can optimize for the MMX and SSE units and the
more subtle issues of that specific CPU. Those shootouts are usually used to
"prove" that java was faster than C++.

You don't even have to resort to such dirty trickery to "prove" it.
Just make a program which allocates 10 million small objects dynamically
in both languages, and there you go: You have proven Java to be vastly
faster than C++.

 

[SG]

  You don't even have to resort to such dirty trickery to "prove" it.
Just make a program which allocates 10 million small objects dynamically
in both languages, and there you go: You have proven Java to be vastly
faster than C++.

Done.

sg@home:~/ccpp/perform$ time ./a.out

real 0m0.972s
user 0m0.776s
sys 0m0.196s

sg@home:~/ccpp/perform$ time java alloc

real 0m4.130s
user 0m4.516s
sys 0m0.596s

Oh my!

Cheers!
SG

 

[Juha Nieminen]

sg@home:~/ccpp/perform$ time ./a.out

real 0m0.972s
user 0m0.776s
sys 0m0.196s

sg@home:~/ccpp/perform$ time java alloc

real 0m4.130s
user 0m4.516s
sys 0m0.596s

I assume you are not using gcc? Or you are using your own specialized
allocator?

 

[Jonathan Lee]

But what is it that makes c++ faster and is it really so much faster
(considering how fast the hardware has developed in the last few years)?

Consider that OpenJDK is written in C++. I think that pretty much sums
up the C++ vs Java argument right there.

--Jonathan

 

[Jerry Coffin]

I have a few years of experience with java and c++. I have read that java is
slower than c++ and thats why c++ is often used in eg. graphics applications
instead of java.

Java isn't _necessarily_ slower than C++ (you can write arbitrarily
slow code in either one) but on average, code written in C++ is
_probably_ somewhat faster than code written in Java. It's a bit hard
to say how much of that is due to the language itself, and how much
is basically a self-fulfilling prophecy -- since it has a reputation
for being slower, people who are likely to be really careful to write
the fastest possible code may be a bit more likely to choose C++ over
Java to start with.

For graphics, most of what you need is a binding to something like
DirectX or OpenGL, that lets most of your code run on the graphics
hardware. There's a JOGL project to provide OpenGL bindings for Java.
There's also Java3D, which can use OpenGL to do the 3D work. Testing
tends to indicate that as a general rule, DirectX code can run around
twice as fast as OpenGL code -- and I don't believe anybody has a
(reasonably current) implementation of Java with DirectX bindings.

Whether that matters to you in a specific application will depend a
lot on whether you're willing/able to restrict the code to running on
Windows -- if you need portability, you have to use OpenGL anyway.

But what is it that makes c++ faster and is it really so much faster
(considering how fast the hardware has developed in the last few years)?

Faster hardware doesn't really make any difference in itself. A CPU
that's twice as fast should generally run code twice as fast,
regardless of the language in which it was written. OTOH, for
caching, locality of reference can make a big difference. C++ and a
(currently typical) JVM both compile to machine code, but the JVM has
to do it at run-time, so there's usually a limit on the optimizations
that are practical. Nonetheless, in this respect, differences are
usually quite small.

Data is open to more question. In Java, a _much_ greater percentage
of data tends to be dynamically allocated, which _tends_ to reduce
locality of reference. OTOH, a copying garbage collector will
normally move the objects (that are still in use) so they will be
located contiguously with each other.

Some particular program might favor one or the other, but minor
changes in its memory usage could easily change which one -- and few
programmers use memory the same in the two languages anyway, so most
comparisons have some degree of unfairness anyway.

 

[James Kanze]

I have a few years of experience with java and c++. I have
read that java is slower than c++ and thats why c++ is often
used in eg. graphics applications instead of java.

But what is it that makes c++ faster and is it really so much
faster (considering how fast the hardware has developed in the
last few years)?

It depends on the application, but the choice between C++ and
Java is rarely made on the grounds of performance. There are
certain things at which C++ will be faster, and others where
Java will be faster, but for most applications, it doesn't
matter. In general, C++ is chosen because it can do more than
Java---it costs less to develop a robust application in C++ than
it does in Java.

I know a lot of current code/libraries are written in c++ but
if we neglect this fact and only look at which language to use
for future applications.

It depends a lot on the application. In certain domains, there
is a very important infrastructure available to support Java; if
you use C++, you have to somehow duplicate this. Outside of
those domains, C++ has the advantage of being a more powerful
language.

 

[Joshua Maurice]

Hi,




I'm pretty sure, that that is wrong. Maybe if you use what C++ gives you you
can gain a factor of 2 compared to a modern java engine, but not much more.
those numbers can only come up when the java engines needs too much memory
and the system starts swapping. Java typically needs more memory than equal
C++ code.

It's right, I think. Interpreted Java / interpreted Java bytecode is
probably that much slower. It's just that no one interprets Java. They
use Java bytecode and JIT, Just In Time compilation, where it tends to
be 1x to 4x slower, depending on how well the code is written, how
much abstraction is used, and the actual problem being solved.

 

[Joshua Maurice]

Done.

  sg@home:~/ccpp/perform$ time ./a.out

  real  0m0.972s
  user  0m0.776s
  sys   0m0.196s

  sg@home:~/ccpp/perform$ time java alloc

  real  0m4.130s
  user  0m4.516s
  sys   0m0.596s

Oh my!

At least be marginally fair and run with java -client and java -
server, and possibly with a slightly larger test to try and balance
out the startup costs of -server. It defaults to -client, which is
like ~6 slower for the last random application I was testing. -client
has a smaller memory footprint and starts up quicker, but it's a lot
slower, on average.

 

[James Kanze]

One factor which makes C++ faster is that it's an "unsafe"
language. This means that clock cycles are not spent on
boundary checks and other such checks which, in a bug-free
program, are 100% useless overhead.

That's not true. C++ makes many things "undefined behavior",
where Java requires a specific behavior (usually the wrong
behavior), but "undefined behavior" means that an implementation
is free to do whatever is best for its users, and all of the
implementations I regularly use (now that I'm no longer using
Sun CC) do implement bounds checking, at least for the standard
containers.

Of course many people don't like to program in an "unsafe"
language, so your mileage may vary.

C++ is not faster than Java in everything. Memory allocation
in most systems is considerably slower in C++ (and C) than in
java. (OTOH Java lives on constant memory allocation due to
how the language works, while most C++ programs don't.)

You don't even have to resort to such dirty trickery to
"prove" it. Just make a program which allocates 10 million
small objects dynamically in both languages, and there you go:
You have proven Java to be vastly faster than C++.

More realistically, tell me which language you want to win, and
I'll write a benchmark which "proves" it to be faster. For
Java, lots of array accesses with arrays of basic types, with
the arrays passed to functions for the actual work; for C++,
just change the type of the array member to a very simple struct
(which means that every element must be individually allocated
in Java), with many short lived (but large) arrays.

 

[Juha Nieminen]

It depends on the application, but the choice between C++ and
Java is rarely made on the grounds of performance. There are
certain things at which C++ will be faster, and others where
Java will be faster, but for most applications, it doesn't
matter. In general, C++ is chosen because it can do more than
Java---it costs less to develop a robust application in C++ than
it does in Java.

In some cases you simply don't have a choice. (Developing for the
iPhone is a good example.)

 

[Brian Wood]

for C++,
just change the type of the array member to a very simple struct
(which means that every element must be individually allocated
in Java), with many short lived (but large) arrays.

The results here may be relevant --
bannalia.blogspot.com/2008/09/profiling-stablevector.html.

The comment about short-lived, large arrays reminds me
of a vector that is out growing it's capacity and has
to copy it's contents into a new block.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[Carlo Milanesi]

It depends on the application, but the choice between C++ and
Java is rarely made on the grounds of performance. There are
certain things at which C++ will be faster, and others where
Java will be faster, but for most applications, it doesn't
matter.

Are you sure?
I think that for embedded application the smaller memory footprint of
C++ is important.
And I think that for real-time applications it is required deterministic
time for memory allocation and deallocation that Java cannot provide.
And how come most CAD/CAM/CAE/GIS packages and most office productivity
tools are still developed in a natively compiled language?

In general, C++ is chosen because it can do more than
Java---it costs less to develop a robust application in C++ than
it does in Java.

Surely C++ can do more than Java: embedding assembly language,
interfacing with hardware, operating systems API or libraries that do
not support Java yet. But could you explain why does it cost less to
develop a robust application in C++ than it does in Java? Have you
references to support this statement?

 

[Chris M. Thomasson]

[...]

C++ is not faster than Java in everything. Memory allocation in most
systems is considerably slower in C++ (and C) than in java. (OTOH Java
lives on constant memory allocation due to how the language works, while
most C++ programs don't.) [...]
You don't even have to resort to such dirty trickery to "prove" it.
Just make a program which allocates 10 million small objects dynamically
in both languages, and there you go: You have proven Java to be vastly
faster than C++.

IMVHO, you're assertions are wrong Juha. Take this Java code:


http://pastebin.com/f7361735b


vs this C++ code:

http://pastebin.com/f36011b3b




On my old P4 3.06gz w/ 512mb ram I am getting the following output using
Unix `time' command:




C++ version - gcc (GCC) 3.4.5 (mingw special)
______________________________________________________________________
$ time ./test

real 0m19.766s
user 0m0.015s
sys 0m0.031s




Java version - java version "1.6.0_05"
______________________________________________________________________
$ time java tree
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at tree.create_tree(tree.java:13)
at tree.create_tree(tree.java:14)
at tree.create_tree(tree.java:14)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:14)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:14)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:14)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:14)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.create_tree(tree.java:15)
at tree.main(tree.java:25)

real 0m3.367s
user 0m0.015s
sys 0m0.031s





Why is Java so crappy at memory management? I mean, I am able to make the
program work using C++ and a crappy little region allocator I whipped up. On
the other hand, Java simply runs out of memory and crashes! WTF is up with
that non-sense!?!?!?!?!

OUCH!


Am I doing something wrong in the Java version????


;^/






Well, I suppose I could create a cached allocator in Java, but won't that
completely defeat the purpose of not having to use manual memory management
in a garbage collected environment? I mean, you would have to explicitly
allocate/free objects from/to the cache. That's sounds manual to me!


;^)






BTW, the region allocator in the C++ code can be greatly improved upon. For
instance, why the heck am I using `std::list'?!?!? That's stupid because
it's going to be making extra allocations. I should use a simple intrusive
linked-list instead. But, you know, I wanted to give Java a fighting
chance...

;^o

 

[DDD]

[...]

 C++ is not faster than Java in everything. Memory allocation in most
systems is considerably slower in C++ (and C) than in java. (OTOH Java
lives on constant memory allocation due to how the language works, while
most C++ programs don't.) [...]
 You don't even have to resort to such dirty trickery to "prove" it.
Just make a program which allocates 10 million small objects dynamically
in both languages, and there you go: You have proven Java to be vastly
faster than C++.

IMVHO, you're assertions are wrong Juha. Take this Java code:

http://pastebin.com/f7361735b

vs this C++ code:

http://pastebin.com/f36011b3b

On my old P4 3.06gz w/ 512mb ram I am getting the following output using
Unix `time' command:

C++ version  -  gcc (GCC) 3.4.5 (mingw special)
______________________________________________________________________
$ time ./test

real    0m19.766s
user    0m0.015s
sys     0m0.031s

Java version  -  java version "1.6.0_05"
______________________________________________________________________
$ time java tree
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at tree.create_tree(tree.java:13)
        at tree.create_tree(tree.java:14)
        at tree.create_tree(tree.java:14)
        at tree.create_tree(tree.java:15)
        at tree.create_tree(tree.java:15)
        at tree.create_tree(tree.java:14)
        at tree.create_tree(tree.java:15)
        at tree.create_tree(tree.java:15)
        at tree.create_tree(tree.java:14)
        at tree.create_tree(tree.java:15)
        at tree.create_tree(tree.java:14)
        at tree.create_tree(tree.java:15)
        at tree.create_tree(tree.java:15)
        at tree.create_tree(tree.java:15)
        at tree.create_tree(tree.java:14)
        at tree.create_tree(tree.java:15)
        at tree.create_tree(tree.java:15)
        at tree.create_tree(tree.java:15)
        at tree.create_tree(tree.java:15)
        at tree.create_tree(tree.java:15)
        at tree.create_tree(tree.java:15)
        at tree.main(tree.java:25)

real    0m3.367s
user    0m0.015s
sys     0m0.031s

Why is Java so crappy at memory management? I mean, I am able to make the
program work using C++ and a crappy little region allocator I whipped up. On
the other hand, Java simply runs out of memory and crashes! WTF is up with
that non-sense!?!?!?!?!

OUCH!

Am I doing something wrong in the Java version????

;^/

Well, I suppose I could create a cached allocator in Java, but won't that
completely defeat the purpose of not having to use manual memory management
in a garbage collected environment? I mean, you would have to explicitly
allocate/free objects from/to the cache. That's sounds manual to me!

;^)

BTW, the region allocator in the C++ code can be greatly improved upon. For
instance, why the heck am I using `std::list'?!?!? That's stupid because
it's going to be making extra allocations. I should use a simple intrusive
linked-list instead. But, you know, I wanted to give Java a fighting
chance...

;^o

In a nutshell, java needs a virtual machine, which occupies at least
300M memories itself.

 

[Chris M. Thomasson]

In a nutshell, java needs a virtual machine, which occupies at least
300M memories itself.

Well, damn. IMVHO, the Java version should be able to run on my old platform
as-is. Piece of shi%.