使用现代优化编译器，纯C程序不太可能比编译后的。net代码快得多，如果有的话。通过像。net这样的框架为开发人员提供的生产力提高，您可以在一天内完成过去用普通c语言需要几周或几个月才能完成的工作。再加上与开发人员的工资相比，硬件成本低廉，用高级语言编写这些东西并以任何缓慢的速度抛出硬件要便宜得多。

The reason Jeff and Joel talk about C being the "real programmer" language is because there is no hand-holding in C. You must allocate your own memory, deallocate that memory, do your own bounds-checking, etc. There's no such thing as new object(); There's no garbage collection, classes, OOP, entity frameworks, LINQ, properties, attributes, fields, or anything like that. You have to know things like pointer arithmetic and how to dereference a pointer. And, for that matter, know and understand what a pointer is. You have to know what a stack frame is and what the instruction pointer is. You have to know the memory model of the CPU architecture you're working on. There is a lot of implicit understanding of the architecture of a microcomputer (usually the microcomputer you're working on) when programming in C that simply is not present nor necessary when programming in something like C# or Java. All of that information has been off-loaded to the compiler (or VM) programmer.

撇开诸如热点优化、预编译元算法和各种形式的并行等高级优化技术不提，语言的基本速度与支持通常在内部循环中指定的操作所需的隐含的幕后复杂性密切相关。

也许最明显的方法是对间接内存引用进行有效性检查——比如检查指针是否为空，检查索引是否符合数组边界。大多数高级语言隐式地执行这些检查，但C不这样做。然而，这并不一定是这些其他语言的基本限制——一个足够聪明的编译器可能能够通过某种形式的循环不变代码运动，从算法的内部循环中删除这些检查。

C语言(在类似程度上与c++密切相关)更基本的优势是严重依赖基于堆栈的内存分配，这本质上是快速的分配、回收和访问。在C(和c++)中，主调用堆栈可用于分配原语、数组和聚合(结构/类)。

虽然C语言确实提供了动态分配任意大小和生命周期的内存的能力(使用所谓的“堆”)，但默认情况下是避免这样做的(而是使用堆栈)。

诱人的是，有时可以在其他编程语言的运行时环境中复制C内存分配策略。asm.js已经证明了这一点，它允许用C或c++编写的代码被翻译成JavaScript的子集，并以接近本机的速度安全地运行在web浏览器环境中。

As somewhat of an aside, another area where C and C++ outshine most other languages for speed is the ability to seamlessly integrate with native machine instruction sets. A notable example of this is the (compiler and platform dependent) availability of SIMD intrinsics which support the construction of custom algorithms that take advantage of the now nearly ubiquitous parallel processing hardware -- while still utilizing the data allocation abstractions provided by the language (lower-level register allocation is managed by the compiler).

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。

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语言中操作的代价相比，对对象(特别是反射)或字符串的高级操作可能具有不明显的代价。

标准ML(使用MLton编译器)和Objective Caml这两种语言通常编译成二进制文件的速度与C语言一样快。如果你检查一下基准测试游戏，你会发现对于一些基准测试，比如二叉树，OCaml版本比c更快(我没有找到任何MLton的条目)。但不要把枪战看得太严重;正如它所说的，它是一个游戏，结果通常反映了人们在调优代码上投入了多少精力。

原因有很多，包括:

它被编译成汇编语言。 它是静态类型的。 没有垃圾回收。 没有异常机制。 编译器优化 C语言的哲学之一是保持简单并保持向后兼容性，而不是添加更多的特性。