For the most part, every C instruction corresponds to a very few assembler instructions. You are essentially writing higher level machine code, so you have control over almost everything the processor does. Many other compiled languages, such as C++, have a lot of simple looking instructions that can turn into much more code than you think it does (virtual functions, copy constructors, etc..) And interpreted languages like Java or Ruby have another layer of instructions that you never see - the Virtual Machine or Interpreter.

这都是时间和努力的问题。

给予无限的时间和努力:

汇编程序比用C语言编写的程序要快。 C程序将比用c++编写的程序更快。

固定的:给定一定的时间和努力:

c++程序比用C编写的程序要快。 C语言的程序比用汇编语言编写的程序要快。

为什么?因为你做的抽象越多，你就可以花更多的时间来优化真正重要的代码关键部分。这里的几个假设是，一个开发人员对这三种语言都有同样的能力，你不关心二进制大小、内存使用情况等。

每种抽象都有其成本效益，但应该使代码更容易、更快地编写。

这实际上是一个长期存在的谎言。虽然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.

The lack of abstraction is what makes C faster. If you write an output statement you know exactly what is happening. If you write an output statement in java it is getting compiled to a class file which then gets run on a virtual machine introducing a layor of abstraction. The lack of object oriented features as a part of the language also increases it's speed do to less code being generated. If you use C as an object oriented language then you are doing all the coding for things such as classes, inharitence, etc. This means rather then make something generalized enough for everyone with the amount of code and the performance penelty that requires you only write what you need to get the job done.

C语言并不总是更快。

C语言比现代Fortran语言慢。

在某些方面，C通常比Java慢。(特别是在JIT编译器对您的代码进行了测试之后)

C允许发生指针混叠，这意味着一些好的优化是不可能的。特别是当您有多个执行单元时，这将导致数据获取停滞。噢。

指针算术工作的假设确实会导致某些CPU系列(特别是PIC !)它曾经在x86上很差劲。

基本上，当你得到一个矢量单元，或者一个并行编译器，C语言很糟糕，而现代的Fortran运行得更快。

C程序员的一些技巧，比如thking(动态修改可执行文件)会导致CPU预取暂停。

明白我的意思了吗?

而我们的好朋友x86执行的指令集，如今与实际的CPU架构关系不大。影子寄存器，负载存储优化器，都在CPU中。所以C离虚拟金属很近。真正的金属，英特尔不会让你看到。(从历史上看，VLIW CPU有点破产，所以，也许这并不是那么糟糕。)

如果你在高性能DSP上用C编程(可能是TI DSP ?)，编译器必须做一些棘手的事情，在多个并行执行单元之间展开C。因此，在这种情况下，C语言并不接近金属，但它接近编译器，它将进行整个程序优化。奇怪。

最后，一些cpu (www.ajile.com)在硬件中运行Java字节码。C将在该CPU上使用一个PITA。

我猜你忘了汇编语言也是一种语言:)

但是说真的，只有当程序员知道自己在做什么的时候，C程序才会更快。你可以很容易地编写一个C程序，它比用其他语言编写的程序运行得更慢。

C语言之所以更快，是因为它就是这样设计的。它允许你做很多“低级”的事情，帮助编译器优化代码。或者，我们可以说，你程序员负责优化代码。但这通常相当棘手，而且容易出错。

其他语言，就像前面提到的其他语言一样，更关注程序员的生产力。人们普遍认为程序员的时间比机器的时间要昂贵得多(即使在过去)。因此，尽量减少程序员花在编写和调试程序上的时间，而不是减少程序的运行时间，是很有意义的。为了做到这一点，您将牺牲一些可以使程序更快的事情，因为许多事情都是自动化的。