Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (10)
Similar a Peeling The Onion For Ipdc Forum09 Mix Ver1
Similar a Peeling The Onion For Ipdc Forum09 Mix Ver1 (20)
Peeling The Onion For Ipdc Forum09 Mix Ver1
- 1. The 3rd Intel Internet DataCenter Forum – YiBin 2009. August Peeling the Onion: Optimize IPDC Performance defects 抽丝剥茧: 优化IPDC应用性能缺陷 Dr. Paresh Pattani paresh.g.pattani@intel.com Director, HPC and Workstations Applications 何万青 博士 wanqing.he@intel.com HPC/IPDC Engineering Mgr. / CRT China Special thanks to: 许进, 金君 Jin.j.xu@intel.com & jun.i.jin@intel.com “Life is like an onion: you peel it off one layer at a time, and sometimes you weep” 1 - Carl Sandburg
- 2. Worldwide SW Support Organization System performance defects Typical Application performance defects Summary Micro- P.S: Micro-arch optimization 2
- 3. ASE Global Cloud/IPDC Enabling Software Optimization – Single application or complex multi-tier systems – Customer Software & Open Source Consultation – Software Architecture – Hardware and Software Configuration Benchmarking 3
- 4. Cloud / IPDC Customers Internet Portals – Social Networking, Media, etc. Service Providers – Search, Mapping, Video, Auction, Web Applications, etc. Software Component Providers – Open Source and Proprietary (Ex. Hadoop) Cloud Providers – General Purpose and HPC 4
- 5. Dedicated Infrastructure – Visitors have logins, storage areas – Multi TB storage. – GigE network infrastructure – Power measurement tools – Secure (private network, locked lab) Variety of machines available – Some older machines, some “bleeding edge” – Intel and competitor systems – Windows and Linux Hosts both on-site and remote visitors – For optimization efforts and hardware evaluation – Remote access by prior arrangement only 5
- 6. Resent Success with Visitors to Lab: – Two Search Engine Customers: 2 week (plus prep) visit . Both: performance improvements >2× – Customers’ post-visit e-mail (etc.) very positive We would like more visitors – Good results when they come… Virtual visitors (remote access): – Short term, customer evaluations – Hadoop clustering experiments – other Intel sites, etc. Loaned/Resident software: – Hadoop – LAMP stack elements – Search and Mapping software 6
- 8. 解决性能缺陷: 解决性能缺陷 概念和方法及策略 次序 优化级别 目标 主要关注的问题 获益 1 高: 通过改善应用和整个软硬件系 网络 高 系统级 统的相互关系来提升性能 磁盘 内存访问 2 中: 通过改善应用本身的算法等 进程/线程的同步 中 应用级 堆竞争 线程的实现 API的选择 库函数的选择 数据结构 3 低: 通过在特定的微架构级优化来 微架构调优的复杂性 低 微架构级 改善应用性能 数据/操作的局部性（ 缓存的效率） 数据对齐 向量化 / SSE 8
- 9. Extracting Performance via Intel tools & Lib. 软件类型 Intel Tools & Libraries Thread Building Block Open Standards Primitives, Vectorization SSE, OpenMP Intel Compliers, Math Kernel, 线程级并行 Libraries, Intel Performance 数据并行 Ct, C/C++ Stds AVX … 任务并行 Message Passing Interface (MPI) 循环级并行 Open MP 串行 C/C++ Standards 应用灵活，基于开放的标准 支持不同的的并行化 9
- 10. 2008年的硬件概述 年的硬件概述 理论计算能力 Xeon Xeon – 3.2GHz * 8核心 * 4指令/周期 = 102.4G指令 5400 5400 /秒 内存（FSB） – 带宽：4通道FD-DIMM：21GB/s RAM – 延时：~120ns MCH 磁盘系统(15K SAS RAID5 x6) – 带宽：<1GB/s – IOPS：~1000s 网络 ICH HDD – 每秒处理的包数 (PPS) – 带宽 例子：Harpertown 10
- 11. 2009年的硬件概述 年的硬件概述 理论计算能力 RAM Xeon Xeon RAM – 3.2GHz * 8核心 * 4指令/周期 = 5500 5500 102.4G指令/秒 内存带宽 – 6通道DDR3：64GB/s (3倍提高) – 延时: NUMA： 67ns/117ns IOH 磁盘系统(SSD RAID5 x6) – IOPS：100,000s (上百倍提升) – 带宽：~1GB/s – 容量：800GB (1/10) ICH SSD 网络 – 多队列 / 10GbE 结论: 要充分发挥系统性能，开发人员必须了解硬件 系统限制，最大限度的平衡整个系统的不同组成部分 11
- 13. 系统级的性能缺陷 内存配置 – 容量和速度的平衡 (max BW, balanced or max capacity?) 磁盘的配置 – SSD vs. HDD – RAID0 vs. RAID1 vs. RAID5, stripe size BIOS 设置 – SMT / EIST / Turbo / NUMA / Prefetcher 更新OS版本并且调整软件架构来配合新的硬件 平台，以此获得更好的性能 13
- 14. SSD vs HD 一般情况下，索引文件都比较大 在更新索引文件的过程中，磁盘压力较大，SSD能获得较好 性能 更新索引过程中磁盘压力较大 采用SSD使性能得到提高 14
- 15. 应用级的性能缺陷 多核环境下，多线程程序的设计需要非常细致的设 计 – 锁的粒度 – 并发 – 软件流水线的设计 – 选择合适的线程库 (TBB) 15
- 16. 锁的粒度 在多线程应用中，需要对共享数据加锁保护 对频繁访问的大块数据区域加锁可能造成线程阻塞 下面这个例子显示了对应用程序内部缓存加锁造成的线程冲突 将缓存拆分成多个部分，分别加以保护大大缓解了冲突，应用程 序性能提高了21% Computation threads Computation threads Cache memory Cache memory Split one lock in to different sets of locks 16
- 17. 软件流水线设计 合理分解和分配任务 – 在下面这个实际案例中，系统idle 50%, user% 仅 40%， 磁盘利用率未达到最大 – 两个IO线程无法充分利用磁盘系统的能力，也无法满足8个计 算线程的需求 – 适度增加IO线程数目，系统性能提高了27% Search Thread Thread Profiler中可以看 Search Thread 到，两个IO线程无法满 足8个计算线程的需求 IO threads 增加IO线程可以增加磁 盘的利用率. IO Thread Wrapper 17
- 18. 典型的应用性能缺陷 滥用STL – 通常，STL 容器和C的数组有同样的性能 – 但是，滥用STL容器可能会造成非常密集 的内存管理操作 – 在实际应用中我们观测到最大50%的性 能下降 – 多线程环境下情况会更糟糕 – Glibc的malloc/free在多核环境下扩展性 很差 – 如果在多线程环境下需要频繁分配和释放 内存，可以考虑SmartHeap，Hoard或者 Intel TBB 18
- 19. 典型的应用性能缺陷 内存操作 – Memcpy / Memset – 实际例子中，消耗了超过50% CPU – memset/memcpy是耗时的, 特别是在Xeon E5400平台 上，每秒memcpy/memset 2GB 将会对整个系统的性能 造成极大的影响. – Bitmap – 问题：随机写位映射序列的某些位 – 如果造成了缓存缺失，每次访问都会造成上百个CPU cycle 19
- 20. 算法的选择 JPEG缩略图生成 – 通过在频率域减采样可以将原图非常快的缩小到1/(2^n) 大小，然后再缩小到合适的大小，与直接缩小相比，性能 提高了2.5倍 20
- 21. 算法的选择 加密算法AES vs TEA – AES比TEA要快3倍以上，并且提供了强的多的加密效果 ，在一个需要对流量进行加密的应用程序中，相对于使用 TEA，AES使整体应用程序性能提升了43% - 96% 21
- 22. 算法的选择 PForDelta vs. VBYTE – 搜索引擎应用中，为了减少磁盘访问，通常倒排表被压缩 后存放，SSE4.2 优化后的PForDelta算法可以达到3GB/s的 解压速度, 是VBYTE速度的10倍，而压缩率更好 V-Byte:F2/2,4,6 Comprare of unCompress Speed V-Byte:F2/3,6,9 V-ByteF3/4,6,8,10,12,14,16 1400 PForDelta Generic 1200 unCompress Speed(M/s) 1000 800 600 400 200 0 250 500 1000 2000 4000 8000 10000 20000 40000 80000 160000320000 lArrSize 22
- 23. 用SSE4.2优化P_FOR_DELTA解压缩 SSE4.2优化P_FOR_DELTA解压缩 优化P_FOR_DELTA • 搜索引擎中，解压缩通常是热点函数 • 基本方法 • P_FOR_DELTA可以达到上GB每秒解压缩速度，因此被广泛应用 • 通过SSE 4.2优化的P_FOR_DELTA可以达到更好的性能 V-Byte:F2/2,4,6 Different Kind of P_FOR_DELTA Decode algorithm Compare of Compress Rate V-Byte:F2/3,6,9 V-Byte:F3/4,6,8,10,12,14,16 7000 0.7 PForDelta Generic 6000 0.6 Speed (MB/s) 5000 0.5 Compress Rate 4000 0.4 3000 0.3 2000 0.2 1000 0.1 0 0 generic decode for D- generic decode for SSE decode for D-gap SSE decode for non gap non-D-gap D-gap decode 0 0 00 00 00 00 0 0 0 0 00 00 25 50 00 00 00 00 10 20 40 80 00 00 10 20 40 80 16 32 Method lArrSize ~2x speedup than generic GB/s Decompress speed by P_FOR_DELTA! 23
- 24. 典型应用的性能缺陷 采用正确的IO API – Synchronized IO vs. Posix AIO vs. Native AIO – SSD的IO延迟很小，并且能同时处理几十个IO请求，单线程上的同 步IO不能最大化发挥SSD的性能 – 相对于Native IO来说，Linux POSIX AIO 存在局限, 使用这些IO 函数之前，必须要正确理解 – read/readv/mmap/directio – Buffered IO会造成内核的内存拷贝，如果需要每秒钟需要处理上GB 的磁盘读操作，则需要考虑是否需要采用Direct-IO或者mmap等无 需拷贝的方式 – 当文件大于系统内存的情况下，通过mmap的方式随机的访问会造成 频繁缺页， HTN平台上内存带宽 受限,Read系统调用 会消耗较多的CPU时 间. NHM平台的内存带宽 得到改善（3x） 24
- 25. 典型的应用性能缺陷 采用高性能库函数 – Intel IPP库可以提供更高的性能 – JPEG resize应用中，IPP是libjpeg性能的2倍 – 对于AES, IPP性能稍好，但是Westmere上的新的AES指令可以 提供10倍于普通AES的性能, IPP将会在第一时间提供支持 25
- 28. 28
- 29. NHM上通过 上通过SSE 4.2来提升应用性能 上通过 来提升应用性能 - Intel® SSE4.2 Instruction Set Architecture (ISA) Leadership 如何使用SSE指令 如何使用 指令? 指令 – 编译器报告，自动向量化（采用编译器报告可以加快开发） – ASM汇编语言(开发难度较大) – 采用编译器内嵌intrinsic函数 (相对汇编来说，简单的多，多数内嵌函数和 一一对应于SIMD指令) – Vector类 (应用于C++面向对象的编程) – 大量的开发文档的支持 X3 X2 X1 X0 Y3 Y2 Y1 Y0 X3opY3 X2opY2 X1opY1 X0opY0 29
- 30. 用SSE4.2优化 优化P_FOR_DELTA解压缩 优化 解压缩 为了减少IO磁盘的压力，倒排表中docId表通常是被压缩存放的，并在归 并计算之前被解压缩 P_FOR_DELTA由UNIVERSITEIT VAN AMSTERDAM的Sandor Heman 提出 基本算法介绍 – 问题的提出: 压缩/解压缩数个整型数据(比如：128 integers) – 采用多少位来进行压缩？ – 对每个数都采用不同的位数(如：vbyte，但由于分支判断，解压缩速度会变慢) – 或者用统一的位数来压缩所有的数? (压缩率不好) – 更好的选择：采用统一的位数来压缩90%的数，把剩余的10%的数当作异 常数据 – 假设有128个整型，90% 小于32 ，选择压缩位数为5; – 分配128 x 5 位，同时存放10%的异常数据(每个异常4个字节)到压缩流的 末尾 1 2 5 11 21 8 7 19 1 49 132 Exceptions: 92 32bits 5bits 30 黄色数据存放的是异常数据的偏移距离
- 31. 用SSE4.2优化 优化P_FOR_DELTA解压缩 优化 解压缩 • 采用SSE intrinsic (17 bits 解压缩为例） SHUFFLE MASK: _mm_set_epi8 (0xFF, 8, 7, 6, 0xFF, 6, 5, 4, 0xFF, 4, 3, 2, 0xFF, 2, 1, 0); F E D C B A 9 8 7 6 5 4 3 2 1 0 1. Load a pre-fetched 128-bit segment of input data into SSE register. ... 110300 65536 1772 2702 2 42 _mm_shuffle_epi8 by SHUFFLE MASK 2. Copy compressed values to target DWORDs “32-bit segment”. 1772 2702 2 42 3. Align the values from unequally shifted DWORDs. By packed and, packed multiply and packed shift right 1772 2702 2 42 4. Store uncompressed values. 5. Use PTEST to check exceptions. • 使用 使用SSE 4.2的 super shuffle engine (_mm_shuffle_epi8) 的 • SSE 4.2中加强的 cache line split load 中加强的 • 红色部分是解压缩第一步完成之后的一些必须被清除的位 31
- 32. Buffer Alignment Affects (Xeon5500 vs. Xeon 5400) a,b 16 Bytes aligned, c has a 4B offset: 44.7sec (3.4x slowdown) a,b,c are 16 Bytes aligned: 13.2sec Ratio (Vector/scalar) cycles a,b,c are 16 Bytes aligned: 8.2sec a,b 16 Bytes aligned, c has a 4B offset: 8.5sec (1.03x slowdown) • HTN平台上，由于需要对齐，向量化的代码性能显著下降 (最大~3.9x slowdown) • NHM平台上，对齐对性能影响不大 (最大 ~1.03x slowdown) 32
- 33. Backups 33