Now it has Polyhedral guided optimization that can do more complex loop optimizations. In order to reduce compile time and resource consuming, this polyhedral model is only used for dependence analysis and loop transformation like tiling.

XL C also use profile guided optimization for data prefetch ( stream prefetch, stride prefetch) and data reorganization, especially the array reorganizations.XL C compiler has 5 optimization optmizations.

XL C can make use of BlueGene/Q’s speculative execution. This type of execution is much like the branch speculation in ILP of CPU. A brief introduction of BlueGene/Q’s speculation execution[2].

The same versioning facility can also be used for speculative execution. Instead of having to wait for up-to-date versions of all the data it needs—which might require, for example, waiting for another core to finish a computation—a thread can begin executing with the data it has, speculatively performing useful work. If it turns out that the data was up-to-date, it can commit that work, giving a performance boost: the work was done before the final value was delivered. If it turns out that the data was stale, the speculative work can be abandoned, and re-executed with the correct value.

XL C also has a efficient auto-vectorization framework whick can make use of Power’s 2 128-bit wide SIMD units( 2x FP/VSX unit and 2x VMX unit).VSX is short for Vector and Scalar Extension, and VMX is short for Vector media extension.

Like ICC , XL C also have a compiler optimization feedback, which can give users that which code and why it cannot be optimized.

A commercial compiler should not only translate code into binaries, but also give users higher performance code using optimizations and hints about how to manually help compilers to optimize the code.

Reference:

• http://www-01.ibm.com/software/awdtools/xlcpp/
• http://arstechnica.com/hardware/news/2011/08/ibms-new-transactional-memory-make-or-break-time-for-multithreaded-revolution.ars

您可能也喜欢：

大软件的烦恼与编译技术

Stencil codes

Open64编译器 5.0版本发布

Open64课程-循环嵌套优化(LNO)

JAVA虚拟机入门

无觅

相关文章：

• JIT Compiler and Virtual Machine SW Engineer for Web Browsers in Qualcomm
• AMD intern and full time compiler position based on OpenCL and LLVM
• MNC need compiler expert
• TIPS for writing easily auto-vectorized code
• TraceMonkey in SpiderMonkey
• 自动向量化

您可能也喜欢：

多面体模型是编译器循环优化的未来吗？

Open64课程-循环嵌套优化(LNO)

SIMD硬件的发展

通用微处理中的SIMD指令扩展

Some notes about IBM XL C Compiler

无觅

相关文章：

• Some notes about IBM XL C Compiler
• 通用微处理中的SIMD指令扩展
• 自动向量化的研究现状
• Open64课程-循环嵌套优化(LNO)
• 自动向量化
• 向量处理器VS标量处理器中的向量扩展

昨天，Intel刚刚发布了AVX2指令集，这套指令集在AVX基础上做了扩展，不过要在2013年发布的Haswell处理器上才能支持。参考1给出了AVX2的详细特性。

AVX2指令集概述

相比AVX，AVX2在如下方面做了扩展。

• 支持的整点SIMD数据宽度从128位扩展到256位。Sandy Bridge虽然已经将支持的SIMD数据宽度增加到了256位，但仅仅增加了对256位的浮点SIMD支持，整点SIMD数据的宽度还停留在128位上，
• 增强广播、置换指令支持的数据元素类型、移位操作对各个数据元素可变移位数的支持、跨距访存支持。

跨距访存支持

跨距访存支持即访存时，每个SIMD数据的向量数据元素可以来自不相邻的内存地址。AVX2的跨距访存指令称为”gather”指令，该指令的操作数是一个基地址加一个向量寄存器，向量寄存器中存放着SIMD数据中各个元素相对基地址的偏移量是多少。有了这条指令，CPU可以轻松用一条指令实现若干不连续数据”聚集”到一个SIMD寄存器中。这会对编译器和虚拟机充分利用向量指令带来很大便利，尤其是自动向量化。另外，参考2中对跨距访存指令的功能描述中可以看到，当该指令的偏移地址向量寄存器中任何两个值相同时，都会出GP错。这意味着编译器还是需要些特殊处理才能利用好这条指令。

跨距访存指令

但跨距访存指令仅仅支持32位整点、64位整点、单精度浮点、双精度浮点的跨距访存操作。从参考4可以猜测其实gather指令只是在硬件上分解成若干条32位或64位的微访存指令实现。这就移位着其实一条32×8的SIMD访存其实就是8次32位普通数据访存，其访存延时和延时不确定性会非常大，聊剩于无。

拓宽原有整点SIMD指令

理论上从128位到256位的成倍SIMD宽度扩展能带来一倍的加速。

从128位扩展到256位的整点SIMD指令

位操作指令支持

这些指令在加速数据库压缩、哈希，大数的算术计算方面会有帮助。

新增的位访存操作指令

任意位置的SIMD数据置换支持

这一支持将使编译器可以更灵活的使用这条指令协助自动向量化。像参考5这类工作就能实施在Intel的芯片中。

任意位置数据置换指令支持

向量-向量移位支持

之前Intel上的所有SIMD扩展指令的移位操作仅支持所有SIMD数据同时移位相同的位数，有了向量-向量移位支持，就可以为每个SIMD数据做不同的移位操作。

向量-向量移位操作支持

浮点乘法累积操作

之前的X86处理器上的累积操作多数针对整点数据，这次针对浮点数据增加的60条SIMD操作会给Intel跑浮点Benchmark，比如linpack之类的带来很多加速。

《编译点滴》评论

之前几乎所有在通用微处理器上的SIMD指令，都倾向于一刀切策略，即所有的SIMD操作都针对SIMD数据实施完全相同的操作，并不存在特性化的指令。比如访存都是从一块连续的地址空间直接访存、移位时所有的数据都移动相同的位数，数据置换指令的支持也是最近才出现在通用CPU中的。AVX2的这些支持再次肯定了个性化的趋势，CPU中的SIMD支持朝着GPU的方向大踏步前进，并最终赶上并超越向量机。不得不称赞一下IBM的超前思想。AVX2中的这些特性支持在几年前的Power处理器中就已经出现了。

