Training course - IPCC 5 Optimize common tools

objdump

通过反汇编可执行文件,查看汇编内容,来判断代码是否被优化(自动向量化,内联)

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

CPU vs GPU

GPU vs CPU

CPU: latency-oriented design

低延时的设计思路

  1. large L1 caches to reduce the average latency of data
  2. 时钟周期的频率是非常高的,达到3-4GHz
  3. Instruction-level parallelism to compute partial results ahead of time to further reduce latency
    1. 当程序含有多个分支的时候,它通过提供分支预测的能力来降低延时。
    2. 数据转发。 当一些指令依赖前面的指令结果时,数据转发的逻辑控制单元决定这些指令在pipeline中的位置并且尽可能快的转发一个指令的结果给后续的指令。

相比之下计算能力只是CPU很小的一部分。擅长逻辑控制,串行的运算。

GPU: throughput-oriented design

大吞吐量设计思路

  1. GPU采用了数量众多的计算单元和超长的流水线
  2. 但只有非常简单的控制逻辑
  3. 几乎省去了Cache。缓存的目的不是保存后面需要访问的数据的,减少cache miss。这点和CPU不同,而是为thread提高服务的。
  4. GPU “over-subscribed” threads: GPU运行任务会启动远超物理核数的thread,原因是借助极小的上下文切换开销,GPU能通过快速切换Threads/warps来隐藏访存延迟。
    1. GPU线程的创建与调度使用硬件而不是操作系统,速度很快(PowerPC创建线程需要37万个周期)[^1]
    2. Cost to switch between warps allocated to a warp scheduler is 0 cycles and can happen every cycle.[^2]

对带宽大的密集计算并行性能出众,擅长的是大规模并发计算。

对比项 CPU GPU 说明
Cache, local memory 低延时
Threads(线程数)
Registers 多寄存器可以支持非常多的Thread,thread需要用到register,thread数目大,register也必须得跟着很大才行。
SIMD Unit 单指令多数据流,以同步方式,在同一时间内执行同一条指令

DRAM vs GDRAM

其实最早用在显卡上的DDR颗粒与用在内存上的DDR颗粒仍然是一样的。后来由于GPU特殊的需要,显存颗粒与内存颗粒开始分道扬镳,这其中包括了几方面的因素:

  1. GPU需要比CPU更高的带宽 GPU不像CPU那样有大容量二三级缓存,GPU与显存之间的数据交换远比CPU频繁,而且大多都是突发性的数据流,因此GPU比CPU更加渴望得到更高的显存带宽支持。位宽×频率=带宽,因此提高带宽的方法就是增加位宽和提高频率,但GPU对于位宽和频率的需求还有其它的因素。
  2. 显卡需要高位宽的显存显卡PCB空间是有限的,在有限的空间内如何合理的安排显存颗粒,无论高中低端显卡都面临这个问题。从布线、成本、性能等多种角度来看,显存都需要达到更高的位宽。 3090是384位。而内存则没有那么多要求,多年来内存条都是64bit,所以单颗内存颗粒没必要设计成高位宽,只要提高容量就行了,所以位宽一直维持在4/8bit。
  3. 显卡能让显存达到更高的频率显存颗粒与GPU配套使用时,一般都经过专门的设计和优化,而不像内存那样有太多顾忌。GPU的显存控制器比CPU或北桥内存控制器性能优异,而且显卡PCB可以随意的进行优化,因此显存一般都能达到更高的频率。而内存受到内存PCB、主板走线、北桥CPU得诸多因素的限制很难冲击高频率。由此算来,显存与内存“分家”既是意料之外,又是情理之中的事情了。为了更好地满足显卡GPU的特殊要求,一些厂商(如三星等)推出了专门为图形系统设计的高速DDR显存,称为“Graphics Double Data Rate DRAM”,也就是我们现在常见的GDDR。

内存频率

1
2
sudo dmidecode|grep -A16 "Memory Device"|grep "Speed"
Speed: 2666 MT/s

