187
126
Taking a look at Julia's webpage, you can see some benchmarks of several languages across several algorithms (timings shown below). How can a language with a compiler originally written in C, outperform C code?
Figure: benchmark times relative to C (smaller is better, C performance = 1.0).
StrugglingProgrammer
Posted 2015-08-22T14:13:48.210
Reputation: 1 913
279
There is no necessary relation between the implementation of the compiler and the output of the compiler. You could write a compiler in a language like Python or Ruby, whose most common implementations are very slow, and that compiler could output highly optimized machine code capable of outperforming C. The compiler itself would take a long time to run, because its code is written in a slow language. (To be more precise, written in a language with a slow implementation. Languages aren't really inherently fast or slow, as Raphael points out in a comment. I expand on this idea below.) The compiled program would be as fast as its own implementation allowed—we could write a compiler in Python that generates the same machine code as a Fortran compiler, and our compiled programs would be as fast as Fortran, even though they would take a long time to compile.
It's a different story if we're talking about an interpreter. Interpreters have to be running while the program they're interpreting is running, so there is a connection between the language in which the interpreter is implemented and the performance of the interpreted code. It takes some clever runtime optimization to make an interpreted language which runs faster than the language in which the interpreter is implemented, and the final performance can depend on how amenable a piece of code is to this kind of optimization. Many languages, such as Java and C#, use runtimes with a hybrid model which combines some of the benefits of interpreters with some of the benefits of compilers.
As a concrete example, let's look more closely at Python. Python has several implementations. The most common is CPython, a bytecode interpreter written in C. There's also PyPy, which is written in a specialized dialect of Python called RPython, and which uses a hybrid compilation model somewhat like the JVM. PyPy is much faster than CPython in most benchmarks; it uses all sorts of amazing tricks to optimize the code at runtime. However, the Python language which PyPy runs is exactly the same Python language that CPython runs, barring a few differences which don't affect performance.
Suppose we wrote a compiler in the Python language for Fortran. Our compiler produces the same machine code as GFortran. Now we compile a Fortran program. We can run our compiler on top of CPython, or we can run it on PyPy, since it's written in Python and both of these implementations run the same Python language. What we'll find is that if we run our compiler on CPython, then run it on PyPy, then compile the same Fortran source with GFortran, we'll get exactly the same machine code all three times, so the compiled program will always run at around the same speed. However, the time it takes to produce that compiled program will be different. CPython will most likely take longer than PyPy, and PyPy will most likely take longer than GFortran, even though all of them will output the same machine code at the end.
From scanning the Julia website's benchmark table, it looks like none of the languages running on interpreters (Python, R, Matlab/Octave, Javascript) have any benchmarks where they beat C. This is generally consistent with what I'd expect to see, although I could imagine code written with Python's highly optimized Numpy library (written in C and Fortran) beating some possible C implementations of similar code. The languages which are equal to or better than C are being compiled (Fortran, Julia) or using a hybrid model with partial compilation (Java, and probably LuaJIT). PyPy also uses a hybrid model, so it's entirely possible that if we ran the same Python code on PyPy instead of CPython, we'd actually see it beat C on some benchmarks.
tsleyson
Posted 2015-08-22T14:13:48.210
Reputation: 2 998
What optimizations the compiler does is one important thing to consider. A really smart compiler would recognize that the program is synthetic benchmark, and simply optimize away just about all code, simply creating the expected output. – ghellquist – 2018-04-08T21:13:57.007
@ghellquist Sure, if the benchmark is artificial enough and the compiler is smart enough. That isn't directly or straightforwardly related to the compiler's implementation language, though, so I didn't mention it here. – tsleyson – 2018-04-09T00:48:10.573
11This is an amazing answer. Very clear, understandable, and informative. Thank you very much for taking the time to write it! – Alex A. – 2015-08-29T05:20:23.347
7Both javascript and java are being run with a JIT compiler, yet java has one test where it is faster then C. The biggest reason why a runtime/compiler can run faster is due to having more information avaliable. C/C++ compilers can optimize code (usually) a lot more then someone writing assembly by hand, simply because the compiler has more information available to it. Sure, in theory the person could write better assembly code, but that requires more knowledge and skill then most people have.JIT languages can expand on this even more, being able to optimize for the exact machine its running on – Programmdude – 2015-08-30T08:51:40.407
99
How can a machine built by a man be stronger than a man? This is exactly the same question.
The answer is that the output of the compiler depends on the algorithms implemented by that compiler, not on the langauge used to implement it. You could write a really slow, inefficient compiler that produces very efficient code. There's nothing special about a compiler: it's just a program that takes some input and produces some output.
David Richerby
Posted 2015-08-22T14:13:48.210
Reputation: 78 585
34How can a chess program beat the human that wrote it? – Thorbjørn Ravn Andersen – 2015-08-23T08:18:42.840
25By making better moves! <rimshot> – Tony Ennis – 2015-08-23T23:32:15.643
1To paraphrase Penn Gilette's answer to why it doesn't matter that a computer can beat a man at chess: "Would you expect a robot designed by GE to lose to a man in a boxing match?" – Dave Kanter – 2015-08-27T17:27:25.760
90
I want to make one point against a common assumption which is, in my opinion, fallacious to the point of being harmful when choosing tools for a job.
There is no such thing as a slow or fast language.¹
On our way to the CPU actually doing something, there are many steps².
Every single item contributes to the actual runtime you can measure, sometimes heavily. Different "languages" focus on different things³.
Just to give some examples.
1 vs 2-4: an average C programmer is likely to produce far worse code than an average Java programmer, both in terms of correctness and efficiency. That is because the programmer has more responsibilities in C.
1/4 vs 7: in low-level language like C, you may be able to exploit certain CPU features as a programmer. In higher-level languages, only the compiler/interpreter can do so, and only if they know the target CPU.
1/4 vs 5: do you want or have to control the memory layout in order to best use the memory architecture at hand? Some languages give you control over that, some don't.
2/4 vs 3: Interpreted Python itself is horribly slow, but there are popular bindings to highly optimized, natively compiled libraries for scientific computing. So doing certain things in Python is fast in the end, if most of the work is done by these libraries.
2 vs 4: The standard Ruby interpreter is quite slow. JRuby, on the other hand, can be very fast. That is the same language is fast using another compiler/interpreter.
1/2 vs 4: Using compiler optimisations, simple code can be translated into very efficient machine code.
The bottom line is, the benchmark you found does not make much sense, at least not when boiled down to that table you include. Even if all you are interested in is running time, you need to specify the whole chain from programmer to CPU; swapping out any of the elements can change the results dramatically.
To be clear, this answers the question because it shows that the language the compiler (step 4) is written in is but one piece of the puzzle, and probably not relevant at all (see other answers).
I deliberately don't go into different success metrics here: running time efficiency, memory efficiency, developer time, security, safety, (provable?) correctness, tool support, platform independency, ...
Comparing languages w.r.t. one metric even though they have been designed for completely different goals is a huge fallacy.
Raphael
Posted 2015-08-22T14:13:48.210
Reputation: 69 237
1@babou Agreed, very nice explanation. So what would be a better metric, or perhaps set of metrics, that can be used to compare languages with their respective compiler / interpreters? Also, a minor nitpick : you say "There is no such thing as a slow or fast language" and then "Python itself is horribly slow", but I assume you meant the Python interpreter. – StrugglingProgrammer – 2015-08-23T14:03:58.273
2@benalbrecht My point is that there is no single good set of such metrics. It's a trade-off, always. If you build device drivers, you want to be correct above all things. If you build Twitter's backbone, you want to be efficient above all else. In both cases, you use the tools and hire the people that allow for that. If you are an Android-app-tinkering startup, you use what your people know and/or what minimises your time-to-market. If you teach algorithms, you want a language with concise, clear syntax and little boilerplate. And so on. Priorities differ, and so we have different languages. – Raphael – 2015-08-23T14:08:05.560
See also this tangentially related question.
23
There is one forgotten thing about optimisation here.
There was longish debate about fortran outperforming C. Putting apart malformed debate: the same code was written in C and fortran (as testers thought) and performance was tested based on same data. The problem is, these languages differ, C allows pointers aliasing, while fortran does not.
So the codes were not same, there was no __restrict in C tested files, which gave differences, after rewriting files to tell compiler that it can optimise pointers, the runtimes become similar.
The point here is, that some optimisation techniques are easier (or starts to be legal) in newly created language.
Also it is possible in long run to VM with JIT outperform C. There are two possibilities:
JIT code can take advantage of machine that it hosts it (for example some SSE $X$ or other exclusive for some CPU vectorised instructions) that were not implemented in compared program.
Secondly VM can perform pressure test while running, so it can take pressured code and optimise it or even precalculate it during runtime. In advance compiled C program does not expect where is the pressure or (the most of the time) there are generic versions of executables for general family of machines.
In this test there is also JS, well there are faster VMs than V8, and it also performs faster than C in some tests.
I have checked it, and there were unique optimising techniques not available yet in C compilers.
C compiler would have to do static analysis of whole code at once, march upon given platform and go around memory alignment problems.
VM just transliterated part of the code to optimised assembly and run it.
About Julia - as I checked it operates on AST of code, for example GCC skipped this step an just recently started to take some info from there. This plus other constraints and VM techniques might explain a bit.
Example: let us take simple loop, that takes starting end ending point from variables and loads part of variables into calculations know at the runtime.
C compiler generates loading variables from registers.
But at the runtime these variables are known and treated as constants through execution.
So instead of loading variables from registers (and not performing caching because it can change, and from static analysis it is not clear) they are treated fully like constants and folded, propagated.
Evil
Posted 2015-08-22T14:13:48.210
Reputation: 9 192
12
The previous answers give pretty much the explanation, though mostly from a pragmatic angle, for as much as the question makes sense, as excellently explained by Raphael's answer.
Adding to this answer, we should note that, nowadays, C compilers are written in C. Of course, as noted by Raphael their output and its performance may depend, among other things, on the CPU it is running on. But it also depends on the amount of optimization done by the compiler. If you write in C a better optimizing compiler for C (which you then compile with the old one to be able to run it), you get a new compiler that makes C a faster language than it was before. So, what is the speed of C? Note that you can even compile the new compiler with itself, as a second pass, so that it compiles more efficiently, though still giving the same object code. And the full employment theorem shows that their is no end to such improvements (thanks to Raphael for the pointer).
But I think it may be worthwhile trying to formalize the issue, as it illustrate very well some fundamental concepts, and particularly denotational versus operational view of things.
A compiler $C_{S\to T}$, abbreviated to $C$ if there is no ambiguity, is a realization of a computable function $\mathcal C_{S\to T}$ that will translate a program text $P_{:S}$ computing a function $\mathcal P$, written in a source language $S$ into program text $P_{:T}$ written in a target language $T$, that is supposed to compute the same function $\mathcal P$.
From a semantic point of view, i.e. denotationally, it does not matter how this compiling function $\mathcal C_{S\to T}$ is computed, i.e., what realization $C_{S\to T}$ is chosen. It could even be done by a magic oracle. Mathematically, the function is simply a set of pairs $\{(P_{:S},P_{:T})\mid P_S\in S \wedge P_T\in T\}$.
The semantic compiling function $\mathcal C_{S\to T}$ is correct if both $P_S$ and $P_T$ compute the same function $\mathcal P$. But this formalization applies as well to an incorrect compiler. The only point is that whatever is implemented achieves the same result independently of the implementation means. What matters semantically is what is done by the compiler, not how (and how fast) it is done.
Actually getting $P_{:T}$ from $P_{:S}$ is an operational issue, that must be solved. This is why the compiling function $\mathcal C_{S\to T}$ must be a computable function. Then any language with Turing power, no matter how slow, is sure to be able to produce code as efficient as any other language, even if it may do so less efficiently.
Refining the argument, we probably want the compiler to have good efficiency, so that the translation can be performed in reasonable time. So the performance of the compiler program matters for users, but it has no impact on semantics. I am saying performance, because the theoretical complexity of some compilers can be much higher than one would expect.
This will illustrate the distinction, and show a practical application.
It is now common place to first implement a language $S$ with an interpreter $I_S$, and then write a compiler $C_{S\to T\,:S}$ in the language $S$ itself. This compiler $C_{S\to T\,:S}$ can be run with the interpreter $I_S$ to translate any program $P_{:S}$ into a program $P_{:T}$. So we do have a running compiler from language $S$ to (machine?) language $T$, but it is very slow, if only because it runs on top of an interpreter.
But you can use this compiling facility to compile the compiler $C_{S\to T\,:S}$, since it is written in language $S$, and thus you get a compiler $C_{S\to T\,:T}$ written in the target language $T$. If you assume, as often the case, that $T$ is a language that is more efficiently interpreted (machine native, for example), then you get a faster version of your compiler running directly in language $T$. It does exactly the same job (i.e. produces the same target programs), but it does it more efficiently.
babou
Posted 2015-08-22T14:13:48.210
Reputation: 18 549
"What matters semantically is what is done, not how (and how fast) it is done" -- it bears mention that non-functional criteria exist in practice. There are many functionally equivalent target programs but we may prefer some over others for some reason (efficiency, size, better memory alignment, ...). That is to say, the view of a compiler as a function as you define is more limited than we want it to be (it also often skips over side effects, e.g. I/O). It serves the explanatory purpose you want to to, though. – Raphael – 2015-08-23T13:19:41.803
@Raphael Regarding full employment theorem, I had that in mind (in my comment on C), but I did not know the name, and postponed finding a reference. Thanks for doing it. --- The semantics I talk about is that of the compiler, not that of the target program. The target program is preserved syntactically and operationally, not just semantically. Or did I misunderstand your remark. I edited to make things more precise in my text. – babou – 2015-08-23T13:49:00.240
@Raphael Since you did not delete your comment, does it mean that I misunderstood it, or did not answer it properly? How is it that the view of the compiler (not of the compiled program) as a function is too limited, from a semantic point of view. Of course, as a function, it could take other arguments than just the compiled program, such as optimization directives) but this is a detail that would not change the discussion. – babou – 2015-08-23T14:56:22.377
I think my comment stands as a pointer towards "there's more than this model". What you write is not wrong, but it's not everything. Theoretically, this seems obvious: "the" compiler function is not per se well-defined since there are infinitely many possible target programs, all semantically equivalent. Which to pick is a very important part of designing compilers. – Raphael – 2015-08-23T14:59:24.223
@Raphael There is only this model. You are misreading my text: I am saying "a computable function", because others are possible. The compiler is implementing one specific compiling function "curly $\mathcal C$", which is a function from S syntax to T syntax, defining a precise set of syntactic pairs of programs (italic letters). These pairs are supposed to compute the same function "curly $\mathcal P$", but the second component cannot be replaced by another one with the same property. I am intentionally ignoring the semantics of programs to keep things comparable in the translation processes. – babou – 2015-08-23T15:51:08.740
But you go on specifying what the function should to, namely creating a semantically equivalent program. My point is that this is not all we specify, in practice. – Raphael – 2015-08-23T16:08:16.957
No, I am saying what this function does (hopefully, since my formalization also applies to a buggy compiler: then bugs are preserved). I am not specifying what it should do. I am specifying a fixed syntactic translation process. I ignore the semantics of programs. The semantic compiling function is unique and precise because it is purely syntactic. I changed my text so that you can no longer read it the way you did. I do not understand why you keep misreading me. Hopefully will no longer. But I fear that the concept of buggy compilers may distress some readers. – babou – 2015-08-23T16:59:47.623
6
By Blum's speedup theorem there are programs which written and run on the very fastest computer/compiler combination will run slower than a program for the same on your first PC running interpreted BASIC. There just isn't a "fastest language". All you can say is that if you write the same algorithm in several language (implementations; as noted, there are plenty of different C compilers around, and I even came across a rather capable C interpreter), it will run faster or slower in each.
There can't be a "always slower" hierarchy. This is a phenomenon everybody fluent in several languages is aware of: Each programming language was designed for a specific type of applications, and the more used implementations have been lovingly optimized for that type of programs. I'm pretty sure that e.g. a program for fooling around with strings written in Perl will probably beat the same algorithm written in C, while a program munching on large arrays of integers in C will be faster than Perl.
vonbrand
Posted 2015-08-22T14:13:48.210
Reputation: 12 507
I guess it depends on how broad you interpret the term "specific type of application". While it is true that most mainstream languages are not DSLs, they most certainly are designed with certain uses in mind. C was designed to implement Unix. Java was designed for scripting Interactive TVs. Smalltalk was designed for teaching children. ECMAScript was designed for server-side and client-side web scripting. Perl was designed for text processing and Unix scripting. PHP was designed for server-side web scripting. Erlang was designed for reliability. Scheme was designed for exploring the … – Jörg W Mittag – 2017-03-24T21:02:03.463
… foundations of OO and the Actor Model. APL was designed as a notation for teaching math. Julia was designed for scientific programming. All of those languages are now of course used outside of their original problem domain, but there still some properties in those languages that make them a better or worse fit for certain kinds of applications, even though they all can be used to build all kinds of things. – Jörg W Mittag – 2017-03-24T21:06:07.543
1"Each programming language was designed for a specific type of applications"
Actually, most programming languages that people actually use are general purpose languages, the opposite of being designed for specific applications. It's just that certain languages end up being used more in certain domains mostly due to social effects. – Cubic – 2015-08-26T21:29:22.013
5
Let's go back to the original line: "How can a language whose compiler is written in C ever be faster than C?" I think this really meant to say: how can a program written in Julia, whose core is written in C, ever be faster than a program written in C? Specifically, how could the "mandel" program as written in Julia run in 87% of the execution time of the equivalent "mandel" program written in C?
Babou's treatise is the only correct answer to this question so far. All the other responses so far are more or less answering other questions. The problem with babou's text is that the many-paragraphs-long theoretical description of "What is a compiler" is written in terms that the original poster will probably have trouble understanding. Anyone who grasps the concepts referred to by the words "semantic", "denotationally", "realization", "computable" and so on will already know the answer to the question.
The simpler answer is that neither C code, nor Julia code, is directly executable by the machine. Both have to be translated, and that translation process introduces a lot of ways that the executable machine code can be slower or faster, but still produce the same end result. Both C and Julia do compilation, which means a series of translations to another form. Commonly, a human-readable text file is translated to some internal representation, and then written out as a sequence of instructions that the computer can understand directly. With some languages, there's more to it than that, and Julia is one of these -- it has a "JIT" compiler, which means the whole translation process doesn't have to happen all at once for the entire program. But the end result for any language is machine code that needs no further translation, code that can be sent directly to the CPU to make it do something. In the end, THIS is the "computation", and there is more than one way to tell a CPU how to get the answer you want.
One could imagine a programming language that has both a "plus" and a "multiply" operator, and another language that has only "plus". If your computation requires multiplication, one language will be "slower" because of course the CPU can do both directly, but if you don't have any way to express the need to multiply 5 * 5, you are left having to write "5 + 5 + 5 + 5 + 5". The latter will take more time to arrive at the same answer. Presumably, there's some of this going on with Julia; perhaps the language allows the programmer to state the desired goal of computing a Mandelbrot set in a way that isn't possible to directly express in C.
The processor used for the benchmark was listed as a Xeon E7-8850 2.00GHz CPU. The C benchmark used the gcc 4.8.2 compiler to produce instructions for that CPU, while Julia uses the LLVM compiler framework. It's possible that gcc's backend (the part that produces machine code for a particular CPU architecture) isn't as advanced in some way as the LLVM backend. That could make a difference in performance. There are also many other things going on -- the compiler can "optimize" by perhaps issuing instructions in a different order than specified by the programmer, or even not doing some things at all if it can analyze the code and determine they're not required to get the right answer. And the programmer might have written part of the C program in a way that make it slow, but didn't make such mistakes in the Julia code -- for example, the order in which elements in a two-dimensional array are accessed might have no bearing on the end result of the computation, but the order might well make a difference in speed (see "Row major versus Column major layout of matrices").
All of these are ways of saying: there are lots of ways to write machine code to compute a Mandelbrot set, and the language you use has a major effect on how that machine code gets written. The more you understand about compilation, instruction sets, caches, and so on, the better equipped you will be to get the results you want. The major takeaway from the benchmark results cited for Julia is that no one language or tool is best at everything. In fact the best speed factor in the entire chart was for Java!
Randall Krieg
Posted 2015-08-22T14:13:48.210
Reputation: 51
2
The speed of a compiled program depends on two things:
The language a compiler is written in is irrelevant to (1). For example, a Java compiler can be written in C or Java or Python, but in all cases the "machine" executing the program is the JVM.
The language a compiler is written in is irrelevant to (2). For example, there is no reason why a C compiler written in Python cannot output exactly the same executable file as a C compiler written in C or Java.
Artelius
Posted 2015-08-22T14:13:48.210
Reputation: 616
1
I'll try to offer a shorter answer.
The core of the question lies in the definition of "speed" of a language.
Most if not all speed comparison tests don't test what the maximum possible speed is. Instead they write a small program in a language they want to test, to solve a problem. When writing the program the programmer uses what the they assume* to be best practice and conventions of the language, at the time of the test. Then they measure the speed at which the program was executed.
*The assumptions are occasionally wrong.
Peter
Posted 2015-08-22T14:13:48.210
Reputation: 139
0
Code written in a language X whose Compiler is written in C, can outperform a code written in C, provided, C compiler does poor optimization compared to that of language X. If we keep optimization out of discussion then if compiler of X could generate better object code than that generated by C compiler, then also code written in X may win the race.
But if language X is an interpreted language, and the interpreter is written in C, and if we assume that interpreter of language X and code written in C is compiled by same C compiler, then in no way code written in X going to outperform code written in C, provided both implementation follow same algorithm and uses equivalent data structures.
jayraj
Posted 2015-08-22T14:13:48.210
Reputation: 11
2What does this add over previous answers? Also, I don't think your second paragraph is true, for reasons laid out in other answers. – Raphael – 2015-09-11T16:13:50.740
2@babou Your comment is cleverly worded but it obfuscates the real intent behind the question. Julia also has a runtime written in C which makes the question more like "How can a human running on foot and equipped with some high-tech device move faster than a human?" That isn't necessarily impossible but it's a significant engineering challenge. If the question is strictly about compilers, then of course it's easy to imagine hypothetical compilers written in Python/Ruby/Smalltalk/VBA that can compile highly optimized native code. – Praxeolitic – 2017-12-30T04:51:48.383
@Praxeolitic Why believe that the real intent is what you try to make it, and which does not seem well expressed in your example. Furthermore, there is no reason to believe that the would-be concept of programming language speed has much meaning. Possibly when considering specific implementations. But the real point here is that, when you have a language with Turing power, you have as much power as you will ever get to compute whatever you need (if computable at all) and in particular to implement a compiler generating code with any level of performance achievable by whatever means. – babou – 2017-12-30T15:47:15.980
@Praxeolitic My initial comment takes, on a trivial example, an even more abstract point of view: can a device build another device better than itself at some given task? Note that neither the task nor the meaning of "better" need be specified. And the answer is that all that matters is the building ability of the building device, independently of its own ability at the given task. This is also the point of view I am taking more formally in my answer below, restricted to compilers. – babou – 2017-12-30T16:18:33.670
1@babou What I'm saying is when a question shows a mismatch between intent and literal wording, it's better to clarify the misunderstanding, answer the intended question, and address the literal question if it makes any sense. I suppose it takes inferring, but it was clear that OP's question was "This implies doing A and then B is faster than just doing B. How is that possible?" and the appropriate answer is "Actually, that isn't implied." The reason for my comment is that I feel SO gives too many hyper-literal answers in general. Those answers have good info but they're often not helpful. – Praxeolitic – 2018-01-01T18:51:36.067
@Praxeolitic Your point is well taken, and I can say that my habit is generally to try to guess the real question hiding behind the miswording. But it is often difficult, and, unlike you, I do not see any such situation here. Well it is clearly a naive question, but not obvious in what way the user is being naive. He might actually ask what I answered to, or he might not even understand properly the differences between a compiler and an interpreter. The given answers actually pretty much assume the same. – babou – 2018-01-01T21:48:54.303
The language in which the compiler is written influences the speed of code generation, but not the speed of the generated code. (I assume the compiler is written in a language conceptually capable of any computing task.) – PJTraill – 2018-02-05T12:31:26.577
It can also simply indicate that an author of C benchmarking program was a lamer. This idea is also supported by fact that even Java Mandel {brot fractal ?} benchmarking program significantly outperforms C version (0.68 duration). And in general Java can't execute things faster than C, because of JVM overhead (even with JIT compiler) and GC overhead. So this clearly shows that there must be some serious design/code flaw in C version of Mandel. Other things being equal - C wins. Just Fortran can be a competitor, because it is ancestor of C and is optimized for numeric computations – Agnius Vasiliauskas – 2019-02-19T12:38:30.037
You could write a compiler for C on a steam-powered Turing machine. It would take ages to compile but the code it produced would run on the target machine at the speed of the target machine. – chasly - supports Monica – 2020-06-22T07:48:58.247
6Closely related question. – Raphael – 2015-08-22T20:48:42.243
1Also, be aware that such microbenchmarks are not very representative. – Raphael – 2015-08-23T09:57:36.650
410How can a car, which is a man-made object, move faster than a man? – babou – 2015-08-23T10:25:18.167
21According to the table, Python is slower than C. Do you think that it is impossible to write a C compiler in Python that generates the same code as your favourite C compiler? And what language is that written in anyway? – Carsten S – 2015-08-23T16:29:02.630
7babou's comment was spot-on, but I don't think we need multiple versions of the same. – Raphael – 2015-08-25T14:07:00.387
14
A related thought. Many compilers are self hosting, meaning they're written in their own language (often plus some assembly) and compiled with the previous version of itself. Yet compilers get better and faster. Mind blow.
– Schwern – 2015-08-25T21:21:23.4931@Schwern It's not too difficult to see how that might work. Write new compiler and compile using old compiler. We end up with a better, yet slower compiler. Then compiler the new compiler again using itself. Now we have a better, faster compiler. – John Gowers – 2015-08-29T15:44:03.207
@Raphael Especially given that babou's comment is already a "multiple version" of my answer! – David Richerby – 2015-08-29T22:02:35.317
Mandel is the algorithm listed that is most often outperformed by languages that aren't C. That seems to hint to me that the C implementation wasn't as optimal as the other languages'. – gil_bz – 2015-09-11T15:21:28.217
Please google "Compiler" "Assembler" and "Interpreter". Maybe your question makes more sense if you relate it to interpreter instead of compiler. – Micka – 2015-09-11T16:14:06.623
I would like to raise a comparison between C++ and Javascript
– Bakudan – 2015-09-13T15:32:34.360It's really complicated to compare the execution speed of two languages. – Celeritas – 2015-10-15T08:27:27.630