虽然AVX号称可以扩展到512位甚至1024位的SIMD支持，但是所带来的问题怎么解决，期待AVX3或者AMD的小宇宙爆发，或者威盛的黑马：

1. 理论上，增加1倍的向量数据宽度，将带来2倍的晶体管数量提升。目前，Intel的AVX指令集只实现在片上每个core里，作为core中的一个功能部件，若扩展到1024位，将增加4倍的晶体管。虽然制造工艺也会改进，但功耗还是会很大，怎么解决？
2. 在自动向量化仍然不好用的前提下，普通程序很难利用到这些功能做加速，白白的浪费这些晶体管吗？
3. 这么大的数据计算能力，访存怎么供数？对齐貌似还是没有好的方法。还是要程序员自己吭哧吭哧写向量化代码，调试吗？芯片厂商可以每几年升级一次宽度，但兼容性如何保证，原来有64位、128位、256位分别对应MMX、XMM、YMM寄存器，以后呢？
   

参考

1. http://software.intel.com/en-us/blogs/2011/06/13/haswell-new-instruction-descriptions-now-available/
2. http://software.intel.com/file/36945
3. http://en.wikipedia.org/wiki/Haswell_%28microarchitecture%29
4. http://software.intel.com/en-us/forums/showthread.php?t=83459&o=a&s=lr
5. http://portal.acm.org/citation.cfm?id=1133996

您可能也喜欢：

通用微处理中的SIMD指令扩展

SIMD硬件的发展

Some notes about IBM XL C Compiler

zz 龙芯之火，可以燎原（上）

自动向量化

无觅

相关文章：

• Intel Sandy Bridge怎么给力
• 通用微处理中的SIMD指令扩展
• SIMD硬件的发展
• 前瞻-主流处理器中的数据并行支持(SIMD)
• 期待未来-一张趣图
• 好消息：GodSon-T第一款芯片已经流片归来，正在测试

目前实现自动向量化的方式有主要有两种：

• 基于循环的自动向量化： 通过分析循环，对于无数据依赖的并行迭代，直接生成对应的向量指令的方式实现向量化。
• 基于基本块的自动向量化： 通过循环展开，得到较大的基本块，然后收集循环中的相同操作，合成后端CPU支持的SIMD操作，实现向量化。

基于循环的自动向量化

基于循环的自动向量化早在上世纪80年代就在向量机系统上得到了广泛应用，其中又以Randy Allen的工作最为著名。 Randy Allen为了在向量机上让历史遗留代码充分利用处理器，开发了一个Fortran到Fortran 8x的代码编译器，其中Fortran 8x中支持向量操作。 该过程就是一个基于循环的自动向量化过程。 为了将循环向量化，作者首先对循环体进行依赖分析，找出无数据依赖的循环迭代， 通过设定循环控制变量每次迭代的跨度，决定有多少个循环迭代被转换成相应的向量指令。 这一机制，使得Fortran能更好的利用向量运算。从Benchmark来看，向量化的加速度大约10倍。

Konrad T. 等人研究了如何把循环自动向量化和其他循环优化映射到多面体模型中。 并在这一模型中，针对这些循环优化，构建统一的代价模型，通过衡量代价模型找出最佳的优化方式。 一般的自动向量化需要事先设定针对最内层循环还是最外层循环作自动向量化。 而本文则可以通过多面体模型自动判断对哪一层循环做向量化。 在作者使用的Benchmark上，基于CELL处理器的测试显示，相比于普通标量有3.5倍的加速比， 相比基于GCC的直接最内层循环向量化有2.3倍的加速；相比直接外层循环向量化，有36%的加速。 在IBM PPC970处理器上，相比串行程序有2.9倍的加速，相比内层循环向量化有2.3倍的加速， 相比外层循环向量化有50%的加速。

Alexandre E. E等人在循环中，考虑有非对齐访存情况下的自动向量化， 提出了一种系统的解决该问题的编译架构。 作者的机制通过在SIMD寄存器中自动拼接数据来满足硬件的对齐需求， 这种拼接多数基于位移的操作，即整个寄存器位移元素长度的整数倍的方式， 位移的操作最终会转换成目标机中的vperm置换指令。 通过vperm置换操作，数据就被有序的组织在向量寄存器中， 接着作者通过向量化数据操作语句的方式，生成向量指令。 作者选定了一些75%以上的数据访存是非对齐的例子，在支持128位向量数据的IBM Altiec上，对于单精度浮点例子，加速比3.71; 对于半字整点例子，加速比6.06。

Doriy Nuzman等人针对通用CPU中的短SIMD结构，研究如何对外层循环做自动向量化， 并在GCC中实现之，相比最内层循环向量化，有一倍以上的加速。 作者注意到，一般的最内层循环向量化很难应对交叉循环迭代依赖，而且迭代次数较少时，也很难有性能提升。 相比于在最内层循环做自动向量化，外层循环能够发现更多的数据并行和局部性，出现非连续访存的可能性更小。 作者首先分析循环，包括对循环内控制流的分析和循环迭代控制的分析，找出循环中会被一直执行的语句和循环的迭代次数。 之后，先通过循环体变换，得到内层循环中的一段线性语句，再递归的对内层循环作处理，将内层循环直线代码分配到基本块。 作者在GCC 4.3中实现了这套机制，对于选定的benchmark，在Cell BE SPU和PowerPC 970上分别获得3.13和2.77的加速比。 相比之下，最内层循环向量化的加速比只有1.53和1.39。

Aart J. C. Bik等人实现了Intel编译器中自动向量化。 ICC通过对最内层循环展开，构建数据依赖图的方式，寻找可以向量化的操作。 为了降低非对齐访存带来的开销，ICC生成了多种版本的循环主体代码，通过运行时检测的方式，寻找最适合执行的代码，并执行之。 对于Linpack，ICC的自动向量化在有MMX和SSE2扩展的2GHz的Pentium 4芯片上，双精度例子加速比平均为2。 对于SPEC2000例子，galgel性能提升20%， swim 6%， gzpi 6%。

基于基本块的自动向量化