显存等效频率

因为显存可以在一个时钟周期内的上升沿和下降沿同时传送数据,所以显存的实际频率应该是标称频率的一半。

从GDDR5开始用两路传输,GDDR6采用四路传输(达到类似效果)。

GDDR6X的频率估计应该至少从16Gbps(GDDR6目前的极限)起跳,20Gbps为主,这样在同样的位宽下,带宽比目前常见的14Gbps GDDR6大一半。比如在常见的中高端显卡256bit~384位宽下能提供512GB/s~768GB/s的带宽。

RTX 3090的GDDR6X显存位宽384bit,等效频率19Gbps到21Gbps,带宽可达912GB/s1006GB/s,达到T级。(384*19/8=912)

RTX 3090 加速频率 (GHz) 1.7, 基础频率 (GHz) 1.4

1
2
19/1.4 = 13.57
21/1.7 = 12.35

消费者设备 GDDR6x DDR4 的带宽对比

  • 上一小节 RTX 3090 带宽在912GB/s1006GB/s 附近
  • DRAM Types 一文里有分析,个人主机插满4条DDR4带宽” 3.2 Gbps * 64 bits * 2 / 8 = 51.2GB/s

可见两者差了20倍左右。

GPU / CPU workload preference

通过上面的例子,大致能知道: 需要高访存带宽和高并行度的SIMD的应用适合分配在GPU上。

最佳并行线程数

$$ 144 SM * 4 warpScheduler/SM * 32 Threads/warps = 18432 $$

参考文献

https://zhuanlan.zhihu.com/p/156171120?utm_source=wechat_session

https://www.cnblogs.com/biglucky/p/4223565.html

https://www.zhihu.com/question/36825227/answer/69351247

https://baijiahao.baidu.com/s?id=1675253413370892973&wfr=spider&for=pc

https://zhuanlan.zhihu.com/p/62234511

https://kknews.cc/digital/x6v69xq.html

[^1]: 并行计算课程-CUDA 密码pa22

AOCC

https://developer.amd.com/amd-aocc/

Install

1
2
3
4
5
6
7
8
cd <compdir>\
tar -xvf aocc-compiler-<ver>.tar
cd aocc-compiler-<ver>
bash install.sh
# It will install the compiler and displaythe AOCC setup instructions.

source <compdir>/setenv_AOCC.sh
# This will setup the shell environment for using AOCC C, C++, and Fortran compiler where the command is executed.

Using AOCC

Libraries

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

https://developer.amd.com/wp-content/resources/AOCC_57223_Install_Guide_Rev_3.1.pdf

AMD Epyc Compiler Options

AMD EPYC™ 7xx2-series Processors Compiler Options Quick Reference Guide

AOCC compiler (with Flang -Fortran Front-End)

Latest release: 2.1, Nov 2019

https://developer.amd.com/amd-aocc/Advanced

GNU compiler collection (gcc, g++, gfortran)

Intel compilers (icc, icpc, ifort)

amd prace guide

需要进一步的研究学习

  1. Amd uprof
  2. PGI compiler
  3. Numactl
  4. OMP_PROC_BIND=TRUE; OMP_PLACES=sockets

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

https://developer.amd.com/wordpress/media/2020/04/Compiler%20Options%20Quick%20Ref%20Guide%20for%20AMD%20EPYC%207xx2%20Series%20Processors.pdf

https://prace-ri.eu/wp-content/uploads/Best-Practice-Guide_AMD.pdf#page35

Prace guide

Intel Compile Options

Win与Linux的区别

选项区别

对于大部分选项,Intel编译器在Win上的格式为:/Qopt,那么对应于Lin上的选项是:-opt。禁用某一个选项的方式是/Qopt-和-opt-。

Intel的编译器、链接器等

在Win上,编译器为icl.exe,链接器为xilink.exe,VS的编译器为cl.exe,链接器为link.exe。

在Linux下,C编译器为icc,C++编译器为icpc(但是也可以使用icc编译C++文件),链接器为xild,打包为xiar,其余工具类似命名。

