移植考虑的内容很多，绝不仅仅是软件，要对整个系统通盘考量。我们一一展开讨论，这里面最关键的就是通篇考虑企业基础架构，制定移植计划。

移植首先要分析的就是企业的基础架构，只有基础架构可以顺利移植，才能实现对整个解决方案的移植，否则就会减缓移植的进程，甚至导致移植的失败：
 > 移植必须建立在符合要求的企业基础架构之上
 > 对基础架构的考量要有系统的变动管理流程，使用流程而不仅仅是经验来进行管理
 > 基础架构变动的流程管理一般需要考虑以下方面，所有以下方面均应考虑好移植的可行性，是否有替代方案，分析出移植的可能瓶颈：
 >> 网络
 >> 操作系统
 >> 身份管理（ID）
 >> 软件栈全生命周期
 >> 系统配置
 >> 数据
 >> 服务器、存储、交换机等硬件系统

下面就是从RISC向IA移植的基本考虑方面示意图：

45NM的风潮才过去，32NM又来了。不过哪怕到3.2NM，我估计也不会惊讶，因为人类的精神在于进取

附1张表

为了实现这种做法，我们需要在编译的时候链接IPP的动态库。
在运行执行文件的时候，修改链接库的目录。

下面举一个例子，系统是linux，Windows应该同理。

假设源代码文件a.cpp,编译生成的执行文件为a_exec,另外IPP有两个版本：ipp版本A，ipp版本B。

1）如果版本A和版本B的大版本号一致，例如都是6.1.***，那么可以不用重新编译

编译的命令为：

g++ -o a_exec a.cpp -I /ipp版本A or B的安装目录/include， ipp_aes.cpp -L /ipp版本A or B的安装目录/sharedlib -

lpthread -lippcpem64t -lguide

生成的执行文件 a_exec 在执行的时候可以选择链接版本A的库或是版本B的库。

执行命令为：
# export export LD_LIBRARY_PATH=/ipp版本A/sharedlib
# ./a_exec
结果为使用IPP版本A的结果

# export export LD_LIBRARY_PATH=/ipp版本B/sharedlib
# ./a_exec
结果为使用IPP版本B的结果

2）如果版本A和版本B的大版本号不一样，比如A为6.1.***，B为5.*.**,文件需要分别编译：

使用版本A：
# g++ -o a_exec a.cpp -I /ipp版本A的安装目录/include， ipp_aes.cpp -L /ipp版本A的安装目录/sharedlib -lpthread  -lippcpem64t -lguide

# export export LD_LIBRARY_PATH=/ipp版本A/sharedlib
# ./a_exec

使用版本B：
# g++ -o a_exec a.cpp -I /ipp版本B的安装目录/include， ipp_aes.cpp -L /ipp版本B的安装目录/sharedlib -lpthread  -lippcpem64t -lguide

# export export LD_LIBRARY_PATH=/ipp版本B/sharedlib
# ./a_exec

这样就可以分别得到使用不同IPP库的性能数据了。

如果要在另外一台机器上运行这个执行文件，
只需把执行文件，以及相应IPP版本的动态库拷贝到这台机器上，并在执行前运行：
# export export LD_LIBRARY_PATH=ipp库所在的目录
就可以看到这个执行文件在这台机器上的性能数据了。

OK，就是这样。
P.S. 最新版的IPP性能还真是不错。
P.P.S.希望我也能跟duofeng同学一样把工作里遇到的方法记录下来，哪怕只是很小很小的一点。
P.P.P.S.这次测试的数据以及编写的代码应该会在不久后就可以发布。

在多线程方案中，我们使用队列（Queue）的同步机制来保证三个模块的协同工作，如图1所示。

                                                图1 模块线程化输入输出图

从图1中，网友不难发现有两个基本的开销点：
- 需要3次同步帧（SyncFrame）来完成一次编解码动作。
- 模块间的2个共享Queue都需要做同步操作。

这两个开销点对于多线程效率和竞争是不利的，那么有什么方法可以剔除或减小这种开销呢？
幸运的是Media SDK提供了异步机制，它提供了三个函数支持相应的三个模块：
- MFXVideoDECODE_DecodeFrameAsync
- MFXVideoVPP_RunFrameVPPAsync
- MFXVideoENCODE_EncodeFrameAsync

模块异步工作原理如图2所示。
&
                                                图2 模块异步化输入输出图

相比于多线程模式，它有几个优点：
- 只需要一次帧同步，而其他两次的异步操作基本上不耗时间，节省了时间。
- 不需要队列的同步操作，提高了效率。
- 不需要多线程，一个线程搞定三个模块，实现复杂度低。

【小结】
- 异步模式对于硬件编解码比较适合。它的效能高，软件复杂度低。在软件编解码中，它的效能和简单串行模式无太多优势，所以可考虑采用多线程模式来实现。
- 多线程模式和异步模式仅仅是提高效率的两种方法，它们之间没有冲突，应用可以根据自身的需求灵活采用，也可以混合运用，提高效率。

