Ogre Forums

Is the C++ the fastest programming language in performance ?

Who is faster ? C++ or C# ?

Do they have the same speed ?

It depends.

xsx wrote:Is the C++ the fastest programming language in performance ?

Is your other topic not good enough?

What is C#? Answer that question and you've answered your own original question.

[humor]
The fastest language is the Troll language.
[/humor]

The fastest language is Assembly.
Everything has to become assembly at some point since that's all the cpu can execute.

However 99% of programmers are far worse at writing efficient assembly than an optimising compiler for a higher level language.

For a software that equals a few hundred thousand lines of C++ assembly isn't going to produce the fastest program. Depending on the program it might even be practically impossible to code it in assembly at all for every programmer in existance. Obviously, the closer to the hardware a language is the more one can optimize code with it (with good knowledge of the hardware). But as programs get more complex more abstraction is needed to make things manageable for humans.

jjp: That's a very good point actually. People always say assembly is the fastest language, but for a practical project, it would get impossible to manage without strict coding methodologies to keep things tidy. But then, you'll find that a C++ compiler can take code that's even more readable, and produce compiled code that's even more efficient, simply because it can perform automated optimizations throughout the machine code it compiles that you would drive yourself insane trying to maintain in a hand-coded assembly app.

The same thing actually applies to other languages, in that for certain tasks, C# may very well be "practically" faster than C++ for example. However, I do know that for games, C++ seems to be the fastest overall, probably because (in most benchmarks) it's many times faster than most other languages when it comes to mass data computations.

Also, keep in mind that saying "language A" is faster than "language B" is somewhat misleading; depending on the compilers/interpreters used, speeds will vary greatly. For example, MS Visual C# is overall a little faster than GCC / MingW C++ I believe, but MS Visual C++ beats all of them by a good margin.

BTW, I sometimes find it funny how people sometimes still say how C++ is slow compared to C because "higher level languages are inherently less efficient". If you look at modern benchmarks though, you'll probably be surprised to find that C++ is actually faster than C most cases. I think that because C++ is a higher level language, more information is supplied to the compiler (like const, etc.), and therefore better optimizations can be performed when compiling.

"const" has no impact on performance. The same code is generated for both const and non-const methods and parameters. The only difference is compile-time support against modifying const objects and pointers/references.

Now, if you meant to say "restrict" and "volatile" then you are on to something.

"const" has no impact on performance. The same code is generated for both const and non-const methods and parameters. The only difference is compile-time support against modifying const objects and pointers/references.

Really? Then why does this compile: But not this:

Anyway the point is C++ has a lot more language features, which when used properly, can result in faster executables than equivalent C code, according to most benchmarks

Best example: C++'s sort vs. C's qsort. C++ wins the game because it can inline a comparison functor. C has to use a function pointer.

But that's really more cosmetics. For all practical purposes, you should take the language which you think makes your specific job the easiest to do *for you*. And in most cases it doesn't matter if your implementation is 10x slower (constant factor, not complexity) than someone else might have managed with a different language because it won't be noticable. There are, of course, exceptions

In the end the programmer's time is more precious than computation time At least most of the time.

I think lets stick to the original question: what is the fastest language? I think it is machine code, err can that be considered as a language?

x86 machine code gets runtime (just-in-time?) "compiled"/interpreted into microcode, which the processor then executes. Provided the x86 opcode semantics hold, it can do lots of fancy optimizations and parallelization tricks. I'm guessing all the other processor types do something similar to maintain opcode compatibility across hardware versions. So yes, raw machine code would be considered a language if you were programming processors.

Kinda like a very loosely typed, low level scripting language since everything's a number or a pointer?

syedhs wrote:I think lets stick to the original question: what is the fastest language?

I think the original question makes no sense. It is too general. Or, the only possible answer is: it depends, there is no language that is fastest for every possible program.

Well, you asked for it:

The fastest language is FL 2000 (FastLanguage 2000)! Its so fast, the program gives output before you enter your input. Cool!

JohnJ wrote:

"const" has no impact on performance. The same code is generated for both const and non-const methods and parameters. The only difference is compile-time support against modifying const objects and pointers/references.

Really? Then why does this compile:

Code: Select all

const int size = 10;
char array[size];

But not this:

Code: Select all

int size = 10;
char array[size];

Your conundrum is irrelevant to the (lack of a) performance impact of the const keyword.

I thought compilers could make more assumptions about const variables, which allows them to optimize better?

nikki wrote:Well, you asked for it:

The fastest language is FL 2000 (FastLanguage 2000)! Its so fast, the program gives output before you enter your input. Cool!

NOP2k is far superior to FL 2000! All language features are expressed as NOPs, and it has a revolutionary NOP-optimising compiler that can speed up your program a thousand fold!

It also doesn't have the reality warping, time paradox side effects of FL 2000 if someone distracts your coding mid-function. Plus it also doesn't attract Daleks.

nullsquared wrote:I thought compilers could make more assumptions about const variables, which allows them to optimize better?

There are no assumptions about const that could have a performance impact. Like I said, though, "restrict" and "volatile" are two keywords that *do* have a performance impact.

"const" in C++ is a language feature that allows code authors to enforce semantic usage of their APIs, is all.

JohnJ wrote: Really? Then why does this compile:

Code: Select all

const int size = 10;
char array[size];

But not this:

Code: Select all

int size = 10;
char array[size];

The answer, btw, is that the language requires array subscripts, when declaring an array, to be constant at compile time.

Yeah, I know why, I was just trying to make the point that "const" is a little more than a compile-time enforcement of variable const-ness . You're probably right about it having no performance impact in most cases though, but it still seems logical that compilers at least should be able to do some extra optimization when encountering const variables. Either way, I still use it, for code correctness as well as theoretical optimization "potential" .

Anyway, this is getting off topic, although the original question has pretty much been answered; C++ is generally faster than C#, and just about everything else, with a good compiler (like MS Visual C++).

Maybe the const keyword has a performance impact - it still is better to pass const reference than a object copy if you need the method to not modify the original object.

My 2 cents: Whatever you do, there is no chance that byte-code oriented languages will outperform statically compiled once in both speed and memory requirements. (One exception is that the bytecode compiler can optimize for the more likely happening code paths, which is also kind-of possible on GCC with some keywords by hand). Although java seems to outperform C++ in some random cases (generally it doesn't), it eats a whole lot more memory while doing so. And we're not talking about the lazy garbage collector which makes the situation even worse. JIT is fun and all, but isn't it all just a waste of CPU cycles? (I understand it means practically zero portability costs)

Edit: Oh I see now the OP asked about C#. Without knowing it much, I'd say the same applies - slower startup with JIT (or worse performance with pre-JIT'ed binaries ).

Interesting article on "const optimization": http://www.gotw.ca/gotw/081.htm from Herb Sutter. Short version: xavier is right; const doesn't help.

I think Herb Sutter points that you shouldn't really be focusing on compiler optimization for const keyword whereas the biggest advantage is actually more to human. There are still possibility of optimizations on const like one case below:- versus if the last line can be simplified to int i = 70; for the latter code version.