软件博客

英特尔的开发人员社区邀请您参加我们的互动博客，谱写软件发展史

漫谈从RISC向IA移植(2)

作者： Bruce Chen 陈宇达 (Intel) (41 篇文章) 日期： 二月 9, 2010 在 2:12 下午
评论 (0)

下面就说说我个人总结的移植方法论，欢迎板砖。 移植考虑的内容很多，绝不仅仅是软件，要对整个系统通盘考量。我们一一展开讨论，这里面最关键的就是通篇考虑企业基础架构，制定移植计划。 移植首先要分析的就是企业的基础架构，只有基础架构可以顺利移植，才能实现对整个解决方案的移植，否则就会减缓移植的进程，甚至导致移植的失败：  > 移植必须建立在符合要求的企业基础架构之上  > 对基础架构的考量要有系统的变动管理流程，使用流程而不仅仅是经验来进行管理  > 基础架构变动的流程管理一般需要考虑以下方面，所有以下方面均应考虑好移植的可行性，是否有替代方案，分析出移植的可能瓶颈：  >> 网络  ...

继续 ›

分类: 并行计算

摩尔定理再次验证,INTEL 32NM I5来了

作者： avensue (30 篇文章) 日期： 二月 5, 2010 在 1:51 下午
评论 (0)

摩尔定理再次得到验证，更高，更快，更强似乎永远是INTEL的座右铭 45NM的风潮才过去，32NM又来了。不过哪怕到3.2NM，我估计也不会惊讶，因为人类的精神在于进取 附1张表

继续 ›

分类: 图形和视觉计算, 并行计算, 移动技术

如何在一台机器上使用多个版本IPP

作者： 丛杨 (Intel) (4 篇文章) 日期： 二月 4, 2010 在 4:38 下午
评论 (2)

最近在用IPP实现AES的加密模块，为了对比几个版本IPP在加密模块上的性能， 要在同一台机器上装几个版本的IPP。 并在运行同一个执行文件的时候链接不同版本的IPP库。 为了实现这种做法，我们需要在编译的时候链接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 ...

继续 ›

分类: 其他, 并行计算

提高Media SDK效率之异步优化篇

作者： Yanqing Wang (Intel) (11 篇文章) 日期： 二月 4, 2010 在 1:05 下午
评论 (6)

    提高Media SDK效率之多线程篇中已经讲述了如何使用多线程提高编解码的效能问题。因为增加了队列（Queue）的创建和维护等附加工作，在多线程情况下程序的复杂性也被加大，那么还有没有其他方面可以采用呢？本文以此为讨论出发点，主要从异步角度出发，讨论如何采用合适的异步方法来提高编解码器的效能问题。 在多线程方案中，我们使用队列（Queue）的同步机制来保证三个模块的协同工作，如图1所示。                                                 图1 模块线程化输入输出图 从图1中，网友不难发现有两个基本的开销点： - 需要3次同步帧（SyncFrame）来完成一次编解码动作。 - 模块间的2个共享Queue都需要做同步操作。 这两个开销点对于多线程效率和竞争是不利的，那么有什么方法可以剔除或减小这种开销呢？ 幸运的是Media SDK提供了异步机制，它提供了三个函数支持相应的三个模块： - MFXVideoDECODE_DecodeFrameAsync - MFXVideoVPP_RunFrameVPPAsync - MFXVideoENCODE_EncodeFrameAsync 模块异步工作原理如图2所示。 &                                                 图2 模块异步化输入输出图 相比于多线程模式，它有几个优点： - 只需要一次帧同步，而其他两次的异步操作基本上不耗时间，节省了时间。 - 不需要队列的同步操作，提高了效率。 - 不需要多线程，一个线程搞定三个模块，实现复杂度低。 【小结】 - 异步模式对于硬件编解码比较适合。它的效能高，软件复杂度低。在软件编解码中，它的效能和简单串行模式无太多优势，所以可考虑采用多线程模式来实现。 - 多线程模式和异步模式仅仅是提高效率的两种方法，它们之间没有冲突，应用可以根据自身的需求灵活采用，也可以混合运用，提高效率。

继续 ›

分类: 图形和视觉计算, 并行计算

漫谈从RISC向IA移植(1)

作者： Bruce Chen 陈宇达 (Intel) (41 篇文章) 日期： 二月 3, 2010 在 3:11 下午
评论 (1)

计算机已经广泛应用了几十年，许多的传统关键业务也经常传统上就部署在基于RISC的UNIX系统之上。随着计算机技术的不断发展，基于IA架构的解决方案也快速的发展进步，在关键业务领域得到了日益广泛的应用，不断地体现着自己独到的特点和优势。那么，如何从RISC向IA移植呢？经常有客户问到这些，我这里就对移植的方法加以讨论。 一家之言，欢迎板砖。 先说说为什么要移植。 传统上，采用基于RISC的UNIX解决方案主要是基于如下的考虑：  > 性能  > 可扩展性  > 可靠性  > 安全性 在十几年前，这些的确是RISC的优势，但随着IA架构及相关软件的不断发展，企业环境的不断变化，RISC系统受到了越来越大的挑战：  > 企业对价格日益敏感，希望尽可能低的价格实现对不断增长的业务的支持  > 企业对可扩展性持续有着较高需求的同时，希望有足够的灵活性  > 随着IT基础设施的不断扩张，复杂又高昂的IT维护已成为企业的一大负担 随着IA架构的性能、安全可靠性的快速提升，这些挑战的解决恰恰就是IA架构的强项:  > 高性能，高性价比: 以目前最新的Xeon ...

继续 ›

分类: 并行计算

Core i7/i5 vPro 平台新特性 – Intel® AMT KVM

