why is C faster than C++ and java?

[san_crazy]

any one please explain it

[laserlight]

This is a topic of much debate, and you should do your research before asking the question. For example, a quick search brings up this debate: C faster than C++ Myth.

[san_crazy]

how could you think that I wouldn't have searched before asking for.? don't explain how to ask smart questions. I've went through the link you have posted already and whatever it says I know.
actually I hoped to get a better reason.

[matsp]

Is it?

I think you have to define under what circumstances - as different languages [using their natural features to solve problems] often lend themselves do different solutions with more or less efficient.

In general, nearly all code written in C++ should be as efficient as code written in C as long as:
1. The goal of the code was to write efficient code (rather than efficient use of the programmers time).
2. The programmer understands what he/she is doing.

Naturally, if we use STL to "help" in speeding up the development, it is possible that it's not quite as fast as the same code written in C by someone with sufficient skill - but it's often not STL's fault, but rather the programmer not understanding how to make STL get the right performance. Recently I wrote a little benchmark comparing C style array and C++ vector. Whilst my results where slightly in favour of array, it was small enough that most people would agree that "it doesn't matter much". Others then tried to replicate my results, and found the STL implementation was actually FASTER - I suspect that some other factors where involved here, but the key being that there's little difference in most things.

Comparing Java in non-native compiled mode with a native compiled environment is like comparing Apples with Bananas - they don't grow in the same climate, they have completely different shape, and taste quite different too. Java tries to solve the problem of needing to compile code for every machine it runs on by having a Java VM in between the actual hardware and the Java code itself - this does consume some extra overhead. Java in Native Compiled mode is quite capable of competing within the same range as C++ - it may not beat C++, but it's not 10x slower - it is 10-20% slower, which for MOST things don't matter, and if it's something that is REALLY critical, it is possible [at the further loss of portability of course] to link Java code with C or C++ code. Of course, it also depends on which compiler we use for each side of the equation.

Some references:
http://www.idiom.com/~zilla/Computer...benchmark.html
http://www.bioinformatics.org/benchmark/results.html
http://www.freewebs.com/godaves/javabench_revisited/
http://shootout.alioth.debian.org/

--
Mats

[laserlight]

how could you think that I wouldn't have searched before asking for.?

You did not tell us anything about what you already knew of the matter.

I've went through the link you have posted already and whatever it says I know.

So what do you know?

actually I hoped to get a better reason.

How do you know that "C (is) faster than C++ and java"? What do you mean when you make such a comparison?

[iMalc]

any one please explain it

Why is green more visually appealing than blue?

See what I did there was make up an absolute yet arbitrary answer in the form of a question, in an attempt to start a flame war.

You think you have a firm grasp of 'how to ask questions the smart way' but you've obviously only skimmed the link in question and haven't really taken any of it in.

[maxorator]

C++ should only be slower when you use C++-specific features. Once I tested an MD5 algorithm in C and one in C++. The speed difference was about 5-6x (!!!). The difference would've been very small or nonexistent when the C code would've been compiled as C++ and then tested.

Java is mostly not run as a machine code application. Instead, Java Runtime Environment (JRE) reads and interprets applications compiled with Java. That is the reason why it is slower.

[zacs7]

However in some cases Java can be faster, especially with just-in-time compiling.

[mike_g]

don't explain how to ask smart questions.

No need to get offended; thats laserlight's signature

[whoie]

Because of Dennis Ritchie. Duh.

He may be a little slower now, but he's one of those quiet types that you have to watch out for. They come out of nowhere...

He's got enough juice to handle Stroustrup and Gosling with some left over.

Ritchie has already solved all of the known problems, and most of the unknown ones. C programming is just unlocking those answers, and that's why it is so much faster than C-- or java. Seriously.

[Sander]

C++ should only be slower when you use C++-specific features. Once I tested an MD5 algorithm in C and one in C++. The speed difference was about 5-6x (!!!). The difference would've been very small or nonexistent when the C code would've been compiled as C++ and then tested.

I find this hard to believe. Either you were comparing different compilers, or something was botched with the comparison.

--
Computer Programming: An Introduction for the Scientifically Inclined

[matsp]

I find this hard to believe. Either you were comparing different compilers, or something was botched with the comparison.

Or simply that one implementation was good and the other not so good? No matter what language you use, you can make good and bad implementations - typically, in C++, it would be pessimisations like passing a vector without const reference when const reference can be used - if you pass around the entire block of data being processed a few times, it can easily take 5x longer than the same code in C [that passed an array -> pointer to the data].

--
Mats

[maxorator]

Well, I went to the MD5 "unofficial homepage", where there were implementations for many languages. I took the ONLY C++ implementation, and chose one of three possible C implmentations. The result was that in C++ the amount of MD5s calculated in one second was around 100 000 - 120 000. In C it was around 600 000. And I found a MASM implementation too, which resulted around 2 000 000 per second.

-------------------------------------------------------------------------------------------------------------------------------------
Edit: My result checking system I used in C and C++ may have affected the results on the previous very old tests due to its ineffectivity. Now I removed result checking and made C and C++ use the same codebase for using the test.

1 900 000 - 1 950 000 --- MASM implementation with result checking and ASCII generating
800 000 - 870 000 --- C implementation with ASCII generating, without result checking
270 000 - 330 000 --- C++ implementation with ASCII generating, without result checking

ASCII generating means generating the strings for brute-force test like "a", "b", ... , "ab", ... , "ba" and so on.
No comments.

[matsp]

I made some tests using the time_trial version in md5-cc "driver.c" and the "L. Peter Deutsch" code.

The C++ code is very old and needed a bit of massaging to get to compile with g++ 3.4.2

I do not get as much difference as maxorator - which may be due to gcc being less optimal, the test-case being different, different processor, or some other variation.

I use -O3 -fomit-frame-pointer (I tested a few other settings too, and this is so far the best one).
Blocks used for testing:
#define TEST_BLOCK_LEN 1000
#define TEST_BLOCK_COUNT 1000000

md5-cc: 5.578 seconds, 179275726 bytes/second
md5-c: 4.124 seconds, 242483026 bytes/second

That makes the C implementation 35% or so faster than the C++ one.
Maxorators results are about 3x difference between C++ and C.

Maxorator: Did you replace the md5::memcpy() and md5::memset() with the standard library variants - that makes a bit of a difference in my tests.

And in the defence of the C++ solution, it makes much less use of macros to provide the calculations. I expect that some work with macros and/or templates could improve the C++ version to equal the C version. Some proper profiling may also help a bit.

--
Mats