Samuel L.首先提出了从单个基本块中综合生成SIMD指令操作的SLP(Superword Level Parallelism)向量化机制。 该架构先在基本块中寻找无依赖的同构操作，将这些同构操作合并，并转换为相应的SIMD操作来实现向量化。 首先使用循环展开，将循环迭代间的并行语句集中到一个基本块中，再在该基本块中利用启发式算法，作对齐分析和数据流优化，减少数据依赖。 之后确定合并成SIMD指令的语句组，并最终生成SIMD操作。 作者将以上机制应用在SPEC95浮点测试集中的科学计算程序和几个多媒体计算程序的kernel中。 因为有了SIMD并行，最终执行的指令数下降了46%。这些benchmark的加速比从1.24到6.70不等。

接着，Samuel L.等人又将软流水和向量化结合，在软流水中寻找向量并行机会，同时进行ILP(Instruction Level Parallelism)和DLP(Data Level Parallelism)。 作者注意到虽然SLP能够发掘并行性，让向量部件更有效的运转，但同时标量运算部件和向量运算部件之间也可以并行。 为了更好的利用这种并行，作者尝试在软流水中寻找向量化机会。 在DSP和SPEC FP benchmark上，分别拿到了1.30和1.18的加速比。

Jaewook Shin等人将SLP扩充到有控制流存在的情况下。 作者注意到控制流因为有分支，使得有些SLP向量化无法进行。 通过将控制流依赖转换为数据流依赖，之后在控制流依赖涉及到的指令中，添加一个谓词属性的转换方式，消除分支，使循环体都在一个基本块中。 之后，重新将SLP算法作用到这个基本块中。 在合并SIMD指令语句组时，相对Samuel L.的SLP，唯一的不同是只有具有相同谓词属性的指令才能合并成带有向量谓词属性的SIMD指令。 然后，对于可以向量化的语句，将其合并。否则通过将向量谓词转换为SELECT动作，保持原程序中分支的语义。 最后将这些向量化的语句生成对应的SIMD代码，而SELECT动作的语句，则重新转换为if-then分支。 作者选取了8个多媒体程序的Kernel来评估自己的工作，获得了1.97到15.07的加速比。

关注可移植性的编译器向量支持

因为各个处理器厂商支持的SIMD扩展支持的数据元素类型、向量数据总长度都有很大的不同。 SIMD指令的数量和功能也有很大的差别，而且处理器厂商也会持续改进自己的SIMD扩展。 在没有好的通用自动向量化算法的前提下，只能由编译器开发者针对每个SIMD扩展，作精确的调优。 如果支持多个处理器，就需要很多繁琐的调优工作。 所以，提升编译器的自动向量化算法的可移植性，也是研究的热点问题。

Dorit N一直为实现一个高性能高可移植的GCC自动向量化而努力。 她在04年的文章中介绍了在 GCC 上实现的基于循环的自动向量化，该机制可以用在向量长度不同的一些后端上。 作者首先介绍了在GCC的嵌套循环优化阶段如何在GCC的SSA表示上使用数据依赖图中的强联通分量作数据依赖分析。 它利用GCC基于SSA的GIMPLE中间表示，首先分析循环格式，接着做数据依赖分析和操作分析。 通过这一系列分析，进行向量化。通过向量化因子VF，控制循环展开的次数，从而实现对不同SIMD数据长度后端的支持。 作者通过循环标记和循环peeling来作对齐分析，寻找最大限度的访存对齐。 两年以后，Dorit N.介绍了他们在GCC中实现自动向量化支持的工作的进展。 作者在GCC 4中实现了新的自动向量化机制，在这套机制中充分考虑了向量化的可移植性问题。 作者的工作基于GCC的GIMPLE中间表示，因为SIMD扩展比较底层，所以作者着重介绍了如何在可移植和暴露底层细节之间的权衡。 在访存对齐方面，作者首先采用静态对齐分析找出对齐访存；再将这些非对齐访存尽可能转换为对齐访存， 可以同时包含多个循环变换版本，并在动态对齐检测的方式确定执行哪个版本； 若经过这一变换，还有些不能确定是否对齐的，若目标平台提供了非对齐访存指令，则向量化之，否则放弃向量化。 作者选了一些浮点、short和char型整点的例子，并在四个平台：IBM PPC97、Pentium4 、Itanium2、Alpha。 结果显示，在四个平台上都有不少加速，尤其在IBM PPC97和Intel Pentium4上有不错的加速比。

CGO 2011中，Dorit Nuzman等人介绍了通过引入运行时支持， 使得静态编译得到的向量化中间表示能在多个不同的SIMD平台上运行，实现了一次编译，跨平台运行。 Dorit Nuzman针对不同处理器的SIMD扩展对向量长度、内存对齐和访问方式三方面的差异展开可移植研究。 作者首先扩充CIL中间表示，针对如上三个差异设计相应的中间表示， 然后利用GCC已有的自动向量化机制，修改GCC使之能生成包含向量扩展的CIL中间表示， 并分别在Intel的SSE、AVX，IBM的AltiVec和ARM的NEON四种SIMD扩展上，通过扩充CIL的运行时环境MONO分别验证了其解决上面三个差异的方法。 作者通过引入向量长度因子和向量化因子来动态表示向量长度，以及由向量长度不同引起的循环展开次数的不同； 通过同时生成对齐和非对齐访存语句，并引入一个判断语句在运行时确定采取哪种方式访存，解决访存对齐问题。 实验结果显示，虽然该策略平均比GCC静态向量化结果略差，但能同时针对多种SIMD扩展， 可以应对不同扩展间对齐访存不同、向量宽度不同、向量指令集不同的问题。

