Suppose a program was written in two distinct languages, let them be language X and language Y, if their compilers generate the same byte code, why I should use language X instead of the language Y? What defines that one language is faster than other?
I ask this because often you see people say things like: "C is the fastest language, ATS is a language fast as C". I was seeking to understand the definition of "fast" for programming languages.
There are many reasons that may be considered for choosing a language X over a language Y. Program readability, ease of programming, portability to many platforms, existence of good programming environments can be such reasons. However, I shall consider only the speed of execution as requested in the question. The question does not seem to consider, for example, the speed of development.
Two languages can compile to the same bytecode, but it does not mean that the same code will be produced,
Actually bytecode is only code for a specific virtual machine. It does have engineering advantages, but does not introduce fundamental differences with compiling directly for a specific harware. So you might as well consider comparing two languages compiled for direct execution on the same machine.
This said, the issue of relative speed of languages is an old one, dating back to the first compilers.
For many years, in those early times, professional considered that hand written code was faster than compiled code. In other words, machine language was considered faster than high level languages such as Cobol or Fortran. And it was, both faster and usually smaller. High level languages still developed because they were much easier to use for many people who were not computer scientists. The cost of using high level languages even had a name: the expansion ratio, which could concern the size of the generated code (a very important issue in those times) or the number of instructions actually executed. The concept was mainly experimental, but the ratio was greater than 1 at first, as compilers did a fairly simple minded job by today standards.
Thus machine language was faster than say, Fortran.
Of course, that changed over the years, as compilers became more sophisticated, to the point that programming in assembly language is now very rare. For most applications, assembly language programs compete poorly with code generated by optimizing compilers.
This shows that one major issue is the quality of the compilers available for the language considered, their ability to analyse the source code, and to optimize it accordingly.
This ability may depend to some extend on the features of the language to emphasize the structural and mathematical properties of the source in order to make the work easier for the compiler. For example, a language could allow the inclusion of statements about the algebraic properties of user defined functions, so as to allows the compiler to use these properties for optimization purposes.
The compiling process may be easier, hence producing better code, when the programming paradigm of the language is closer to the features of the machines that will intepret the code, whether real or virtual machine.
Another point is whether the paradigms implemented in the language are closed to the type of problem being programmed. It is to be expected that a programming language specialized for specific programming paradigms will compile very efficiently features related to that paradigm. Hence the choice of a programming language may depend, for clarity and for speed, of the choice of a programming language adapted to the kind of problem being programmed.
The popularity of C for system programming is probably due to the fact that C is close to the machine architecture, and that system programming is directly related to that architecture too.
Some other problem will be more easily programmed, with faster execution using logic programming and constraint resolution languages.
Complex reactive systems can be very efficiently programmed with specialized synchronous programming languages like Esterel which embodies very specialized knowledge about such systems and generate very fast code.
Or to take an extreme example, some languages are highly specialized, such as syntax description languages used to program parsers. A parser generator is nothing but a compiler for such languages. Of course, it is not Turing complete, but these compilers are extremely good for their specialty: producing efficient parsing programs. The domain of knowledge being restricted, the optimization techniques can be very specialized and tuned very finely. These parser generators are usually much better than what could be obtained by writing code in another language. There are many highly specialized languages with compilers that produce excellent and fast code for a restricted class of problems.
Hence, when writing a large system, it may be advisable not to rely on a single language, but to choose the best language for different components of the system. This, of course, raises problems of compatibility.
Another point that matters often is simply the existence of efficient libraries for the topics being programmed.
Finally, speed is not the only criterion and may be in conflict with other criteria such as code safety (for exemple with respect to bad input, or resilience to system errors), memory use, ease of programming (though paradigm compatibility may actually help that), object code size, program maintainability, etc.
Speed is not always the most important parameter. Also it may take different guises, like complexity which may be average complexity or worse case complexity. Also, in a large system as in a smaller program, there are parts where speed is critical, and others where it matters little. And it s not always easy to determine that in advance.
While everything is eventually run on the CPU*, there are various differences between different languages. Here are some examples.
Interpreted languages Some languages are interpreted rather than compiled, for example Python, Ruby and Matlab. That means that Python and Ruby code doesn't compile to machine code, but rather is interpreted on-the-fly. It is possible to compile Python and Ruby to a virtual machine (see next point). See also this question. Interpreted is generally slower than compiled code for various reasons. Not only can interpretation itself be slow, it is also harder to do optimizations. However, if your code spends most of the time on library functions (the case of Matlab), performance won't suffer.
Virtual machine Some languages are compiled into bytecode, an invented "machine code" which is then interpreted. The quintessential examples are Java and C#. While bytecode can be converted to machine code on the fly, the code will probably still run slower. In the case of Java, a virtual machine is used for portability. In the case of C#, there might be other concerns such as security.
Overhead Some languages trade efficiency for security. For example, some versions of Pascal would check that you don't access an array out of bounds. C# code is "managed", and this has a cost. Another common example is garbage collection, which saves time for the programmer but is not as efficient as hands on memory management. There are other sources of overhead such as infrastructure for exception handling or for supporting object oriented programming.
* In fact, nowadays high performance systems also run code on GPUs and even on FPGAs.
There are different factors for choosing X instead of Y, like
Some languages are suitable for developing business projects like C# or Python, but on other hand some of them are good for system programming like C++.
You must determine under what platform you are going to work and what application you are going to create.
The "fastest" programming language you can get with any platform is the assembly language for the chipset you are dealing with. At that level there is no translations. However there needs to have some knowledge of how the chipset executes instructions especially those that can do things in parallel.
The conversion from C to assembly is very "shallow" that it is near one to one but it is more readable. However it has a lot of layers above it due to the standard libraries to improve portability. There are not as many things that the compiler would need to do to get to assembly code and the stronger optimizations are generally there to make machine specific changes.
C++ adds a richer language. However because the language adds so much complexity it gets harder for the compiler to create optimal code for the platform.
Then we go to the other side of the scale. Interpreted languages. These tend to be the slowest because in addition to doing the work there is some time spent to parse the code and convert it to machine calls.
Then we have those in between. Generally they have a virtual machine layer which are optimized for the platform. And the compiler will create code for the virtual machine to execute. Sometimes this happens all at once like perl or pascal or ruby or Python. Or in several stages like java.
Some of these virtual machines add the notion of a JIT compiler which speeds up the runtime as well by creating machine level code rather than translating intermediate byte code.
Some virtual machines are low level which allow for less translation from byte code to machine code. Which speed things up while keeping portability.
*p++=*q++; would on many machines have been faster than array1[i]=array2[i]; but on many processors the reverse is often true and thus compilers may end up converting the former style of code to the latter--hardly a "shallow" conversion.
$\endgroup$
-O0 it won't do any optimizations. Optimizations are a bonus you get with the compiler, but the language in itself can translate near one to one to assembly.
$\endgroup$
Commented
Mar 26, 2018 at 19:25
A point which has not yet been mentioned is that in some languages, running the same piece of code many times will always perform the same sequence of actions; the computer thus only needs to determine once what the section of code should do. One of the major benefits of the "use strict" dialect of JavaScript is that it once the JavaScript engine figures out what a piece of code does, it can make use of that information the next time it is run; without "use strict", it can't.
For example, in the absence of "use strict", a piece of code like:
function f() { return x; }
may return a variable X in the immediate calling context, if there is one, or a variable X from an outer calling context, or it may return Undefined. Worse, in a loop like:
for (i=0; i<40; i+=1) { g(i); }
there is no way for the JavaScript engine to know what g() might do with i [or to g itself for that matter. Since g or i could quite legitimately change i into a string, the JavaScript engine can't simply use a numeric addition and numeric comparison in the loop, but must on each pass through the loop check to see if either of the function calls have done anything to i or g. By contrast, in the "use strict" [somewhat-sane] dialect the JavaScipt engine can examine the above code and know that every pass through the loop will use the same numeric variable and invoke the same function. It will thus only need to identify i and function g once, rather than having to look them up on every pass through the loop--a major time savings.
Well there are some quite professional answers here, this one is no close to them but might be intuitive for you.
You might have heard many times that when you need to perform a task as quickly as possible you would want to write the code that executes it in assembly. That's because you execute only commands that you actually need for completing the task and nothing more. While on a high level language you could implement this task in several lines, the compiler still needs to translate them to machine language. This translation is not always minimalistic as you could write it directly. That means that the machine will spend many clocks on executing commands which you could spare.
Although compilers are very sophisticated today they are still not effective as best assembly programmers can be.
Continuing in this direction, those unneeded commands grow in their amount (usually) as the language is higher leveled. (this is not 100% true for all high level languages)
So to me, language X is faster than language Y (on runtime) if for certain piece of code, the machine code of X is shorter than Y's.
It is difficult to answer this question definitively because it is so complex and multidimensional (it's almost like e.g. comparing car brands over misc. criteria) but there are new scientific studies including of an excellent code repository known as Rosetta code, (wikipedia overview). This 2014 survey by Nanz and Furia studies this question quite definitively and scientifically based on the following typical criteria and a rare quantitative analysis of typically subjective code qualities. The abstract contains some objectively-grounded findings and generalizations. (Hopefully other studies building on these results can be done in the future.)
RQ1. Which programming languages make for more concise code?
RQ2. Which programming languages compile into smaller executables?
RQ3. Which programming languages have better running-time performance?
RQ4. Which programming languages use memory more efficiently?
RQ5. Which programming languages are less failure prone?
Abstract—Sometimes debates on programming languages are more religious than scientific. Questions about which language is more succinct or efficient, or makes developers more productive are discussed with fervor, and their answers are too often based on anecdotes and unsubstantiated beliefs. In this study, we use the largely untapped research potential of Rosetta Code, a code repository of solutions to common programming tasks in various languages, which offers a large data set for analysis. Our study is based on 7,087 solution programs corresponding to 745 tasks in 8 widely used languages representing the major programming paradigms (procedural: C and Go; object-oriented: C# and Java; functional: F# and Haskell; scripting: Python and Ruby). Our statistical analysis reveals, most notably, that: functional and scripting languages are more concise than procedural and object- oriented languages; C is hard to beat when it comes to raw speed on large inputs, but performance differences over inputs of moderate size are less pronounced and allow even interpreted languages to be competitive; compiled strongly-typed languages, where more defects can be caught at compile time, are less prone to runtime failures than interpreted or weakly-typed languages. We discuss implications of these results for developers, language designers, and educators.
Computer languages are just an abstraction of commands to explain the computer what to do.
You can even write in the computer language Python and compile it with an C compiler (cython).
Keeping this in mind the speed of computer languages can not be compared.
But you can compare compilers for the same language up to some extend. For example GNU C compiler versus Intel C compiler. (Search for compiler benchmark)
