38
$\begingroup$

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.

$\endgroup$
  • 21
    $\begingroup$ If one program is faster than another one, it means they can't have the same byte code. $\endgroup$ – svick Mar 13 '15 at 23:11
  • 5
    $\begingroup$ Languages are just a notion one uses to write programs, so you can't really talk about the speed of a language. $\endgroup$ – Juho Mar 14 '15 at 8:25
  • 1
    $\begingroup$ @Raphael I feel it's off-topic, unclear and much too broad. While the topic is better suited to Software Engineering, I suspect it would be closed as "too broad" there. $\endgroup$ – David Richerby Mar 14 '15 at 13:31
  • 2
    $\begingroup$ Implementation aside, "speed" is ambiguous, there are different speeds for implementing, compiling, executing, and debugging, and you're generally going to be trading off some for the others (otherwise we would all be using the programming language) $\endgroup$ – Nick T Mar 15 '15 at 15:47
  • $\begingroup$ As above. The languages don't generate the same byte code. Some languages are easier to parse into byte code. Some have a higher level of abstraction. $\endgroup$ – superluminary Mar 16 '15 at 19:00
23
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Thanks. Its something like that. I was looking for. It was hardo to find material for the subject. This clarified enough. $\endgroup$ – Rodrigo Valente Mar 14 '15 at 17:24
  • $\begingroup$ @RodrigoAraújoValente Thanks, You may wish to look at this question. An extremist view is that a compiler for language L can just bundle an interpreter for L with the source code of the program, without doing anything. Then you can do better by trying to optimize the computation of the bundle (partial evaluation). The more you optimize and the faster your language will be. The question is then: what can help you optimize? Answers may include good knowledge of specialized subject area, help from programmer, sophisticated analysis, etc... $\endgroup$ – babou Mar 14 '15 at 18:42
  • $\begingroup$ By "same bytecode" I am guessing that you mean "same kind of executable representation". Obviously identical executables will run at the same speed (assuming the same execution system). (I would probably have looked at this from an information/communication perspective. In theory, a programmer can know everything about the program and the hardware whereas a language often constrains communication (limiting what tranformations are allowed or useful) and the compiler may not know microarchitectural details. Compilation and compiler development are analygous to development and training. ... $\endgroup$ – Paul A. Clayton Mar 15 '15 at 8:39
  • $\begingroup$ This then gets into what humans are generally good at (e.g., recognizing general patterns) versus what computers are typically good at (e.g., record keeping and "arithmetic"). In addition, communication of runtime information is often more computer-friendly (profile-guided optimization can overcome some lack of information communicated through the programming language). Dynamic optimization would be impractical with human programmers ... $\endgroup$ – Paul A. Clayton Mar 15 '15 at 8:40
  • $\begingroup$ (though the same could be said of writing all software in assembly by skilled programmers targeting specific hardware, by the time the software was optimized not only would the hardware have changed but the software would be obsolete).) $\endgroup$ – Paul A. Clayton Mar 15 '15 at 8:40
16
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ So, basically if I need more performance I should go for compiled languages then? And about the paradigms? There is a reason to choose functional instead of oop, or vice versa? $\endgroup$ – Rodrigo Valente Mar 14 '15 at 12:45
  • $\begingroup$ Your remark about garbage collection is a bit simplistic. It is not always decidable statically when allocated memory is no longer used. Even when decidable, it may be very hard to determine without making errors. Hence, GC is sometimes necessary and often safer (like checkingarray bounds). Furthermore, it can be combined with explicit release. $\endgroup$ – babou Mar 14 '15 at 13:11
  • $\begingroup$ @RodrigoAraújoValente Depends. Crappy code will often compile to crappy code. Maybe the code you can write in Python is actually faster than the code you can write in C. $\endgroup$ – Raphael Mar 14 '15 at 13:16
  • $\begingroup$ nit: as explained by the question you linked to, python is not actually interpreted "on-the-fly" :) $\endgroup$ – Eevee Mar 14 '15 at 23:57
  • $\begingroup$ None of the languages you mention in the interpreted section are interpreted on the fly. Python is compiled to bytecode, Ruby was compiled to AST, but I believe is now compiled to bytecode. Matlab, I believe is now actually JIT compiled. Actually, I don't know any non-niche language implementation that interprets things on the fly rather then at least compiling to some kind of virtual machine representation. $\endgroup$ – Winston Ewert Mar 15 '15 at 3:25
5
$\begingroup$

There are different factors for choosing X instead of Y, like

  • Ease of learning
  • Ease of understanding
  • Speed of development
  • Help with enforcement of correct code
  • Performance of compiled code
  • Supported platform environments
  • Portability
  • Fit-for-purpose

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.

$\endgroup$
  • 1
    $\begingroup$ So, how I determine performance of compiled code? That's basically what made me do this question. $\endgroup$ – Rodrigo Valente Mar 14 '15 at 12:40
  • 6
    $\begingroup$ This answer certainly has good advice, but I fail to see how it answers the question, which is about speed as a choice factor for a language. $\endgroup$ – babou Mar 14 '15 at 12:58
  • $\begingroup$ @RodrigoAraújoValente They may not even be compiled code (if your language is interpreted). $\endgroup$ – Raphael Mar 14 '15 at 13:14
  • 1
    $\begingroup$ You may want to add "Good libraries" and "Good tools". $\endgroup$ – Raphael Mar 14 '15 at 13:15
  • $\begingroup$ @RodrigoAraújoValente You run it and profile it. $\endgroup$ – Kyle Mar 14 '15 at 16:32
2
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Historically, C was designed to allow easy translation into machine code. To an increasing extent, however, turning C into efficient C code requires that a compiler figure out what a programmer was trying to do and then translate that intention into machine code. For example, historically the machine code equivalent of *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$ – supercat Mar 15 '15 at 19:19
  • $\begingroup$ That's usually if you do -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$ – Archimedes Trajano Mar 26 '18 at 19:25
2
$\begingroup$

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.

$\endgroup$
2
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Assembly totally rocks. It takes a true artist to outperform the best compilers though. $\endgroup$ – Johan - reinstate Monica May 11 '16 at 0:10
1
$\begingroup$

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.

$\endgroup$
0
$\begingroup$

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)

$\endgroup$
  • 2
    $\begingroup$ If you want to make comments about the question, please use the comment box, not your answer. Note that this is Computer Science Stack Exchange and computer science is not programming, just as literature is not word-processing. Programming questions live on Software Engineering or Stack Overflow. $\endgroup$ – David Richerby Mar 14 '15 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.