托管代码可以像未托管代码一样快速地执行计算吗

"能"吗？是的，当然。即使没有不安全/不可验证的代码，经过良好优化的.NET代码也可以胜过本机代码。举个例子，Jon Harrop博士在这个话题上的回答：科学计算中的F#性能

会吗？通常情况下，不会，除非您采取方式来避免分配。

.NET不是超级慢的，但它也不属于母语。对于一款更喜欢安全和更短开发周期的商业应用程序来说，速度差是很容易接受的。如果你没有在CPU上使用每个周期，那么你使用多少并不重要，事实上，许多甚至大多数应用程序根本不需要这种性能。然而，当确实需要这种性能时，.NET不会提供。

更重要的是，它还不够可控。在C++中，您可以销毁每一个资源，管理每一个分配。当你真的不想这样做的时候，这是一个很大的负担——但当你需要微调每个分配的额外性能时，这是不可能击败的。

另一件需要考虑的事情是编译器。我的意思是，JIT可以访问有关程序和目标CPU的更多信息。然而，它确实每次都必须从头开始重新编译，而且这样做的时间限制比C++编译器大得多，这从本质上限制了它的能力。CLR语义，就像每次为每个对象分配堆一样，也从根本上限制了它的性能。托管GC分配非常快，但它没有堆栈分配，更重要的是，它是去分配。

编辑：当然，.NET提供了与（大多数）本机语言不同的内存控制范式，这意味着对于垃圾收集特别适合的应用程序来说，.NET代码可能比本机代码运行得更快。然而，这与托管代码与本机代码无关，只是为正确的工作选择了正确的算法，这并不意味着从本机代码中使用等效的GC算法不会更快。

简短回答是，长回答有足够的工作量。

有一些高频率的交易应用程序是用托管C#.NET编写的。很少有其他应用程序能达到交易引擎所要求的时间关键性。总体概念是，您开发的软件非常高效，您的应用程序将不需要垃圾收集器为非0代对象调用自己。如果垃圾收集器在任何时候启动，您都会有一个持续数十或数百毫秒的巨大延迟（从计算时间的角度来看），这是不可接受的。

您可以使用不安全的和指针来获得"原始"内存访问，这可以显著提高速度，但代价是对您的东西承担更多责任（记住固定您的对象）。在这一点上，您只是在移动字节。

垃圾收集压力可能是一件有趣的事情，但也有一些策略（对象池）。

这似乎是一个过于宽泛的问题。

这里有一些免费的提示：是的，您可以使用unsafe、unchecked、结构数组，最重要的是使用C++/CLI。

C++的内联、compiletime模板扩展（以及类似的优化）等永远不会匹配。

但底线是：这取决于问题。是computations。Mono有漂亮的扩展来使用SIMD指令，在Win32上，您必须使用本机才能获得这些指令。Interop在作弊。

不过，根据我的经验，移植玩具项目（如解析器和Chess引擎）将导致至少一个数量级的速度差异，无论你如何优化。NET方面的东西。我认为这主要与堆管理和服务例程（System.String、System.IO）有关

可能会有很大的陷阱。NET（过度使用Linq、lambdas，意外地依赖Enum.HasFlag来执行像位操作一样的操作…）等YMMV，并仔细选择您的武器