views:

249

answers:

6

Isn't every language compiled into low-level computer language?

If so, shouldn't all languages have the same performance?

Just wondering...

+1  A: 

No, some languages are run by a 'software interpreter' as byte code.

Also, it depends on what the language does in the background as well, so 2 identically functioning programs in different languages may have different mechanics behind the scenes and hence be actually running different instructions resulting in differing performance.

Dan McGrath
+4  A: 

No, some languages are simply interpreted. They never actually get turned into machine code. So those languages will generally run slower than low-level languages like C.

Even for the languages which are compiled into machine code, sometimes what comes out of the compiler is not the most efficient possible way to write that given program. So it's often possible to write programs in, say, assembly language that run faster than their C equivalents, and C programs that run faster than their JIT-compiled Java equivalents, etc. (Modern compilers are pretty good, though, so that's not so much of an issue these days)

David Zaslavsky
Even languages that are interpreted are translated into machine code in some sense.
Omnifarious
It's becoming _more_ possible to write programs in C that run faster than their assembly equivalents and JITed-Java programs that run faster than their C equivalents. Modern compilers are pretty damn good; they regularly do stuff that humans simply can't. Of course, humans regularly do stuff they simply can't, so...
Vuntic
@Omnifarious: true, I guess I meant that some languages never get run as machine code without having the interpreter's machine code interspersed. @Vuntic: I have to disagree. It's possible in some cases to write an assembly program that runs faster than any C program which has the same function, but not the other way around - for instance, copy the output of the C compiler and you get an assembly program which runs just as fast.
David Zaslavsky
@Omnifarious: interpreted languages are translated into actions and declarations. These may or may not be implemented as machine code.
John Saunders
+14  A: 

It is easier and more efficient to map some languages into machine language than others. There is no easy analogy that I can think of for this. The closest I can come to is translating Italian to Spanish vs. translating a Khoisan language into Hawaiian.

Another analogy is saying "Well, the laws of physics are what govern how every animal moves, so why do some animals move so much faster than others? Shouldn't they all just move at the same speed?".

Omnifarious
+1 for brilliant analogy.
Crashworks
@Crashworks - Thanks, but which one? *big grin*
Omnifarious
+3  A: 

Yes, all programs get eventually translated into machine code. BUT:

  1. Some programs get translated during compilation, while others are translated on-the-fly by an interpreter (e.g. Perl) or a virtual machine (e.g. original Java)

    Obviously, the latter is MUCH slower as you spend time on translation during running.

  2. Different languages can be translated into DIFFERENT machine code. Even when the same programming task is done. So that machine code might be faster or slower depending on the language.

DVK
but if php is interpreted and compiled once and cached, then it shouldn't be slower than C if we are assuming that it compiles into the same machine code? this is the part i have difficulties to understand.
never_had_a_name
@gayer - php is NOT compiled into machine code. It is interpreted by php interpreter, dynamically. I'm not 100% what gets cached (I am guessing the parsed grammar tree but don't know enough about php to be sure) but it is certainly NOT the machine code.
DVK
Why the downvote?
DVK
@fayer, PHP doesn't exactly follow that model, but even if it did, it would never compile into the same machine code as an equivalent C program. Yes, they all compile into machine code, but not the same machine code, and, practically speaking, they never will.
Omnifarious
+13  A: 

As pointed out by others, not every language is translated into machine language; some are translated into some form (bytecode, reverse Polish, AST) that is interpreted.

But even among languages that are translated to machine code,

  • Some translators are better than others
  • Some language features are easier to translate to high-performance code than others

An example of a translator that is better than some others is the GCC C compiler. It has had many years' work invested in producing good code, and its translations outperform those of the simpler compilers lcc and tcc, for example.

An example of a feature that is hard to translate to high-performance code is C's ability to do pointer arithmetic and to dereference pointers: when a program stores through a pointer, it is very difficult for the compiler to know what memory locations are affected. Similarly, when an unknown function is called, the compiler must make very pessimistic assumptions about what might happen to the contents of objects allocated on the heap. In a language like Java, the compiler can do a better job translating because the type system enforces greater separation between pointers of different types. In a language like ML or Haskell, the compiler can do better still, because in these languages, most data allocated in memory cannot be changed by a function call. But of course object-oriented languages and functional languages present their own translation challenges.

Finally, translation of a Turing-complete language is itself a hard problem: in general, finding the best translation of a program is an NP-hard problem, which means that the only solutions known potentially take time exponential in the size of the program. This would be unacceptable in a compiler (can't wait forever to compile a mere few thousand lines), and so compilers use heuristics. There is always room for improvement in these heuristics.

Norman Ramsey
+1: this is a much better answer than @Omnifarious provided, should have more votes too.
High Performance Mark
@High I bet at least 50% of all votes arrive in the first hour :-)
Norman Ramsey
I agree, I think it's a technically better answer too. But people also like simple and seemingly profound analogies, and I think good analogies are sometimes better than answers that are more technically accurate in detail because they allow you to apply the same thought process to other problems. I still think your answer is better, but I can see why people voted more for mine.
Omnifarious
@Omnifarious: Nothing beats a good metaphor!
Norman Ramsey
+2  A: 

You should understand the difference between compiling (which is translating) and interpreting (which is simulating). You should also understand the concept of a universal basis for computation.

A language or instruction set is universal if it can be used to write an interpreter (or simulator) for any other language or instruction set. Most computers are electronic, but they can be made in many other ways, such as by fluidics, or mechanical parts, or even by people following directions. A good teaching exercise is to write a small program in BASIC and then have a classroom of students "execute" the program by following its steps. Since BASIC is universal (to a first approximation) you can use it to write a program that simulates the instruction set for any other computer.

So you could take a program in your favorite language, compile (translate) it into machine language for your favorite machine, have an interpreter for that machine written in BASIC, and then (in principle) have a class full of students "execute" it. In this way, it is first being reduced to an instruction set for a "fast" machine, and then being executed by a very very very slow "computer". It will still get the same answer, only about a trillion times slower.

Point being, the concept of universality makes all computers equivalent to each other, even though some are very fast and others are very slow.

Mike Dunlavey