一家之言，欢迎板砖。

先说说为什么要移植。

传统上，采用基于RISC的UNIX解决方案主要是基于如下的考虑：
 > 性能
 > 可扩展性
 > 可靠性
 > 安全性

在十几年前，这些的确是RISC的优势，但随着IA架构及相关软件的不断发展，企业环境的不断变化，RISC系统受到了越来越大的挑战：
 > 企业对价格日益敏感，希望尽可能低的价格实现对不断增长的业务的支持
 > 企业对可扩展性持续有着较高需求的同时，希望有足够的灵活性
 > 随着IT基础设施的不断扩张，复杂又高昂的IT维护已成为企业的一大负担

随着IA架构的性能、安全可靠性的快速提升，这些挑战的解决恰恰就是IA架构的强项:
 > 高性能，高性价比: 以目前最新的Xeon 5570为例，根据公开测试的标准SPEC fp/int/jbb，其性能是某RISC品牌对应最新产品的1.9至2.9倍；性价比更是大幅的提升
 > 广泛的软硬件支持: IA架构有着广泛的软硬件支持基础，几乎所有的OEM厂商均有相关的硬件产品，选择空间巨大；也几乎所有的企业应用软件供应商提供对应的可靠的软件版本。
 > 开放的环境，不存在单一供应商的锁定：
 > 可以快速的采用新技术和新应用

下图就是RISC与IA架构的简要对比示意：

正是基于这些考虑，越来越多的解决方案走向了开放的IA架构。

        KVM是Keyboard、Video and Mouse的缩写，KVM设备目前已经被广泛应用。一般的应用模式是：通过KVM设备，同一套键盘、鼠标和显示器可以同时操作多台计算机，能操作的计算机台数取决于使用的KVM设备支持的端口数，一般有4口、8口、16口、24口；但普通的KVM设备比较遗憾的一点是无法通过网络传输，这就限制了键盘、鼠标和显示器与被操作的设备距离不能太远。市场上也有支持跨网络的KVM连接的设备，这样的设置支持KVM Over IP的特性，功能比普通的KVM设备要复杂，可以直接连接到局域网，然后控制台可以通过IP访问KVM设备，然后打开相应的设备就能远程操作。笔者实验室就有一台Avocent AutoView 3200就支持KVM Over IP，可以通过网络远程直接控制多达16台计算机，不过同时只能打开两台机器的界面；另外有一点不是很好的是，如果客户机死机了，远程重启没办法做到，还是需要本地去重置电源；这个设备的价格也是比较昂贵的，一般都要好几万人民币。

        最新Intel(R) Core i7/i5 vPro平台支持的最新Intel(R) AMT的KVM特性就能实现以前类似于KVM Over IP设备的功能，通过Intel(R) AMT KVM，被管理终端机的键盘、鼠标和显示能够通过AMT被重定向到远程控制台；并且结合Intel(R) AMT已有的远程控制的能力，可以在客户端失去响应的情况下远程重启，真正意义上实现了远程操控和管理；另外，结合最近的Intel(R) AMT的Fast Call for Help特性，可以做到跨防火墙远程控制客户机。

        Intel(R) AMT KVM特性使得Intel(R) AMT能够更好的支持更多的使用模式，比如：

               ¨ 客户机端蓝屏时，需要IT操作员帮忙查看蓝屏信息；
               ¨客户机操作系统无法响应或处于修复模式时，其他的基于操作系统的远程显示应用无法工作；
               ¨客户机操作系统还未正常工作，处于远程安装或修复时，随后的重启动作需要远程安装人员确认时；
               ¨ 客户机处于待机(S3)状态时，IT操作员需要远程唤醒并操作；
               ¨客户机平台启动时，需要在BIOS（文本显示）和操作系统（图形显示）启动过程中进行交互，IT操作员可以远程查看和控制整个启动过程。

      基于Intel(R) AMT KVM特性的使用模式绝对不仅仅限于上面提到的几点，只要咱们劳动人民发挥我们的聪明才智，肯定是能够更好的利用起来，以解决不同场景的问题，满足不同用户的要求。笔者相信，Intel(R) AMT KVM新特性是Intel(R) AMT技术发展历史中具有重要里程碑意义的特性，有了此特性，远程操作、远程诊断和远程修复及其引申出来的需求才真正意义上得到了完美解决，也一定能吸引越来越多的IT管理人员的目光，进一步将Intel(R) AMT其他特性应用起来。

        关于Intel(R) AMT KVM特性的更多细节和开发相关的问题，笔者将在随后的文章中进一步介绍，敬请期待………

在运用Media SDK进行格式转换时，一般要涉及三大模块，他们是Decoder，VPP和Encoder，数据输入输出如图1所示。

                                                图1 基本数据输入输出图

从图1可以看出，每经过一个模块，都要对数据进行同步操作。在此期间，其他两个模块是处于空闲状态，是一个典型的串行处理过程。对于英特尔的多核技术，它的多核利用率是最低的，相应的效率也较差。

