• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Peeling The Onion For Ipdc Forum09 Mix Ver1
 

Peeling The Onion For Ipdc Forum09 Mix Ver1

on

  • 1,886 views

 

Statistics

Views

Total Views
1,886
Views on SlideShare
1,851
Embed Views
35

Actions

Likes
0
Downloads
22
Comments
0

2 Embeds 35

http://www.daniel-journey.com 32
http://www.slideshare.net 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Peeling The Onion For Ipdc Forum09 Mix Ver1 Peeling The Onion For Ipdc Forum09 Mix Ver1 Presentation Transcript

    • 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
    • Worldwide SW Support Organization System performance defects Typical Application performance defects Summary Micro- P.S: Micro-arch optimization 2
    • 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
    • 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
    • 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
    • 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
    • 内容 全球的软件支持组织 系统级的性能缺陷 典型的应用级缺陷 总结 附: 基于微架构的优化方法 7
    • 解决性能缺陷: 解决性能缺陷 概念和方法及策略 次序 优化级别 目标 主要关注的问题 获益 1 高: 通过改善应用和整个软硬件系 网络 高 系统级 统的相互关系来提升性能 磁盘 内存访问 2 中: 通过改善应用本身的算法等 进程/线程的同步 中 应用级 堆竞争 线程的实现 API的选择 库函数的选择 数据结构 3 低: 通过在特定的微架构级优化来 微架构调优的复杂性 低 微架构级 改善应用性能 数据/操作的局部性( 缓存的效率) 数据对齐 向量化 / SSE 8
    • 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
    • 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
    • 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
    • Contents 全球的软件支持组织 系统级的性能缺陷 典型的应用级缺陷 总结 附: 基于微架构的优化方法 12
    • 系统级的性能缺陷 内存配置 – 容量和速度的平衡 (max BW, balanced or max capacity?) 磁盘的配置 – SSD vs. HDD – RAID0 vs. RAID1 vs. RAID5, stripe size BIOS 设置 – SMT / EIST / Turbo / NUMA / Prefetcher 更新OS版本并且调整软件架构来配合新的硬件 平台,以此获得更好的性能 13
    • SSD vs HD 一般情况下,索引文件都比较大 在更新索引文件的过程中,磁盘压力较大,SSD能获得较好 性能 更新索引过程中磁盘压力较大 采用SSD使性能得到提高 14
    • 应用级的性能缺陷 多核环境下,多线程程序的设计需要非常细致的设 计 – 锁的粒度 – 并发 – 软件流水线的设计 – 选择合适的线程库 (TBB) 15
    • 锁的粒度 在多线程应用中,需要对共享数据加锁保护 对频繁访问的大块数据区域加锁可能造成线程阻塞 下面这个例子显示了对应用程序内部缓存加锁造成的线程冲突 将缓存拆分成多个部分,分别加以保护大大缓解了冲突,应用程 序性能提高了21% Computation threads Computation threads Cache memory Cache memory Split one lock in to different sets of locks 16
    • 软件流水线设计 合理分解和分配任务 – 在下面这个实际案例中,系统idle 50%, user% 仅 40%, 磁盘利用率未达到最大 – 两个IO线程无法充分利用磁盘系统的能力,也无法满足8个计 算线程的需求 – 适度增加IO线程数目,系统性能提高了27% Search Thread Thread Profiler中可以看 Search Thread 到,两个IO线程无法满 足8个计算线程的需求 IO threads 增加IO线程可以增加磁 盘的利用率. IO Thread Wrapper 17
    • 典型的应用性能缺陷 滥用STL – 通常,STL 容器和C的数组有同样的性能 – 但是,滥用STL容器可能会造成非常密集 的内存管理操作 – 在实际应用中我们观测到最大50%的性 能下降 – 多线程环境下情况会更糟糕 – Glibc的malloc/free在多核环境下扩展性 很差 – 如果在多线程环境下需要频繁分配和释放 内存,可以考虑SmartHeap,Hoard或者 Intel TBB 18
    • 典型的应用性能缺陷 内存操作 – Memcpy / Memset – 实际例子中,消耗了超过50% CPU – memset/memcpy是耗时的, 特别是在Xeon E5400平台 上,每秒memcpy/memset 2GB 将会对整个系统的性能 造成极大的影响. – Bitmap – 问题:随机写位映射序列的某些位 – 如果造成了缓存缺失,每次访问都会造成上百个CPU cycle 19
    • 算法的选择 JPEG缩略图生成 – 通过在频率域减采样可以将原图非常快的缩小到1/(2^n) 大小,然后再缩小到合适的大小,与直接缩小相比,性能 提高了2.5倍 20
    • 算法的选择 加密算法AES vs TEA – AES比TEA要快3倍以上,并且提供了强的多的加密效果 ,在一个需要对流量进行加密的应用程序中,相对于使用 TEA,AES使整体应用程序性能提升了43% - 96% 21
    • 算法的选择 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
    • 用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
    • 典型应用的性能缺陷 采用正确的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
    • 典型的应用性能缺陷 采用高性能库函数 – Intel IPP库可以提供更高的性能 – JPEG resize应用中,IPP是libjpeg性能的2倍 – 对于AES, IPP性能稍好,但是Westmere上的新的AES指令可以 提供10倍于普通AES的性能, IPP将会在第一时间提供支持 25
    • 总结 Intel对云计算的研究可以更好的支持IPDC应用的 优化 理解Xeon5500可以为IPDC的应用提供些什么 我们必须关注IPDC应用的典型的性能缺陷 系统的评估和解决应用的性能缺陷是一种有效的做 法 附:为了最大程度的释放CPU的性能,基于微架构 的优化手段有时是有必要的 26
    • Contents 全球的软件支持组织 系统级的性能缺陷 典型的应用级缺陷 总结 附: 基于微架构的优化方法 27
    • 28
    • 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
    • 用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 黄色数据存放的是异常数据的偏移距离
    • 用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
    • 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
    • Backups 33