慢羊羊的空间

看到这个标题后，是不是准备怼我没有常识？

先往下看。

1985 年，Intel 发布了 386 处理器，首次实现了 32 位指令集。那么这时候，你要写个程序，会调用 386 指令集吗？

通常是不会的，因为这么做以后，就等于说，你的程序不能在市面上绝大多数的 PC 上运行，因为其他 PC 都不支持 386 指令集。至少要等上好几年，等 386 普及之后，你才能放心大胆的调用 386 指令集。

等过了 5 年，你觉得 386 指令集可以放心调用时，其实这时候 486 已经诞生了。

实际上，386 的普及远不止 5 年。

高级语言编译器将一条条高级指令编译为汇编指令，这时候，近几年 CPU 新增的指令集，都别指望可以支持。

对于编译器来说，这是一个选择：要么使用新指令集以获得更高的性能，要么不使用新指令集以获得更强的兼容性。对于绝大多数应用而言，都会优先选择兼容性。

再一个假设：在 386 时代，用户购买了你针对最新平台指令集编写的应用。几年后，用户升级到了 486，但是你的程序却没有可能自动支持 486 指令集。

以上两点就是编译的局限性。

意识到这个局限性之后，新一代的托管编程平台 .NET 诞生了。作为该平台的主打语言 C#，相信大家都不陌生。

C# 的代码，在 Visual Studio 里面编译的时候，虽然生成了 .exe，但这个 .exe 只是类似于 Java 那样的字节码，并不是机器代码。在特定目标平台上首次执行这个 .exe 的时候，会再次编译为本机的机器代码。这时候生成的机器代码，是最符合本机硬件特性的机器代码，可以放心的调用本机最新的指令集。所以在性能上，通过调用最新的指令集对性能的提高，弥补了编译生成的冗余代码对性能的影响。随着编译器智能程度的提高，C# 的执行效率超越“缺少最新指令集的汇编语言”，理论上不是问题。

说到 C#，不得不提 Java。

Java 目前仍然是解释执行。为了弥补 Java 解释执行的效率问题，Google 的 Android 在 4.4 的时候引入了一种新的 ART 模式，与 .NET 编译方式类似，都是提前编译为本地机器代码。

Oracle 作为 Java 的家长，本来早就该实现这个功能，可惜 Google 等啊等也没等到，干脆自己实现了。这么多年过去了，Java 还是没有这个功能。不仅如此，Oracle 还隔三差五的扯一扯 Google 的后腿。Google 没办法，自己去搞 Go，以及拉拢 Kotlin……。这边 Oracle 见谁就跟谁掐架，Java 毫无进展；那边在 Microsoft 大旗下，C# 发展的顺风顺水，一路高歌。现在单从语言层面来看，Java 已经完败了。

关于性能问题，C# 开发游戏早已不是新闻。除此以外，还有 C# 写的开源操作系统（COSMOS），有兴趣的可以关注一下：

官网：https://www.gocosmos.org/

从编译项目到在虚拟机里跑起来：https://www.codeproject.com/articles/29523/cosmos-c-open-source-managed-operating-system

PS：临时起兴手码的，一些是个人理解，如有偏差，欢迎探讨。​​​​