简短版：我想知道是否有可能以及如何最好地利用特定于CPU的资源
DLL中的指令？

稍长的版本：
例如，当从Microsoft下载(32bit)DLL时，似乎一个大小适合所有处理器。

这是否意味着它们是严格按照最低公分母(即
操作系统支持的最低平台)？
还是有某种技术可用于导出DLL中的单个接口但可以利用
在后台获得特定于CPU的代码以获得最佳性能？如果是这样，怎么做？

解决方案

该DLL有望在运行WIN32的每台计算机上工作，因此通常会陷入i386指令集的困境。没有公开特定指令集功能/代码的官方方法。我们必须手动透明地进行操作。

基本使用的技术如下：
确定运行时的MMX，SSE等CPU功能

如果存在，请使用它们；如果不存在，请准备好后备代码

因为我们不能让编译器针对i386以外的任何东西进行优化，所以我们必须使用内联汇编器中的特定指令集来编写代码。我不知道是否有更高语言的工具包。确定CPU功能很简单，但是也可能需要在汇编器中完成。

我不知道任何标准技术，但是如果必须做这样的事情，我会在DllMain()函数中编写一些代码以检测CPU类型，并使用指向每个CPU优化版本的函数指针填充跳转表功能。

当CPU类型未知时，还需要一个最低的公分母函数。

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor

我们可以在注册表中找到当前的CPU信息：

获得SSE / SSE2优化的一种简单方法是仅对MSVC使用/ arch参数。我不会担心回退-除非我们有一个非常合适的应用程序，否则没有理由支持低于此的任何内容。

http://msdn.microsoft.com/zh-CN/library/7t5yh4fd.aspx

我相信gcc / g ++具有等效的标志。

从Microsoft下载的DLL是针对通用x86体系结构的，原因很简单，即它必须可以跨所有机器运行。

在Visual Studio 6.0的时间范围内(我不知道它是否已更改)，Microsoft以前一直在优化DLL的大小而不是速度。这是因为DLL整体大小的减少比编译器可以生成的任何其他优化都能带来更高的性能提升。这是因为与不让CPU等待内存的加速相比，微优化的加速肯定会较低。速度的真正提高来自减少I / O或者改进了基础算法。

微程序优化仅因为它们被调用的次数很多，所以运行在程序核心的几个关键循环才能从中受益。代码中只有大约5-10％属于此类别。我们可以放心，Microsoft软件工程师已经可以在汇编器中对此类关键循环进行某种程度的优化，并且不会给编译器留下很多麻烦。 (我知道期望值过高，但我希望他们能做到这一点)

如我们所见，增加的DLL代码只会带来弊端，其中包括很少使用此代码的大多数版本/它们从来都不是消耗大多数CPU周期的关键代码的一部分，而这些代码针对不同的体系结构进行了调整。

英特尔的ICC可以针对不同的体系结构两次编译代码。这样，我们就可以吃蛋糕了。 (好的，我们得到两个蛋糕，DLL会更大)。甚至MSVC2005都能在非常特殊的情况下做到这一点(例如memcpy()可以使用SSE4)

段落数量不匹配