GNU的C编译器为gcc,C++编译器为g++,链接器为ld,打包为ar

并行化

-qopenmp

-qopenmp-simd

如果选项 O2 或更高版本有效,则启用 OpenMP* SIMD 编译。

-parallel

告诉自动并行程序为可以安全地并行执行的循环生成多线程代码。

要使用此选项,您还必须指定选项 O2 或 O3。
如果还指定了选项 O3,则此选项设置选项 [q 或 Q]opt-matmul。

-qopt-matmul

启用或禁用编译器生成的矩阵乘法(matmul)库调用。

向量化(SIMD指令集)

-xHost

必须至少与-O2一起使用,在Linux系统上,如果既不指定-x也不指定-m,则默认值为-msse2。

-fast

On macOS* systems: -ipo, -mdynamic-no-pic,-O3, -no-prec-div,-fp-model fast=2, and -xHost

On Windows* systems: /O3, /Qipo, /Qprec-div-, /fp:fast=2, and /QxHost

On Linux* systems: -ipo, -O3, -no-prec-div,-static, -fp-model fast=2, and -xHost

指定选项 fast 后,您可以通过在命令行上指定不同的特定于处理器的 [Q]x 选项来覆盖 [Q]xHost 选项设置。但是,命令行上指定的最后一个选项优先。

-march

必须至少与-O2一起使用,如果同时指定 -ax 和 -march 选项,编译器将不会生成特定于 Intel 的指令。

指定 -march=pentium4 设置 -mtune=pentium4。

-x

告诉编译器它可以针对哪些处理器功能,包括它可以生成哪些指令集和优化。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
AMBERLAKE
BROADWELL
CANNONLAKE
CASCADELAKE
COFFEELAKE
GOLDMONT
GOLDMONT-PLUS
HASWELL
ICELAKE-CLIENT (or ICELAKE)
ICELAKE-SERVER
IVYBRIDGE
KABYLAKE
KNL
KNM
SANDYBRIDGE
SILVERMONT
SKYLAKE
SKYLAKE-AVX512
TREMONT
WHISKEYLAKE

-m

告诉编译器它可能针对哪些功能,包括它可能生成的指令集。

-ax

生成基于多个指令集的代码。

HLO

High-level Optimizations,高级(别)优化。O1不属于

-O2

更广泛的优化。英特尔推荐通用。

在O2和更高级别启用矢量化。

在使用IA-32体系结构的系统上:执行一些基本的循环优化,例如分发、谓词Opt、交换、多版本控制和标量替换。

此选项还支持:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
内部函数的内联
文件内过程间优化,包括:
内联
恒定传播
正向替代
常规属性传播
可变地址分析
死静态函数消除
删除未引用变量
以下性能增益功能:
恒定传播
复制传播
死码消除
全局寄存器分配
全局指令调度与控制推测
循环展开
优化代码选择
部分冗余消除
强度折减/诱导变量简化
变量重命名
异常处理优化
尾部递归
窥视孔优化
结构分配降低与优化
死区消除

-O3

O3选项对循环转换(loop transformations)进行更好的处理来优化内存访问。

比-O2更激进,编译时间更长。建议用于涉及密集浮点计算的循环代码。

既执行O2优化,并支持更积极的循环转换,如Fusion、Block Unroll和Jam以及Collasing IF语句。

此选项可以设置其他选项。这由编译器决定,具体取决于您使用的操作系统和体系结构。设置的选项可能会因版本而异。

当O3与options-ax或-x(Linux)或options/Qax或/Qx(Windows)一起使用时,编译器执行的数据依赖性分析比O2更严格,这可能会导致更长的编译时间。

O3优化可能不会导致更高的性能,除非发生循环和内存访问转换。在某些情况下,与O2优化相比,优化可能会减慢代码的速度。

O3选项建议用于循环大量使用浮点计算和处理大型数据集的应用程序。