Manuel H.等人针对嵌入式平台，研究编译器 SIMD 支持的可移植性，给出了一个能快速高效移植的编译器向量化架构。 这种嵌入式平台多为面向特定应用的指令集(ASIP)，这类平台一般指令集差别很大，因此对编译器的可移植性要求高。 作者提出了一种能充分利用SIMD指令和编译器可移植性的机制。 该机制由一个循环向量化器和一个展开——打包工具组成，这两者都使用相同的SIMD指令集描述。 因此，移植编译器时只需要修改这些指令集表示即可。 向量相关的优化都采用机器无关的形式描述。 作者在ACE公司的编译器生成工具中实现了这一机制，并在ARM11和NXP TriMedia两款嵌入式处理器上做了验证。 结果显示，这种机制对于DSP类的Benchmark，有7%-66%的加速比。 即使做了4次循环展开， 代码大小与串行代码相比，ARM为原来的0.9，TriMedia为原来的1.1。

Randall J. Fisher等人研究了98年以前SIMD扩展的情况，总结概括了这些SIMD扩展中指令动作的特点， 并据此开发了一种类C语言SWARC，以方便编译器同时支持多个SIMD扩展。 并为该语言开发了一个实验性的编译器Scc，该编译器支持X86平台的MMX和3DNow！ SIMD扩展。 之后，他们又针对SCC编译器做了向量处理优化，但并未给出具体的数据。 该编译器针通过扩展数据类型，使之具有溢出和向量的属性。 针对SIMD指令的新功能，增加新的操作符，如增加最大操作符：?<、最小值操作符：?>。

自动向量化面临的问题

时至今日，虽然学术界针对自动向量化展开了很多研究，但仍存在很多的问题：

• 发现可向量化操作难： 因为指针引起的别名，使得编译器很难对有指针存在的程序做精确的数据依赖关系分析，因而很难并行化。 且SIMD指令无法描述有分支的串行程序的语义，因此编译器无法对循环体中有分支结构的程序向量化。
• 确定向量化方案难： 对于越来越强大的SIMD支持，编译器有很多种向量化方式，由于代价模型不成熟，编译器有时不能正确找到有性能提升的自动向量化方式。 数据置换指令执行时间长，非对齐访存延迟大，自动向量化对循环结构的改变影响其他编译优化的正常进行， 这些都可能影响自动向量化的最终效果。 目前尚无理想的代价模型，可以让编译器从众多向量化方式中，找到代价最小，性能最优的一个。
• 对齐访存要求严格： 非对齐的访存，要么出错，要么效率很低。 在编译时并不能得到所有对齐信息。 为了保证正确性，编译器就需要放弃许多潜在优化机会。
• 可移植性差： 由于知识产权保护和技术演进，各个 CPU SIMD 扩展指令支持的操作、SIMD数据长度和类型都不尽相同。 自动向量化算法要么针对各个不同的指令集做针对性配置和调试，但这样可移植性差； 要么努力提高可移植性，兼容尽可能多的后端CPU扩展，但这样某些后端特有的指令就很难有效利用。

参考

Eichenberger et al.(2004)aEICHENBERGER A E, WU P, O’BRIEN K. Vectorization for SIMD architectures with alignment constraints. Proceedings of the ACM SIGPLAN 2004 conference on Programming language design and implementation, 2004:82-93
Naishlos(2004)NAISHLOS D. Autovectorization in GCC. GCC Developers’ Summit, 2004:105-118Allen and Johnson(1988)ALLEN R, JOHNSON S. Compiling C for vectorization, parallelization, and inline expansion. Proceedings of the ACM SIGPLAN 1988 conference on Programming Language design and Implementation, 1988:241-24942VOJIN Z. Compilers for digital signal processors: The hard way from marketing to production tool. DSP and Multimedia Technology, 1995(4):27-45
Cooperation()Intel COOPERATION . Intel C/C++ Compiler User and Reference Guides. http://www.intel.com/software/products/compilers.III(1999)III J H W. Programming Methods for the Pentium  III Processor’s Streaming SIMD Extensions Using the VTune^TMPerformance Enhancement Environment. Intel Technol. J., 1999Shahbahrami et al.(2006)SHAHBAHRAMI A, JUURLINK B, VASSILIADIS S. Performance Impact of Misaligned Accesses in SIMD Extension.Proceedings of the 17th Annual Workshop on Circuits, Systems and Signal Processing (ProRISC 2006), 2006:334-342Slingerland and Smith(2001)SLINGERLAND N, SMITH A J. Performance Analysis of Instruction Set Architecture Extensions for Multimedia.In the 3rd Workshop on Media and Stream Processors, 2001:204 – 217.Ren et al.(2006)REN G, WU P, PADUA D. Optimizing data permutations for SIMD devices. Proceedings of the 2006 ACM SIGPLAN conference on Programming language design and implementation, 2006, 41:118-131.Allen and Kennedy(1987)ALLEN R, KENNEDY K. Automatic translation of FORTRAN programs to vector form. ACM Trans. Program. Lang. Syst., 1987, 9:491-542.Trifunovic et al.(2009)TRIFUNOVIC K, NUZMAN D, COHEN A, et al. Polyhedral-Model Guided Loop-Nest Auto-Vectorization. Proceedings of the 2009 18th International Conference on Parallel Architectures and Compilation Techniques, 2009:327-337.Eichenberger et al.(2004)bEICHENBERGER A E, WU P, O’BRIEN K. Vectorization for SIMD architectures with alignment constraints.Proceedings of the ACM SIGPLAN 2004 conference on Programming language design and implementation, 2004:82-93.Nuzman and Zaks(2008)NUZMAN D, ZAKS A. Outer-loop vectorization: revisited for short SIMD architectures. Proceedings of the 17th international conference on Parallel architectures and compilation techniques, 2008:2-11Bik et al.(2002)BIK A J C, GIRKAR M, GREY P M, et al. Automatic intra-register vectorization for the Intel architecture. Int. J. Parallel Program., 2002, 30:65-98.Larsen and Amarasinghe(2000)LARSEN S, AMARASINGHE S. Exploiting superword level parallelism with multimedia instruction sets. Proceedings of the ACM SIGPLAN 2000 conference on Programming language design and implementation, 2000:145-156.Larsen et al.(2005)LARSEN S, RABBAH R, AMARASINGHE S. Exploiting Vector Parallelism in Software Pipelined Loops. Proceedings of the 38th annual IEEE/ACM International Symposium on Microarchitecture, 2005:119-129Shin et al.(2005)SHIN J, HALL M, JACQUELINE C. Superword-Level Parallelism in the Presence of Control Flow. Proceedings of the international symposium on Code generation and optimization, 2005:165-175Nuzman and Henderson(2006)NUZMAN D, HENDERSON R. Multi-platform Auto-vectorization. Proceedings of the International Symposium on Code Generation and Optimization, 2006:281-294Dyshel et al.(2011)DYSHEL S, NUZMAN D, ROHOU E, et al. Vapor SIMD – Auto-Vectorize Once, Run Everywhere. International Symposium on Code Generation and Optimization (CGO’11). Chamonix, France, 2011Hohenauer et al.(2009)HOHENAUER M, ENGEL F, LEUPERS R, et al. A SIMD optimization framework for retargetable compilers. ACM Trans. Archit. Code Optim., 2009, 6:2:1-2:27.Fisher and Dietz(1999)FISHER R J, DIETZ H G. Compiling for SIMD Within a Register. Proceedings of the 11th International Workshop on Languages and Compilers for Parallel Computing. 1999:290-304Fisher and Dietz(2000)FISHER R J, DIETZ H G. The Scc Compiler: SWARing at MMX 3DNow!. Proceedings of the 12th International Workshop on Languages and Compilers for Parallel Computing, 2000:399-414

