有什么能阻止其他语言 能够编译成二进制文件 运行速度和C一样快?

没什么。像Java或。net语言这样的现代语言更多地面向程序员的生产力，而不是性能。现在硬件很便宜。此外，编译到中间表示提供了很多好处，如安全性，可移植性等。net CLR可以利用不同的硬件-例如，你不需要手动优化/重新编译程序来使用SSE指令集。

这不是语言的问题，而是工具和库的问题。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.

实际上，在某些应用程序(数字)中，甚至C也可以被击败，我指的不是汇编语言，而是老的、经常被嘲笑的Fortran。原因是，Fortran保证没有指针别名。

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