这是自动和手动的区别，高级语言是抽象的，因此是自动化的。C/ c++是人工控制和处理的，甚至错误检查代码有时也是人工劳动。

C和c++也是编译语言，这意味着没有任何一种语言可以在任何地方运行，这些语言必须针对您使用的硬件进行微调，从而增加了额外的隐患。尽管现在C/ c++编译器在所有平台上变得越来越普遍，这有点令人不安。您可以在平台之间进行交叉编译。这仍然不是一个到处运行的情况，你基本上是在指示编译器a针对编译器B编译相同的代码，不同的架构。

归根结底，C语言并不意味着容易理解或推理，这也是为什么它们被称为系统语言。他们出现在所有高层次抽象的废话之前。这也是为什么它们不用于前端web编程。他们只是不适合这项任务，他们的意思是解决传统语言工具无法解决的复杂问题。

这就是为什么你会得到一些疯狂的东西(微架构、驱动程序、量子物理、AAA游戏、操作系统)，这些东西C和c++非常适合。速度和数据处理是主要领域。

使用现代优化编译器，纯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.

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语言比现代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。

只需在您的IDE中逐步检查机器代码，您就会看到为什么它更快(如果它更快的话)。它省去了很多手把手的环节。很有可能你的Cxx也会被告知不要使用，在这种情况下，它应该是相同的。

编译器优化被高估了，就像几乎所有关于语言速度的看法一样。

优化生成的代码只会对热点代码产生影响，也就是说，没有函数调用(显式或隐式)的紧凑算法。在其他地方，收效甚微。

我在链接上找到了一个关于为什么有些语言更快，有些更慢的答案，我希望这将更清楚为什么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.

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