您可能也喜欢：

自动向量化的研究现状

Open64中的自动向量化支持

体系结构这五年--《计算机体系结构-量化研究方法》第5版的新变化

SIMD硬件的发展

通用微处理中的SIMD指令扩展

无觅

相关文章：

• 自动向量化的研究现状
• SIMD硬件的发展
• 关于
• 计算机系统结构方向的顶尖会议
• 美国国家仪器（NI）招聘信息
• TIPS for writing easily auto-vectorized code

目前，包含SIMD支持的体系结构主要分为如下几类：

• 单核通用微处理器中的SIMD扩展： 这是最普通的一类SIMD扩展。
• 对称多核中的SIMD扩展： 结构上一般都采用多个单核通用微处理器组合形成多核，SIMD多数存在于单个核内。 这种方式，从05年发展至今，已经普遍存在于通用计算领域，如高端嵌入式、PC、低端服务器。
• 异构多核中的SIMD扩展： 一般异构多核由一个功能强大的核加若干结构简单，但计算能力强的核组成，以IBM 05年推出的Cell处理器最为典型。
• 数字信号处理芯片(DSP)中的SIMD： 相比通用芯片的SIMD扩展，DSP芯片的SIMD指令集一般是为了处理特定的数据结构，如声音、视频。 DSP中SIMD操作对象一般都通过DMA从宿主机上先拷贝到暂存器(Scratchpad RAM)中，再在这块存储上作操作。 这些指令一般不能直接访问宿主的主存。
• GPU中的SIMD： 严格意义上，GPU就是一种的DSP。 GPU以NVIDIA的CUDA最为典型，Intel也在08年展示了自己的GPU设计。 这类SIMD的突出特点是支持向量宽，SIMD指令支持丰富，计算功能强大，有SIMT支持。 但由于GPU一般都有自己的独立存储空间，且底层差异很大，所以可编程性差。
• 向量机中的SIMD： 这类SIMD在上世纪80年代红极一时，支持的向量操作最为灵活，至今仍在某些领域占据一席之地。

对称多核与SIMD

对称多核处理器厂商的典型代表是Intel、AMD和IBM Power。Intel自2004年发布第一款双核处理器Celeron D开始， 一直在其处理器中持续改进SIMD扩展。

2008年推出的Core i7处理器增加了对XML处理的SIMD加速支持，将非对齐访存的延迟减小到最快仅1拍， 当数据不在同一个cache line时才需要4.5拍。

Intel 2010年底推出的Sandy Bridge架构，其中的AVX扩展，除了兼容之前的MMX，SSE，SSE2外，将浮点SIMD运算支持的数据宽度提升到了256位。 并对访存通道做了调整，扩展原X86的存地址访存通道，使之也可以从内存取数据。 这样CPU的访存能力就大大增强。

Figure 2.1: AMD Bulldozer结构

AMD在2011的ISSCC上也推出了其最新双核架构Bulldozer。 图 2.1 为Bulldozer的结构图，Bulldozer的两个核不仅共享取指、解码和L2 Cache，还共享SIMD运算部件FMAC。 当执行128位的SSE2 SIMD扩展时，Bulldozer的每个核可以最多使用两套SIMD运算部件；当执行256位 AVX指令时，两个128位的FMAC部件共同执行此指令。

异构多核与SIMD

异构多核与SIMD的典型芯片是Sony、IBM和Toshiba共同开发的Cell处理器，其内部结构如图 2.2 所示：

Figure 2.2:Cell处理器结构

Figure 2.3:Cell处理器编译流程图

Cell处理器中包含了一个功能强大的Power处理器核PPE和八个流处理器核SPE。 SPE和PPE都有128位的SIMD数据支持，支持浮点和整点的SIMD操作。 每个SPE都有自己的局部存储，而且能够确保在一定延时内完成数据分发，这使得Cell可以用简单的逻辑完成流水线控制。 Cell需要程序员自己通过控制DMA(Direct Memory Access)部件管理数据存取。

Alexandre E. E.等人开发了针对CELL的优化编译器。 作者的工作除了构建一个面向CELL的高性能编译器外，还着力于提升结构简单的流处理核——SPE的性能，为SIMD提供自动向量化支持。但这种异构结构也为二进制兼容带来了问题，如图2.3为Cell上可执行文件编译链接流程图。

GPGPU与SIMD

GPGPU，即将GPU用于通用计算领域，许多计算密集型应用能通过GPU的流处理支持获得较高的加速比，因为GPU有强大的数据并行能力。 每个GPU都有多个multiprocessor组成，每个multiprocessor又包含若干个processor。 每个multiprocess中的所有processor共享一个取指部件，它们同时执行一条指令，操作的数据对象可能不同。 因为GPGPU中的SIMD是每条指令同时操作多个线程中的数据，因此这种SIMD也被成为SIMT。

