language speed

[Mr Mr]

When I hear phrases like, "C++ is faster" than higher level languages, I'm not sure what it means.

More specifically, when compiling a C++ program, it's converted into an executable (machine language) file before it can be run?

However, when compiling a higher level language, is it not also converted to an executable file (in machine language)?

So if all languages are converted to machine language before they're running, why is C++ faster?

This is the best way I can think to ask this question — maybe I should have asked it differently.

[ericM]

Yes, when you compile you program it is converted in a binary file that run on a certain architecture. And of course, when you use an interpreted language, all your instructions are moved into binary representation and then executed (and this explain why an high level interpreted language is generally slower then c++).
However when you compile an higher level language (let's say python) you do not lose any time with the interpreter.
On the other hand, c++ is designed to be very flexible, so the compiler can produce optimised code and, more important, the programmer can implement certain operation more efficiently (since you have access to low-level features).
The school example are pointers and pointers arithmetic, which you use al the time with c++ and I've never seen in use in real-world python code.

[Ganado]

I don't really have a good answer to this, and will probably leave out important details, but I'll give a few bullets.

First, it's apples to oranges to compare a compiled language to an interpreted one. The interpreted one will be slower.

Then, there are languages that produce bytecode that is Just-in-Time (JIT) compiled into machine code. Theoretically, JIT compilation could produce code that is faster than just static compilation because it has more available runtime information. However, I don't know if this is reality or not. Probably depends on how good the JIT compiler is.

The closest thing to compare C++ is other native-compiled languages, such as Rust. In some cases, I've heard Rust matches C++ in speed, but there are various things that C++ (with the GCC compiler) is still better at. Newer languages also probably have libraries that aren't as optimized.

https://stackoverflow.com/questions/13853053/what-makes-c-faster-than-python

But it's not even just about interpretation vs JIT vs native compilation. There do exist compilers for languages like Python, but the speed still probably won't be equivalent to C or C++. It's also about the philosophy of the language. C++'s design allows for abstraction while still keeping performance. It uses things like RAII, and has no built-in garbage collection. Other languages, such as C# and Java, can do things differently. For example, they manage memory with a garbage collector. I assume objects in C# and Java are bigger because everything inherits from Object, while this concept does not exist in C++.

Also, hand-crafted benchmarks can be misleading, because C and C++ are probably the best at doing nitty-gritty hand [micro-]optimizations. But a good reason for why that's true, I'm not really sure how to explain.

Hope someone else knows more specifics than me.

[mbozzi]

So if all languages are converted to machine language before they're running

It hasn't been said yet, so I'll say it: there isn't a requirement to convert an program to machine code before doing what it says. Consider this simple source code in the imaginary language IM++:

print("Hello world\n");

One could certainly write a C++ program to say "Hello world" as it instructs, without ever converting the IM++ program into machine language. This is called interpretation. Most interpreters handle more complicated inputs -- Python source code, for example -- but the idea is the same.

Still, it's not meaningful to compare the resource efficiency of languages. The only comparison that means anything is the bottom line - the resource demands of two complete solutions to the same problem.

When one says that "language X is faster than language Y", the intent might be one or both of
- It is easier to write a faster program with some implementation of X; or
- It is possible to write a faster program in some implementation of X.

It may be easier to write a faster program with an implementation of language X because it lets you write a fast solution without breaking your back optimizing by hand. Maybe it more readily transforms an easy-to-write, slow solution into a fast one. Or maybe X makes it more simple and natural to write an efficient solution.

Similarly, it might be possible to write a faster program with an implementation of X, because it has a performance-critical feature that Y doesn't, or because one implementation makes a profitable assumption the other doesn't.

[Mr Mr]

Thanks, people. That helps a lot.

[Peter87]

C++ doesn't automatically make your program fast. If you don't know what you are doing it might even end up being worse. But what it gives you is control. In a language like Java you can't pass class objects by value, you cannot even store a class object on the stack, and you cannot store an object directly inside another object so you end up using a lot of references. This makes it difficult to write very compact programs that are truly cache friendly. Being able to do these things has some consequences, and it wouldn't work very well with how Java handles the lifetime of objects, but in C++ you have the choice and it is up to you to choose what is right for your situation.