我知道很多人都说过这句话，但是:

C更快，因为它(为你)做的更少。

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不会

检查数组下标边界 检查未初始化的变量值 检查内存泄漏 检查空指针解引用

当你索引到一个数组时，在Java中，它接受虚拟机中的一些方法调用，绑定检查和其他健全检查。这是有效的，绝对没问题，因为它在应有的地方增加了安全性。但是在C语言中，即使是非常微不足道的东西也不会被放在安全的地方。例如，C不要求memcpy检查要复制的区域是否重叠。它并不是一种用于编写大型商业应用程序的语言。

但是这些设计决策并不是C语言中的bug。它们是被设计出来的，因为它允许编译器和库编写者从计算机中获得每一点性能。下面是C语言的精神——C语言的基本原理文档是这样解释的:

C code can be non-portable. Although it strove to give programmers the opportunity to write truly portable programs, the Committee did not want to force programmers into writing portably, to preclude the use of C as a ``high-level assembler'': the ability to write machine-specific code is one of the strengths of C. Keep the spirit of C. The Committee kept as a major goal to preserve the traditional spirit of C. There are many facets of the spirit of C, but the essence is a community sentiment of the underlying principles upon which the C language is based. Some of the facets of the spirit of C can be summarized in phrases like Trust the programmer. Don't prevent the programmer from doing what needs to be done. Keep the language small and simple. Provide only one way to do an operation. Make it fast, even if it is not guaranteed to be portable. The last proverb needs a little explanation. The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine's hardware does it rather than by a general abstract rule. An example of this willingness to live with what the machine does can be seen in the rules that govern the widening of char objects for use in expressions: whether the values of char objects widen to signed or unsigned quantities typically depends on which byte operation is more efficient on the target machine.

原因有很多，包括:

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

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

也许最明显的方法是对间接内存引用进行有效性检查——比如检查指针是否为空，检查索引是否符合数组边界。大多数高级语言隐式地执行这些检查，但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程序不太可能比编译后的。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.