与非英特尔微处理器相比,共享库中的许多例程针对英特尔微处理器进行了高度优化。

-Ofast

-O3 plus some extras.

IPO

Interprocedural Optimizations,过程间优化。

典型优化措施包括:过程内嵌与重新排序、消除死(执行不到的)代码以及常数传播和内联等基本优化。

过程间优化,当程序链接时检查文件间函数调用的一个步骤。在编译和链接时必须使用此标志。使用这个标志的编译时间非常长,但是根据应用程序的不同,如果与-O*标志结合使用,可能会有明显的性能改进。

内联

内联或内联展开,简单理解,就是将函数调用用函数体代替,主要优点是省去了函数调用开销和返回指令的开销,主要缺点是可能增大代码大小。

PGO

PGO优化是分三步完成的,是一个动态的优化过程。

PGO,即Profile-Guided Optimizations,档案导引优化。

具体选项详解

-mtune=processor

此标志对特定的处理器类型进行额外的调整,但是它不会生成额外的SIMD指令,因此不存在体系结构兼容性问题。调优将涉及对处理器缓存大小、指令优先顺序等的优化。

为支持指定英特尔处理器或微体系结构代码名的处理器优化代码。

-no-prec-div

不启用 提高浮点除法的精度。

-static

不用动态库

-fp-model fast=2

自动向量化时按照固定精度,与OpenMP的选项好像有兼容性的问题

-funroll-all-loops

展开所有循环,即使进入循环时迭代次数不确定。此选项可能会影响性能。

-unroll-aggressive / -no-unroll-aggressive

此选项决定编译器是否对某些循环使用更激进的展开。期权的积极形式可以提高绩效。

此选项可对具有较小恒定递增计数的回路进行积极的完全展开。

falign-loops

将循环对齐到 2 的幂次字节边界。

-falign-loops[=n]是最小对齐边界的可选字节数。它必须是 1 到 4096 之间的 2 的幂,例如 1、2、4、8、16、32、64、128 等。如果为 n 指定 1,则不执行对齐;这与指定选项的否定形式相同。如果不指定 n,则默认对齐为 16 字节。

-O0 / -Od

关闭所有优化选项,-O等于-O2 (Linux* and macOS*)

-O1

在保证代码量不增加的情况下编译,

  1. 实现全局优化;这包括数据流分析、代码运动、强度降低和测试替换、分割生存期分析和指令调度。
  2. 禁用某些内部函数的内联。

遇到的问题

1
icpc -dM -E -x c++ SLIC.cpp

https://stackoverflow.com/questions/34310546/how-can-i-see-which-compilation-options-are-enabled-on-intel-icc-compiler

parallel 与mpicc 或者mpiicc有什么区别呢

开题缘由、总结、反思、吐槽~~

讲实话,IPO PGO我已经晕了,我先列个list,之后再研究

参考文献

https://blog.csdn.net/gengshenghong/article/details/7034748

按字母顺序排列的intel c++编译器选项列表

IPCC Preliminary SLIC Optimization 2

chivier advise on IPCC amd_256

技术路线 描述 时间 加速比 备注
Baseline 串行程序 21872 ms 1
核心循环openmp 未指定 8079ms
核心循环openmp 单节点64核 7690ms 2.84
换intel的ipcp 基于上一步 3071 ms 7.12
-xHOST 其余不行,基于上一步 4012ms
-O3 基于上一步 3593ms

node5

Intel(R) Xeon(R) Platinum 8153 CPU @ 2.00GHz

技术路线 描述 时间 加速比 备注
Baseline 串行程序 29240 ms 1
核心循环openmp 未指定(htop看出64核) 12244 ms
去除无用计算+两个numk的for循环 080501 11953 ms 10054 ms
计算融合(去除inv) 080502 15702 ms 14923 ms 15438 ms 11987 ms
maxlab openmp 基于第三行080503 13872 ms 11716 ms
循环展开?? 14436 ms 14232 ms 15680 ms

-xCOMMON-AVX512 not supports

