Thread 106961431

how can compiled languages be faster or slower than one another? if they all are compiled to machine code, wouldn't they all have more or less same compiled result?

That is mostly true in simple examples, but as examples get larger, you'll see noticeable differences due to the programming language's abstractions, and compilers.
Some programming abstractions cost more instructions in machine code, and different languages will have more or less of these costly abstractions.
Also, some languages simply have better compilers than others, and some languages have abstractions that help the compiler figure out the programmer's intent in order to further optimize the compiled program.

>>106961431 (OP)
It depends on what kind of machine code they get compiled to.
Go's compiler, for example, doesn't spend much time optimizing the code and produces quite suboptimal code as a result. The makers of the language try to sell it as a feature (fast compile times!).

Ada for example has to insert lots of runtime checks for things like array bounds checking. Rust usually doesn't because it can prove they're not needed at compile time, C doesn't because it was invented before anyone cared about memory safety.

>>106961431 (OP)
Optimizing compilers performing different optimizations, language specification may prevent some optimizations. Standard libraries having different algorithms.

>>106961431 (OP)
Some compilers are better at optimizing than others.

>>106961431 (OP)
I fucking wish this was the case and then the world could be rid of C cancer.

>>106961431 (OP)
Technically shipping python source code as a giant char* with the python interpreter would count as a "compiled language". It's an extreme example to illustrate the point that high you could still have a high level language that is compiled and the further you move away from assembly the more runtime type checks etc the compiler will have to write.

>>106961619
Compiler optimizations are probably responsible for 5% of performance benefits to better management techniques which go doesn't have either. For the use case go is targeting I would also probably favor compilation speed over performance.

>>106961431 (OP)
Different language features => different implementations => different machine code.

>>106961827
That's fucking complicist you right wing biggot nazi /s

There aren't really "faster languages". There are faster compilers of course, and there are faster ways of writing the same algorithm. And a language can push you to implement things a certain way, hence making your code faster or slower. But you could write the exact same algorithm in a bunch of different languages, then a sufficiently intelligent compiler could compile it to identical code. The language itself isn't making your code slow. This is an important point because in "benchmark games" people will attempt to compare languages based on how fast their code is. But all they're really comparing is the compiler, and their own ability to write code that it can compile to good machine code. They aren't testing, for example, how good the compiler is at taking idiomatic code and compiling it to performant code.

>>106963664
>There aren't really "faster languages", bro
>If you had a magical compiler that circumvents Rice's theorem, it could prove that a program built out of wasteful constructs and overly general constructs is equivalent to hand-optimized assembly that does the same

>>106964027
You don't really need a "magical" compiler for this. This is how emscripten works. Recognize "(x|0) + (y|0)" as being equivalent to integer addition in c and compile it as such. You can't compile any program optimally, but you can compile specially written programs this way.

>>106961431 (OP)
haha OP I love froggo XD