作者： 李铎锋--Duofeng Li (Intel) (57 篇文章) 日期： 二月 1, 2010 在 6:57 下午
评论 (3)

      酝酿已久的Intel(R) AMT KVM特性终于在最近发布的最新Intel(R) Core i7 vPro和Core i5 vPro平台上发布了，新的vPro平台除了CPU采用Intel最新的Core i7和Core ...

继续 ›

分类: 可管理性

提高Media SDK效率之多线程篇

作者： Yanqing Wang (Intel) (11 篇文章) 日期： 一月 28, 2010 在 4:16 下午
评论 (3)

        提高Media SDK效率之初始化设置篇和提高Media SDK效率之内存选择篇中，笔者已经对Media SDK的两个重要配置部分进行了分析和总结。本节，我们将着重讨论如何使用多线程技术提高视频Converter的效能（一种视频的常用应用）。 在运用Media SDK进行格式转换时，一般要涉及三大模块，他们是Decoder，VPP和Encoder，数据输入输出如图1所示。                                                 图1 基本数据输入输出图 从图1可以看出，每经过一个模块，都要对数据进行同步操作。在此期间，其他两个模块是处于空闲状态，是一个典型的串行处理过程。对于英特尔的多核技术，它的多核利用率是最低的，相应的效率也较差。 那么如何对现有流程进行多线程化呢？ 本文提供了一种最简单的方法，即对每个模块线程化。它在实际运用中并非是最佳方案，之所以采用它，仅仅是为了提供一种思路。请参考图2所示。                                                 图2 模块线程化输入输出图 图2将Decoder，VPP和Encoder三个模块分别线程化，在彼此之间以队列（queue）为数据交换。 简单的工作模式如下： - 若队列为空，后级模块等待数据。 - 若队列被填充，前级模块通知后级模块。 - 若无输入数据，前级模块通知后级模块结束工作，后自行了断。 虽然这种线程化的工作增加的程序的复杂性，但是对于赢得的性能而言是值得的。在理想状态下，我们看到三个模块的并行工作，转化时间的长短取决于最为耗时模块。 【小结】 - Media SDK仅仅提供硬件加速能力，线程化工作展开于具体应用。 - 三个模块线程化仅仅是一种简单参考实现，不是最佳方案。如何充分利用英特尔的多核技术，应该建立在具体分析的基础之上。英特尔提供了丰富的性能检测和优化工具，他们能够帮助程序员找出关键问题所在。 - VPP模块是可选的，如果应用没有采用，就将Decoder后的队列直接连接到Encoder之前。

继续 ›

分类: 图形和视觉计算, 并行计算

英特尔平台上使用IPP高性能库加速软件并行化开发（6）

作者： Bruce Chen 陈宇达 (Intel) (41 篇文章) 日期： 一月 27, 2010 在 1:44 下午
评论 (2)

写了这么多关于IPP的文章，很多同学在问，IPP性能提升的效果到底怎么样？我这里就写写IPP的性能表现，也算是IPP文章的收山之作了，来个漂亮的尾巴。 这里以P4为例（也有最新平台的数据，性能表现也很好，但拿不准是不是最新的数据公布处理太敏感，就还是用这个吧），都是用的基本优化后的标准C算法代码，使用IPP之后，跟之前相比： Video处理性能平均提升300% Audio处理性能平均提升200% Image处理性能平均提升260% 向量处理性能平均提升300% 信号处理性能平均提升180% 字符串处理性能平均提升120% 加解密处理性能平均提升30% ... 以我个人的经验，客户的代码用IPP改写后，性能提升多数在1倍以上，如果只有百分之几十，多半是没有使用好，还有空间。 IPP另外的十分明显的好处，就是随着英特尔最新CPU的发布而同步更新，使用者免去了汇编之苦，就可以享受到最新指令集的优势。 好了，就这么多，继续工作了。IPP在英特尔网站上有1个月试用版的下载，欢迎试用，欢迎讨论！

继续 ›

分类: 并行计算

关于科学计算中的数值误差问题

作者： 甘驰 (Intel) (16 篇文章) 日期： 一月 26, 2010 在 3:51 下午
评论 (3)

最近看到有开发HPC应用的程序员反映换了编译器后，新程序的结果不正确。我不禁想起20年前在16位IBM PC AT/XT台式机上开发CAD/CAM程序, 程序在计算边界状况时，如两圆柱的轴夹角为1分求交线，结果经常匪夷所思，都是精度惹得祸。进入64bit时代同样的问题仍然存在，单次运算的精度提高了，但HPC程序中的大量的迭代计算，累积了误差，导致结果不同。我读了Intel同事的文章（http://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler），略有所得，与大家分享。 人们要求结果的复现性有以下几方面， -同一程序，同一数据集，执行若干次的结果相同（近） -同一代码，不同编译选项产生的程序，相同的数据集，执行的结果相同（近） -同一代码，不同编译器产生的程序，相同的数据集，执行的结果相同（近） -同一代码，相同的数据集，在不同架构的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 ...

继续 ›

分类: 并行计算, 英特尔® 软件网络 2.0

读针对AVX优化代码 --- 优化issue port的使用

作者： 甘驰 (Intel) (16 篇文章) 日期： 一月 26, 2010 在 3:50 下午
评论 (1)

本文中的issue port专指CPU内部向其他执行单元(ALU, SSE MUL, DIV, Load, STD…)发送指令的通道，在Intel Micro Architectur(Sandy Bridge)中共有6个ports，port2,3,4负责存储单元，port0,1,5负责计算单元。若干计算单元会共享一个port，由于每个issue ...

继续 ›

分类: 并行计算
历史记录 ›