1
Please verify that both the operating system and the processor support Intel(R) X87, CMOV, MMX, FXSAVE, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, MOVBE, POPCNT, AVX, F16C, FMA, BMI, LZCNT, AVX2, AVX512F, ADX and AVX512CD instructions.

-xCORE-AVX2

1
Please verify that both the operating system and the processor support Intel(R) X87, CMOV, MMX, FXSAVE, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, MOVBE, POPCNT, AVX, F16C, FMA, BMI, LZCNT and AVX2 instructions

没有 FXSAVE,BMI,LZCNT 有BMI1,BMI2

使用-xAVX,或者-xHOST 来选择可用的最先进指令集

1
Please verify that both the operating system and the processor support Intel(R) X87, CMOV, MMX, FXSAVE, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, POPCNT and AVX instructions.

-fast bugs

1
2
3
4
5
ld: cannot find -lstdc++
ld: cannot find -lstdc++
/public1/soft/intel/2020u4/compilers_and_libraries_2020.4.304/linux/compiler/lib/intel64_lin/libiomp5.a(ompt-general.o): In function `ompt_pre_init':
(.text+0x2281): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/var/spool/slurm/d/job437118/slurm_script: line 23: ./SLIC_slurm_intel_o3: No such file or directory

AMD EPYC 7~~2

icpc -Ofast -march=core-avx2 -ipo -mdynamic-no-pic -unroll-aggressive -no-prec-div -fp-mode fast=2 -funroll-all-loops -falign-loops -fma -ftz -fomit-frame-pointer -std=c++11 -qopenmp SLIC_openmp.cpp -o SLIC_slurm_intel_o3

后续优化

基于核心的openmp并行

去除无用计算

1
2
delete all maxxy
if(maxxy[klabels[i]] < distxy[i]) maxxy[klabels[i]] = distxy[i];

计算融合(减少访存次数)

  1. 将inv去除(效果存疑)
  2. maxlab openmp并行(由于不是计算密集的,是不是要循环展开)

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

WebCrawler first try

常见的仿站软件尝试

  1. wget -c -r -np -k -L -p 递归下载
  2. webCopy
  3. WinHTTrack
  4. Octoparse
  5. Teleport pro

遇到的问题

尝试后下载了一些html\css\js文件。但是没有达到我的要求。

我猜测的爬取原理,根据网站返回的index.html以及文件里指向的新文件路径进行递归下载。

这样的问题有:

  1. 无法对json文件里指向的材质包路径进行递归下载
  2. 无法读取指定网站文件夹的目录,导致不知道文件夹里有什么文件
    1. 假如有ftp://可能可以

需要进一步的研究学习

  1. 通过python实现对json文件里指向的材质包路径进行递归下载(感觉只能半自动)
  2. 读取指定网站文件夹的目录

开题缘由、总结、反思、吐槽~~

在找live2d模型的时候找到了 https://github.com/Eikanya/Live2d-model ,然后其中有个HSO的demo网站https://l2d.alg-wiki.com/。

然后一开始我想在自己页面做一个仿站,后来了解后只想把他里面的live2d的材质数据、贴图等爬下来。但是遇到了几个问题。

参考文献

https://www.shuzhiduo.com/A/E35pV9EAzv/

python crawler

IPCC Preliminary SLIC Optimization 1

第一部分优化

从数据重用(不重复计算,降低计算量)、计算融合(减少访存次数)、循环重组、改变数据结构入手

数据重用

主体变量数据依赖梳理


一开始所有的RGB颜色在ubuff里,klabel存分类结果

首先经过转换,将ubuff的RGB转换为lvec avec bvec三个double[sz]数组
存在私有变量m_lvec m_avec m_bvec,供class内访问

优化建议:lab三种颜色存在一起,访问缓存连续

DoRGBtoLABConversion(ubuff, m_lvec, m_avec, m_bvec);

计算冗余一:


计算出的全体edges,只有一部分在后面一个地方用了196个中心以及周围8个节点。

优化建议:要用edges时再计算(保证了去除不必要计算和计算融合)


优化建议:kseedsl/a/b/x/y 分别用5个vector存是不好的,每个中心的5元组要存在一起,因为访问和修改都是一起的。

优化建议:

  1. 核心计算,是不是要拆开?
  2. 除以maxlab[n],改成乘1/maxlab[n]
  3. maxxy没有用,可以除去定义与数组维护(line 429)
  4. disxy[i]也就可以不用数组

优化建议:

  1. if判断用掩码
  2. 想将与每个像素i有关的属性放在一起,但是distvec要全部初始化。那我维护char*的passcheck数组判断是否已经遍历?未遍历直接赋值,已经遍历,比较后判断是否赋值。
  3. 对于2和并行化这个部分的问题:1.按照中心划分,存储每个点的距不同中心的距离,最后归约取最小。2. 并行还是按照坐标划分,判断在哪几个区域内,然后计算距离最小的)

优化建议:

  1. 对于求和部分labxy与1/clustersize??存在一起
  2. 这部分按坐标并行时,归约的是196个元素的最小值或者求和

vector 连续性

vector中的元素在内存中是连续存储的.

vector的实现是由一个动态数组构成. 当空间不够的时候, 采用类似于C语言的realloc函数重新分配空间. 正是因为vector中的元素是连续存储的, 所以vector支持常数时间内完成元素的随机访问. vector中的iterator属于Random Access Iterator.

cache缓存原理疑问

每级cache难道只存读取数据周围的所有地址数据吗?还是一块一块读的。

假如调度是一块一块读取的而且cache足够大存下时,对于m_lvec m_avec m_bvec,假如各读取同一块,会导致和将其存储在一起是一样的效果。对于m_lvec[i]的下一个元素m_lvec[i+1],m_avec[i+1],m_bvec[i+1]也在cache中。

chivier 建议

1
2
3
4
5
#pragma omp parallel for collapse(2)
icpc -xCOMMON-AVX512 -O3 -std=c++11 -qopenmp SLIC.cpp -o SLIC
g++ -fopenmp
先openMP优化,然后MPI一分为二
数据结构没有必要改,不会访存连续

minicoda for tmux zsh htop gcc9

pip install gdbgui to localhost

gdb tui enable



需要进一步的研究学习

暂无

遇到的问题

暂无

参考文献

Analysis Software

tools

  1. intel vtune
  2. GNU gprof
  3. linux perf
  4. valgrind
    1. memcheck
    2. callgrind
    3. cachegrind
    4. Helgrind
  5. ITAC (for MPI)
  6. IPM (for MPI)
  7. Charging software
    1. paramon
    2. paratunes

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

2021 IPCC

参考文献

ZEN2


Zen 2 使用所谓的 TAGE 分支预测器,它比其前身具有更深的分支历史。这通过比 Zen (+) 更大的分支目标缓冲区 (BTB) 得到增强,L1 BTB(512 个条目)增加了一倍,L2 BTB 几乎增加了一倍(现在为 7K)。随着 MOP 缓存增长到 4K,更大更好的主题仍在继续。这特别方便,因为没有处理器想要多次解码微操作。将它们解码一次并将它们放入大(r)缓存中可以加快速度并使处理器更高效。

有趣的是,在分析了大量应用程序及其数据集大小后,指令缓存实际上从 64KB 下降到 32KB,但关联性从 4 路增加到 8 路。原因是,根据 Mike Clark 的说法,这种减少几乎不会降低性能:无论如何,大多数数据集都需要超过 64KB。新的缓存还具有改进的预取和更好的利用率。

这一切意味着 Zen 2 的前端更高效——有助于 IPC——但确实以占用更多空间为代价。

Zen 2 微架构的简化图

单个核心

参考文献

https://hexus.net/tech/news/cpu/131549-the-architecture-behind-amds-zen-2-ryzen-3000-cpus/

https://en.wikichip.org/wiki/amd/microarchitectures/zen_2