Is it possible to measure the performance of the language? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For hel开发者_StackOverflow社区p clarifying this question so that it can be reopened, visit the help center. Closed 12 years ago.

Do most languages have many different execution engines ?

---

Is it possible to measure the performance of the language ?

Not really. It depends on how you define performance and what you put your weight on. If you for instance mean "raw cpu-intensive computation work", sure, one could write a bunch of algorithm in a few different languages and try them out on some different hardware and measure the running time. But in general, it's not possible to say language X performs better than language Y.

Do most languages have many different execution engines ?

Do you mean if most languages have virtual machines? I would say, no, not today. However, many new languages are VM based (or based on some existing VM such as the JVM or the .NET VM).

---

Many languages don't have execution engines - the whole dynamic/static thing revolves around the fact that dynamic capabilities can simplify certain kinds of programming problems by orders of magnitude - but you pay for this at runtime, because things have to be figured out on the fly - common lisp is one of the best examples of this, it's perfectly happy to deal with data and code interchangably, but it's not exactly a speed demon (against native compiled C++ where 100x+ engineering time has been spent to remove dynamic reqts, lisp people, before you start yelling at me)

1) Many languages have focus areas - IFF you know prolog, you'll create a performant rules system a lot faster than someone would in C++ - but if the C++ developer spends 10 times as long, they'll have a system that can run 10 times as fast on 1/10th of the cases

2) You have to distinguish between true compiled languages (classic C++), interpreted languages (classic LISP), VM based languages (Smalltalk, Pascal), and the newer breed of hybrids that present a VM up to the user, but can recompile on the fly on the host machine using peephole optimization (C#, Java) - an interpreted language will always be slower than a native compiled language - native compiled languages do not have execution engines, all others have one form or another of an execution engine

3) The 'fastest' language would be native machine code - not very portable, and hideously expensive to develop in

4) The real questions are;

• How long does it take to express a particular problem in the language
• How long does it take to verify that the problem solution is correct
• How long does it take to move that solution to other environments
• What is the runtime of the solution

Consider - I can write some programs in Smalltalk in a matter of a few minutes that would take me days in C# to make equivalent progress - Now the Smalltalk program runs much more slowly than the C# program, but overall, I spend less time on/with it -

Moral of this story - languages are tools - pick the right tool for the job

---

Most languages have many different execution engines..." I didnt understood the meaning hence asked the question !

In context, the meaning is - most languages have more than one implementation, and program performance depends on which language implementation is used to run the program.

As a trivial example, we'd usually expect programs run with a Java interpreter to use more time than the same programs run with Java Hotspot -

Java -Xint (interpreter) :: Java -server (Hotspot)

---

You can always look at the benchmarks provided by SPEC here: benchmark suite

It's quite common to test the compiler and hardware together.

---

There really isn't a standard meaning of "execution engine" that I know of. The original person was apparently using it to describe a conglomeration of a large number of things.

Many languages are typically compiled to machine code. This means that a compiler translates what the program says into machine code in some way, provides runtime routines and libraries (and that distinction isn't sharp either), and puts everything into an executable package. The compilation process itself may be direct, or may be to something else that is then translated to machine language (the system's assembler language and C are two popular choices).

Many languages are typically interpreted. This means that a compiler will probably translate the source into some intermediate code, which is then executed by an interpreter. In some cases, the interpreter can do its own translation to machine language, and is typically called a JIT (Just In Time) compiler. The original translation step is not mandatory, but common.

There are no languages that must be compiled or must be interpreted (although making an actual Perl compiler would be far more trouble than it's worth). The type of implementation can change: Java was originally considered an interpreted language, until some of the JVM (Java Virtual Machine) interpreters became JIT compilers.

Most popular languages have more than one implementation in general use (Perl probably being the biggest counterexample). Sometimes they're almost all compiled, sometimes they're almost all interpreted. Some languages would be very hard to compile (like Perl), some look like they'd be hard but are commonly compiled (like Lisp), some are pretty much made to be compiled (like C).

So, a given language can have all sorts of implementations, not necessarily of the same sort. There can be different components in different implementations, and the components won't be the same. You could call these systems execution engines if you liked.

Therefore, asking whether language X is faster than language Y is often meaningless, as it depends on the quality of implementations. That being said, some languages are better suited to being compiled (which is faster), and some are better suited to be compiled to fast code, and some languages have one or few common implementations, so I can say that C is usually faster to run than Python.