The fastest running code would be carefully hand crafted machine code. Assembler will be almost as good. Both are very low level and it takes a lot of writing code to do things. C is a little above assembler. You still have the ability to control things at a very low level in the actual machine, but there is enough abstraction make writing it faster and easier then assembler. Other languages such as C# and JAVA are even more abstract. While Assembler and machine code are called low level languages, C# and JAVA (and many others) are called high level languages. C is sometimes called a middle level language.

我在链接上找到了一个关于为什么有些语言更快，有些更慢的答案，我希望这将更清楚为什么C或c++比其他语言更快，还有一些其他语言也比C更快，但我们不能使用所有的语言。一些解释-

Fortran仍然重要的一个重要原因是它的速度快:用Fortran编写的数字处理例程往往比用大多数其他语言编写的等效例程要快。在这个领域与Fortran竞争的语言是C和c++，因为它们在性能上具有竞争力。

这就提出了一个问题:为什么?是什么让c++和Fortran速度如此之快?为什么它们比其他流行语言(如Java或Python)性能更好?

解释与编译 根据编程语言所鼓励的编程风格和所提供的特性，有许多方法可以对编程语言进行分类和定义。在性能方面，最大的区别是解释语言和编译语言之间的区别。

划分并不难;而是有一个光谱。在一端，我们有传统的编译语言，包括Fortran、C和c++。在这些语言中，有一个独立的编译阶段，将程序的源代码转换为处理器可以使用的可执行形式。

这个编译过程有几个步骤。对源代码进行分析和解析。基本的编码错误，如错字和拼写错误，此时可以检测到。解析后的代码用于生成内存中的表示，该表示也可用于检测错误——这一次是语义错误，例如调用不存在的函数，或者试图对文本字符串执行算术操作。

然后，这个内存中表示形式用于驱动代码生成器，即生成可执行代码的部分。代码优化，以提高所生成代码的性能，在此过程中的不同时间执行:可以在代码表示上执行高级优化，而在代码生成器的输出上使用低级优化。

实际执行代码发生在后面。整个编译过程只是用来创建可以执行的内容。

在另一端，我们有口译员。解释器将包括一个类似于编译器的解析阶段，但这随后用于驱动直接执行，程序立即运行。

最简单的解释器包含与该语言支持的各种特性相对应的可执行代码，因此它将具有用于添加数字、连接字符串以及给定语言所具有的任何其他功能的函数。当它解析代码时，它将查找相应的函数并执行它。在程序中创建的变量将保存在某种将其名称映射到其数据的查找表中。

解释器风格的最极端的例子是类似批处理文件或shell脚本的东西。在这些语言中，可执行代码通常甚至不内置在解释器本身中，而是单独的独立程序。

So why does this make a difference to performance? In general, each layer of indirection reduces performance. For example, the fastest way to add two numbers is to have both of those numbers in registers in the processor, and to use the processor's add instruction. That's what compiled programs can do; they can put variables into registers and take advantage of processor instructions. But in interpreted programs, that same addition might require two lookups in a table of variables to fetch the values to add, then calling a function to perform the addition. That function may very well use the same processor instruction as the compiled program uses to perform the actual addition, but all the extra work before the instruction can actually be used makes things slower.

如果你想知道更多，请查看来源

这实际上是一个长期存在的谎言。虽然C程序确实经常更快，但情况并非总是如此，特别是当C程序员不太擅长它的时候。

人们往往会忘记的一个明显的漏洞是，当程序必须为某种IO阻塞时，比如任何GUI程序中的用户输入。在这些情况下，使用什么语言并不重要，因为您受到数据传入速度的限制，而不是处理数据的速度。在这种情况下，不管你使用的是C、Java、c#甚至Perl;你不能比数据进入的速度更快。

The other major thing is that using garbage collection and not using proper pointers allows the virtual machine to make a number of optimizations not available in other languages. For instance, the JVM is capable of moving objects around on the heap to defragment it. This makes future allocations much faster since the next index can simply be used rather than looking it up in a table. Modern JVMs also don't have to actually deallocate memory; instead, they just move the live objects around when they GC and the spent memory from the dead objects is recovered essentially for free.

This also brings up an interesting point about C and even more so in C++. There is something of a design philosophy of "If you don't need it, you don't pay for it." The problem is that if you do want it, you end up paying through the nose for it. For instance, the vtable implementation in Java tends to be a lot better than C++ implementations, so virtual function calls are a lot faster. On the other hand, you have no choice but to use virtual functions in Java and they still cost something, but in programs that use a lot of virtual functions, the reduced cost adds up.

1)正如其他人所说，C为你做的更少。没有初始化变量，没有数组边界检查，没有内存管理等。其他语言中的这些特性会消耗C语言不需要的内存和CPU周期。

2) Answers saying that C is less abstracted and therefore faster are only half correct I think. Technically speaking, if you had a "sufficiently advanced compiler" for language X, then language X could approach or equal the speed of C. The difference with C is that since it maps so obviously (if you've taken an architecture course) and directly to assembly language that even a naive compiler can do a decent job. For something like Python, you need a very advanced compiler to predict the probable types of objects and generate machine code on the fly -- C's semantics are simple enough that a simple compiler can do well.

我认为没有人提到这样一个事实，即在C编译器上投入的精力比任何其他编译器都要多，也许Java是例外。

由于前面提到的许多原因，C是非常可优化的——几乎比任何其他语言都要多。因此，如果在其他语言编译器上投入同样的精力，C可能仍然会名列前茅。

I think there is at least one candidate language that with effort could be optimized better than C and thus we could see implementations that produce faster binaries. I'm thinking of digital mars D because the creator took care to build a language that could potentially be better optimized than C. There may be other languages that have this possibility. However I cannot imagine that any language will have compilers more than just a few percent faster than the best C compilers. I would love to be wrong.

我认为真正的“唾手可得的果实”将是那些被设计为易于人类优化的语言。一个熟练的程序员可以让任何语言运行得更快——但有时你不得不做一些荒谬的事情或使用不自然的结构来实现这一点。尽管这总是需要付出努力，但一种好的语言应该产生相对快速的代码，而不必纠结于程序究竟是如何编写的。

It's also important (at least to me) that the worst case code tends to be fast. There are numerous "proofs" on the web that Java is as fast or faster than C, but that is based on cherry picking examples. I'm not big fan of C, but I know that ANYTHING I write in C is going to run well. With Java it will "probably" run within 15% of the speed, usually within 25% but in some cases it can be far worse. Any cases where it's just as fast or within a couple of percent are usually due to most of the time being spent in the library code which is heavily optimized C anyway.

一些c++算法比C快，其他语言中的算法或设计模式的一些实现可能比C快。

当人们说C语言很快，然后转向谈论其他语言时，他们通常是在用C语言的性能作为基准。