那么如何对现有流程进行多线程化呢？

本文提供了一种最简单的方法，即对每个模块线程化。它在实际运用中并非是最佳方案，之所以采用它，仅仅是为了提供一种思路。请参考图2所示。

                                                图2 模块线程化输入输出图

图2将Decoder，VPP和Encoder三个模块分别线程化，在彼此之间以队列（queue）为数据交换。
简单的工作模式如下：
- 若队列为空，后级模块等待数据。
- 若队列被填充，前级模块通知后级模块。
- 若无输入数据，前级模块通知后级模块结束工作，后自行了断。

虽然这种线程化的工作增加的程序的复杂性，但是对于赢得的性能而言是值得的。在理想状态下，我们看到三个模块的并行工作，转化时间的长短取决于最为耗时模块。

【小结】
- Media SDK仅仅提供硬件加速能力，线程化工作展开于具体应用。
- 三个模块线程化仅仅是一种简单参考实现，不是最佳方案。如何充分利用英特尔的多核技术，应该建立在具体分析的基础之上。英特尔提供了丰富的性能检测和优化工具，他们能够帮助程序员找出关键问题所在。
- VPP模块是可选的，如果应用没有采用，就将Decoder后的队列直接连接到Encoder之前。

这里以P4为例（也有最新平台的数据，性能表现也很好，但拿不准是不是最新的数据公布处理太敏感，就还是用这个吧），都是用的基本优化后的标准C算法代码，使用IPP之后，跟之前相比：
Video处理性能平均提升300%
Audio处理性能平均提升200%
Image处理性能平均提升260%
向量处理性能平均提升300%
信号处理性能平均提升180%
字符串处理性能平均提升120%
加解密处理性能平均提升30%
...

以我个人的经验，客户的代码用IPP改写后，性能提升多数在1倍以上，如果只有百分之几十，多半是没有使用好，还有空间。

IPP另外的十分明显的好处，就是随着英特尔最新CPU的发布而同步更新，使用者免去了汇编之苦，就可以享受到最新指令集的优势。

好了，就这么多，继续工作了。IPP在英特尔网站上有1个月试用版的下载，欢迎试用，欢迎讨论！

人们要求结果的复现性有以下几方面，
-同一程序，同一数据集，执行若干次的结果相同（近）
-同一代码，不同编译选项产生的程序，相同的数据集，执行的结果相同（近）
-同一代码，不同编译器产生的程序，相同的数据集，执行的结果相同（近）
-同一代码，相同的数据集，在不同架构的CPU上执行的结果相同（近）
最好运行速度也要快。这些要求有时是相互矛盾的。让我们先分析计算结果有差别的原因，注意这里我用了差别，而不是误差。

首先，通常十进制的浮点数用二进制数表示时就有误差，便有了‘原罪’。

其二，计算机运算是不符合结合律的，如A+B+C不一定等于A+(B+C)。当A= -B且C为极小值时，A+B+C=C，但A+(B+C)=0，极小值C和B相加时由于精度限制，被忽略了或者说表示B的有效位不能包含C的值；但A+B=0,再加C后，结果为C。当你多线程或多进程化程序运行时，原来的数据被切成几分，分给不同的进程/线程执行，于是原先的次序被打破，用MPI或OpenMP的程序都有引入的这类潜在的结果差别。

其三，X87 FPU是以80位（1位符号，15位指数，64位数值）、扩展双精度浮点数运算的。SIMD执行单元可能不是（查遍手册，未见答案，至少其数据是以64位存放的）。

其四，四舍五入，(a) 1.0001 0000 1000 0011 1001 0111E2 101以单精度数表示时需要四舍五入，因为其数值有25位，超过单精度浮点数的24位。根据系统设置，有四种模式可选，
-Round to nearest (even) --- 选精度误差最小的
-Round down (toward −∞) -- 选精度误差最小的, 但不大于原数
-Round up (toward +∞) --选精度误差最小的, 但不小于原数
-Round toward zero (Truncate) --选精度误差最小的, 但其绝对值不大于原数

其五，Flush-to-zero 和 denormal-to-zero. 如设定flush-to-zero, 当浮点运算发生underflow时，返回0值而不是像IEEE754要求的，返回非正规数据（denormalized data），这主要是为了提升性能。Denormal-to-zero是将非正规数据操作数置零，也是为性能。

 其六，不良的编程习惯。如变量不置初值等

我的同事将随后发如何巧用Intel编译器的选项避免结果差别，和如何发现导致结果差别的代码。

 Intel® 64 and IA-32 Architectures Optimization Reference Manual（248966）的54页列出了(Nehalem)issue port 和执行单元的对应关系。下表建立执行单元与port的关系

当你的程序大量使用那些只有一个issue port能发送的指令，要引起注意。当然Intel编译器会帮你优化，除非你直接写汇编。