问C++CLI。本机部件是否用纯C++编写，但在CLI中编译的速度与纯本机C++一样快？

EN

在C++/CLI中，托管类型(例如ref class)及其成员被编译为MSIL。这意味着不再使用SIMD，更不用说优化了(至少在当前版本的.NET中是如此，微软给出的原因不会很快改变，尽管他们可以改变对权衡的评估)。

另一方面，可以将本机类型编译为MSIL或本机代码。虽然VisualC++没有世界上最好的C++优化器，但它非常好。所以我的建议是编译成本机代码。在托管代码和本机代码之间调用时，Visual C++将使用C++互操作，这是非常有效的(与用于所有.NET内置函数(例如字符串连接)使用的internalcall技术相同)。

要实现这一点，您可以将时间紧迫的代码放在一个单独的对象文件中(而不是单独的DLL!，让链接器将托管代码和非托管代码合并到一个“混合模式”程序集中)，或者将其与#pragma managed(push, off) . #pragma managed(pop)放在一起。无论哪种方式，都将使您获得最大限度的优化，并允许您使用SIMD本质为非常快速的代码。

连接C++/CLI层是一种编组工作，其中托管状态被转换为原始类型以封送到非托管层，然后处理，然后封送回封。根据您的算法(以及用于“包装”过渡层的实用方法)，最好保持编组尽可能有界(小)。

因此，这取决于问题:最简单的问题将是一个接口，该接口通过C++/CLI层发送少量原始数据，处理很长时间，然后发送少量数据(例如，最小的编组开销)。如果您的算法需要在C++/CLI层进行更广泛的交互，那么它将变得非常棘手。

"All C#“或"All Managed”的优点是：(1)跳过这个编组层(这是开销，有时根据工作的不同而单调乏味)；(2)运行时优化，.NET引擎可以对运行代码的特定计算机进行优化(您不能使用本机C/C++，也不能使用非托管代码)。

我同意这个线程中的其他评论，您应该/必须用您的场景“测试”它。具有性能敏感转换的“大”C++/CLI层很难实现，因为当您一直在托管/非托管之间跳转时(自动)会发生“装箱/取消装箱”。

最后，混合“托管/非管理”设计与“全管理”设计之间的最终性能差异与以下之间的权衡有关：.NET引擎能否对.NET代码进行特定于机器的优化(例如，利用特定于机器的线程/核心/寄存器)，比“纯本地”代码(它链接到混合模式程序集)能够绕过.NET引擎(它是解释器)快速处理吗？

诚然，编写良好的本机代码可以“检测”处理器线程，但通常不能检测特定于机器的寄存器(除非为目标平台编译)。相反，本机代码没有通过.NET运行时的“开销”，这仅仅是一个虚拟机(它可以通过对特定底层硬件的某些逻辑的实时编译来“加速”)。

复杂的问题。抱歉的。IMHO，如果“性能敏感”是您的问题，那么在这类问题上没有简单的答案。

我建议您看看这篇文章。此外，当试图确定什么是最适合您的代码编写时，您应该(总是)为您的情况做一个小的测试，看看您的实际情况是否有任何不同。