Rajesh Bordawekar等人使用通用CPU上SIMD + 多核优化一个实际的图像处理应用程序，证实优化后的性能可以超过GPU。 作者通过分析，得出GPU在擅长的浮点运算上不敌CPU的原因有四点： 1,共享内存小; 2,内存访问模式为非对齐; 3,原子操作代价高; 4,单线程性能弱。

Intel 08年公布了其基于X86架构的GPU设计——Larrabee[。 Larrabee采用对称众核设计，每个核都是顺序发射、X86架构，有512位宽SIMD支持，且支持函数调用栈和缺页中断处理。 但09年底Intel宣布不再将Larrabee作为GPU产品开发，而仅仅作为实验性的软件平台。 因为其能效不高，很多依赖GPU硬件实现的操作，改用软件实现，效率和功耗都不理想。

向量机与SIMD

目前SIMD的发展朝着数据越来越宽，支持操作越来越复杂，访存支持越来越丰富的方向发展。 按照这个势头，SIMD扩展是否会最终变成曾经红极一时的向量机呢？ 我们有必要将SIMD扩展和向量机做个对比，借鉴向量机的成功经验，同时规避向量机的劣势。

向量机是80年代和90年代初大多数超级计算机的基础，面向向量机的自动向量化研究工作在这期间也一度非常热。 向量机中又以向量——寄存器类处理器类型最为主流。 这类处理器中SIMD指令的操作数，除访存操作外，都保存在寄存器中。 通用微处理器上的SIMD扩展和这种向量处理器有许多相似之处。 如向量机中的寄存器类似微处理器上的SIMD寄存器；向量机上向量指令的功能也和SIMD指令功能相似。 但也有很多关键的不同点：

• 向量机支持的向量数据类型很长，而且支持变长向量数据；而SIMD扩展一般支持较短的定长向量数据类型。
• 向量机访存支持强大，访存带宽大；而SIMD扩展访存由于成本原因，访存支持较弱，访存带宽小。 向量机的访存部件都支持跨距访存，即可以从不连续的地址取数到一个向量里，而SIMD扩展目前仅支持连续的存取一个向量中的元素。 带宽方面，06年最快的通用超标量微处理器的访存带宽只有5GB/秒，而最快的向量处理机达到50GB/秒。
• 向量机的向量操作通用性强。 所有的操作可以针对所有的向量数据类型实施。 而SIMD扩展的向量操作由于向量运算部件物理实现的原因，限制较多，操作不通用。某些操作仅仅支持某些向量数据类型。

虽然从这些不同点来看，向量机比SIMD扩展有很大优势， 但之所以有SIMD扩展的通用微处理器能得到通用计算市场领域的认可，是因为向量机的内存、缓存和处理器设计及实现成本过高。 06年，只要1000多美元就能买到一台CPU频率比造价上千万的向量机还要高的笔记本电脑。 不过，因为向量机自身有通用串行微处理器很难企及的优势，在对存储带宽要求较高的科学和工程应用中仍然很流行。 这使得向量机在高性能计算领域，牢牢的占据着一席之地，在2010年11月全球高性能计算机的TOP10中，仍有4个是向量机。

Davida A. PaDua和Michael J. Wolfe总结了针对向量和多核计算机的编译器应该具有的特性。 他指出数据依赖分析，尤其是针对循环的数据依赖分析是自动向量化编译器必须具备的功能，而并行化则是多核计算机性能提升的关键。

传统向量机的向量化技术多数针对基于数组的FORTRAN语言，而现阶段很多数据并行度高的多媒体应用都是用C语言编写。 C语言中的指针和其他语言特性使得针对向量机的向量化技术很难直接应用在通用处理器的SIMD扩展中。

参考文献:

您可能也喜欢：
通用微处理中的SIMD指令扩展	Intel 的AVX2指令集解读	自动向量化	Expected unqualified-id before 查错	Some notes about IBM XL C Compiler
无觅

相关文章：

• 自动向量化
• 自动向量化的研究现状
• 通用微处理中的SIMD指令扩展
• Intel 的AVX2指令集解读
• 计算机系统结构方向的顶尖会议
• 前瞻-LLVM大事记(2004-2010)

SIMD技术是许多计算密集应用提升性能的关键。 上世纪80年代，向量处理器以其出色的并行处理能力，曾经在高性能计算领域广泛应用。 这种并行处理能力就来自SIMD技术。

近几年，由GPGPU和通用CPU组成的异构模式也在高性能计算领域大显身手。 GPGPU的SIMT模式，因为一次将一条指令作用于一个线程块中多个线程中的数据，因此本质上也是SIMD。 因为SIMT的计算模式使得多个线程可以并行执行，因此并行密度高。

在通用计算领域，随着数字多媒体技术的发展。 使用通用计算机对诸如文本、图像、视频、二维和三维图形之类的多媒体对象做捕捉、编辑、存储和转换之类的应用越来越多。 这类应用的突出特点是数据宽度小、并行度高、计算相对整齐。 本世纪初，许多通用微处理器针对这类应用的特点，开发了SIMD指令集扩展。

这种扩展中SIMD指令操作的数据集合都保存在一个寄存器中。 所以这种SIMD也被称作SWAR(SIMD Within A Register)。 其中的数据集合被称为SIMD数据或向量。 由于本文的工作基于通用CPU中的SIMD扩展，为了表述方便，如无特殊说明，文中的SIMD都指SWAR。

这种扩展仅使用芯片上少量的晶体管，就可以为标量CPU引入SIMD支持，提升芯片数据并行处理能力，所以得到了许多通用CPU厂商的亲睐。 表 2 为从惠普公司最早在通用CPU中引入SIMD指令至今，主流通用CPU中引入SIMD扩展的情况。 从表中可以看出，各个厂商推出的SIMD指令集从最初的仅仅支持整点操作发展到现在支持有符号/无符号整点、单精度和双精度浮点，支持的数据类型越来越丰富； 从开始时复用浮点寄存器到现在有专门的向量寄存器，SIMD指令越来越多，向量运算的支持越来越强大； 从开始时，仅支持64位向量数据，到现在可以支持256位的宽向量数据类型，支持的向量越来越宽。

您可能也喜欢：
SIMD硬件的发展	Intel 的AVX2指令集解读	Some notes about IBM XL C Compiler	Expected unqualified-id before 查错	自动向量化
无觅

相关文章：

• TIPS for writing easily auto-vectorized code
• Intel 的AVX2指令集解读
• 前瞻-主流处理器中的数据并行支持(SIMD)
• 好大一筐梅普斯(MIPS)
• 自动向量化
• 前瞻-拿起SIMD的武器II

• 级别0时编译器不进行向量化；
• 级别1时，编译器仅在没有因使用非最佳对齐策略导致性能下降，而且不会出现浮点运算不精确的情况下做向量化；
• 级别2时，编译器会做最激进的向量化。默认的选项是-LNO:simd=1

Open64与自动向量化有关的代码都在 osprey/be/lno/simd.cxx 文件中。Open64的自动向量化目前仅支持X86_64后端。函数void Simd_Phase(WN* func_nd)是自动向量化阶段的入口函数。接着调用函数static void Simd_Walk(WN* wn) 递归地遍历每个PU中的Whirl Node，检查是否满足自动向量化的条件。Open64的自动向量化机制较简单，目前只对没有别名引用的、循环中没有函数调用和Goto语句的最内层循环做向量化。

Open64自动向量化的过程在函数static INT Simd(WN* innerloop)中实现。若成功向量化，则返回1。对于其他后端以及不能成功向量化的返回0。在这个函数中还会对满足前面条件的内层循环继续分析排除不能向量化的循环。首先调用函数static BOOL Simd_Pre_Analysis(WN *innerloop, char *verbose_msg)排除迭代次数太少、迭代变量在循环结束后仍活跃、循环边界过于复杂的循环。再使用函数static BOOL Simd_Analysis(WN *innerloop, char *verbose_msg)排除循环内操作不能向量化、变量形式过于复杂、存在变量依赖环等其他不满足向量化条件的循环。在上述分析的过程中，也在收集能满足向量化条件的语句和循环的信息。

自动向量化的过程分为两个模块：分析并维护数组的对齐 和向量化。分析和维护数组对齐即在编译时，检测数组的对齐信息并对不对齐的部分做出调整。向量化模块则是将循环中的常量和不变量转换为向量类型，再将循环展开，进而将展开后的语句拼接成向量化的Whirl node.

您可能也喜欢：

AMD编译器开发工程师介绍Open64编译器

自动向量化

Open64、LLVM、GCC源代码行数对比

Open64课程-循环嵌套优化(LNO)

最近Open64动作不小

无觅

相关文章：

• Expected unqualified-id before 查错
• Open64课程-循环嵌套优化(LNO)
• Open64课程-简介，概述和中间表示
• Open64课程-编译过程
• Open64课程–付诸实践(Practical Matters)
• 前瞻-全时优化和LLVM-1

如何实现？

编程环境

在现在CPU设计中都加入SIMD扩展并不是解决应用性能问题的好方法。如果没有很好的利用途径，再强大的SIMD扩展指令集都是徒劳。接下来，我们从编译器技术和编程方法论上探讨如何使用SIMD指令来实现应用加速。

编译器的局限

尽管现在SIMD扩展在大部分处理器中都已具备，但目前编译器仍难生成基于SIMD指令的高效代码序列，因为从以控制流为主体的C语言中自动抽象并行化很难。仅仅有几个商业编译器能自动产生SIMD并行，但往往需要很高的代价，结构也很不令人满意。这一块依然是研究开发的热点。SWAR(SIMD within a register)是曾经比较典型的比那一起。一开始作为一个兼容面向多种处理器，之后又转化为一个能识别简单高层并行语言SWARC(一个为使用SIMD指令而生的数据并行C语言).但是，因为SIMD指令的限制，数据并行语言的成功取决于应用领域中高效的并行方法和能很好描述这种应用的语言。SWARC在语言设计阶段，缺乏对特定并行方法的假设使得它使用范围很有限。
也有人针对图像处理任务，提出了一种对C语言的并行扩展和对应的SIMD编译器，并用它实现SIMD加速。作者使用这种语言实现了图像滤波器，并使用SIMD编译器在奔腾处理器上得到了图像滤波器的高效代码序列。通过与最新C编译器中编译得到的代码对比，SIMD编译器得到的代码有4x的加速.也有人专门就如何降低用户学习新编程语言的复杂性进行研究，并提出了一个编程语言原型和相应的编译器。自动向量化的工作也有人在继续奋斗。有人提供了在编译C代码时自动使用SIMD指令代替的技术，使用它让跨平台的源代码使用SIMD指令。这种技术基于经典的代码树结构，并在其上收集数据流图信息以便生成SIMD指令，对目前的主流处理器，这样实现还行，但是很多新的SIMD结构都在趋于提供较高层的并行了。
在某些应用中，通过使用编译器内部的函数来插入一组SIMD指令实现数据在寄存器中的重排，可以实现更高度的并行。这种编译器内部函数都对应一个或多个特定的SIMD指令，通过插入这些函数，程序员告诉编译器需要选择哪个SIMD指令，编译器则负责寄存器分配和指令调度。最近有人描述了SIMD指令如何从常规代码中产生，如何决定SIMD操作的书讯，并每个SIMD指令组。在该提议中，独立的存储访问都组织称SIMD操作，SIMD数据流图根据访存的数据依赖构建，接着SIMD操作的顺序复制到数据六图中。这种机制并不依赖特定的体系结构，在SSE实现该提议，对于某些应用核心，加速比达到35%。
另外也有人研究了使用SIMD并行操作和使用串行操作的能耗问题。通过比较多个benchmark，作者的结论是：使用SIMD指令能节省72%的能耗，提升76%的性能。

编程方法论

虽然没有编译器令人满意的支持，但SIMD依然是有效的提升性能的方法，接下来介绍三种使用SIMD扩展的途径。

1. 汇编语言：这是最高效的使用方式，因为这种编程方式能直接从硬件平台获得性能。但很容易出错，而且可移植性不强。
2. 共享库：这些库通常处理器生产商提供的，但这些库只能覆盖特等的函数，而且只能用在特定的处理器上。比如，Intel的汇编库就提供了很多常用信号处理，向量计算和图像处理的汇编函数库供C函数调用,但通常，这种方式会造成库中的可用函数和目标应用需要的不匹配。
3. 向量化编译器：最理想的情况下，高级语言编译器能自动识别代码中的并行部分，并生成相应的SIMD指令串。但是虽然现在有很多自动SIMD向量化的提议，但成功的很少。值得一提的是Intel C++ Compiler中的intrinsic支持，把括MMX，SSE，SSE2的SIMD指令支持，C++ SIMD向量类，还有一个自动的向量化工具能自动从循环中得到SIMD并行。它为Microsoft Windows和Linux操作系统环境带来明显性能提升。ICC的二进制文件，在Windows环境下能与Visual C++二进制兼容，在Linux能与GCC相应版本的二进制兼容。现在通过intrinsic库和C++来编程要比汇编语言容易的多，因为不再需要维护寄存器，可以方便的开发较大的软件，但因为编译器要完成寄存器分配和指令调度，所以相对于汇编，性能可能会有下降，但并不绝对。 GNU Gcc 4.2也支持了包括AtliVec,SSE2和3DNow！在内的一些多媒体扩展。

数据对齐

对齐就是把数据和代码放在主存中能让硬件更高效访问的地址的技术，也就是存储地址的一种属性。一个地址是X对齐的，如果它的地址能表示为Xn+0的形式。其中X是2的某次幂，n为任意整数。一个存储向量数据的内存块，若其边界是非对齐的，那访问它的开销将会非常大，因为需要使用数据重排机制。这种机制通常需要产生很多额外的存储访问。为了避免这种过高代价，已经有了一些技术，如循环分割，动态/静态对齐检测。很多CPU，如基于Alpha, IA-64, IA-32,MIPS和SuperH的结构，都禁止访问非对齐数据，如果程序请求访问了非对齐的数据，则抛出异常。

数据对齐是开发自动使用SIMD扩展必须要解决的基础问题之一。掌控对齐会大大增加自动向量化的难度，并限制其应用范围。为了能对向量数据高效存储，存储访问必须正确对齐。

选择合适的SIMD扩展

SIMD扩展在现在的PC中几乎都有，为啥不用呢？但，再者之前，得先回答几个问题：

1. 现在的代码能从MMX，SSE,SSE2或SSE3中获益吗？
2. 代码是整点运算还是浮点？
3. 需要什么样的编程技术？
4. 如何组织数据类型，如何对齐？

另外，为了能从SIMD扩展中获得最大收益，下面几点一定要好好评估：

1. 计算敏感的程序段
2. 足够给程序性能产生影响的程序段
3. 几乎没有数据依赖控制流图的程序段
4. 需要浮点运算的程序段
5. 使用少量指令就能编写的计算代码段
6. 需要额外调整才能高效利用cache结构的代码段

一款商业软件Intel VTune能较好到检测出可以并行的程序段。协助程序员优化性能。

总的来说，一个能做SIMD优化的程序段，应该是循环体较小，循环操作一个数组，该数组由8、16或者32位对齐整数，单精度32位浮点，或双精度64位浮点组成。再加上使用尽可能少的数据类型，更长的向量数据，并且小心的控制内存访问。能做到这些，SIMD扩展就能为你的程序带来不小的性能提升了：）

个人总计：

至此，对目前最低级的并行–单指令多数据并行。算是有了点认识。SIMD几乎所有的主流CPU上都有，从Alpha的MVI，IBM PowerPC上的AltiVec和SPE，HP PA-RISC 多媒体加速扩展(MAX), Intel的MMX，iwMMX，SSE，SSE2，SSE3，SSSE3；AMD的3DNow!, ARC的ARC视频处理子系统，SPARC的VIS， Sun的MAJC， ARM的NEON， MIPS的MDMX和MIPS-3D， Cell的SPU， Philips的Xetal 到GPU上SIMD的普遍使用，从64位到128位，256位的数据并行。SIMD的硬件支持越来约强大。

另一方面，高品质的多媒体处理需求，也使得我们的计算机应用中数据处理越来越庞大。但唯独编译器很难为SIMD加速做贡献。SIMD的并行需要很弱的数据依赖，数据流的统一。而这种统一很难靠编译器来提取。高效的方式还得靠人工来做。人工来做，就意味着人要了解他要优化的这个算法，哪里数据计算比较多，哪里跳转，控制语句比较多。能不能使用SIMD优化，如何使用SIMD优化。

SIMD的硬件支持因为各个CPU厂商的设计目标不同，而且还有知识产权的问题。这样SIMD标准很难统一起来。针对每一个特定的CPU型号，都要做特定的SIMD优化，这也给软件的可移植性带来了挑战。

编译器能提取数据依赖吗？编译器能为程序员做点什么？编译器能在多大程度上协助程序员的工作？主流编译器已经有了对MMX，SSE，SSE2的intrinsic支持，编程在稍微损失性能的条件下编程更加容易了。Intel的VTune能帮助我们更好的发现并行机会。但很明显，这些还不够。幸好，GCC也引入了Graphite，或许在不久的将来，会有一些机会吧。现在影响SIMD，最多的不是找到一系列指令串来操作数据，而是如何高效的把数据组织成一个向量数据，在计算完成以后，高效的把这些数据都拿出来。

未来，我们还有很多值得期待，还有许多可以努力！

您可能也喜欢：

SIMD硬件的发展

通用微处理中的SIMD指令扩展

Some notes about IBM XL C Compiler

前瞻-拿起SIMD的武器I

Expected unqualified-id before 查错

无觅

相关文章：

• 前瞻-主流处理器中的数据并行支持(SIMD)
• 小例子–回眸一笑百媚生
• 前瞻-拿起SIMD的武器I
• GCC初窥
• Open64课程-简介，概述和中间表示
• 探秘CPU性能测试：Spec CPU2000之整点篇