笔记¶

2021年8月3日
分类于 Tutorials
需要 1 分钟阅读时间

Training course - IPCC 5 Optimize common tools

CPU vs GPU

GPU vs CPU

CPU: latency-oriented design

低延时的设计思路

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

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

GPU: throughput-oriented design

大吞吐量设计思路

GPU采用了数量众多的计算单元和超长的流水线
但只有非常简单的控制逻辑
几乎省去了Cache。缓存的目的不是保存后面需要访问的数据的，减少cache miss。这点和CPU不同，而是为thread提高服务的。
GPU “over-subscribed” threads： GPU运行任务会启动远超物理核数的thread，原因是借助极小的上下文切换开销，GPU能通过快速切换Threads/warps来隐藏访存延迟。
1. GPU线程的创建与调度使用硬件而不是操作系统，速度很快（PowerPC创建线程需要37万个周期）¹
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特殊的需要，显存颗粒与内存颗粒开始分道扬镳，这其中包括了几方面的因素：

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

内存频率

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/s到1006GB/s，达到T级。(384*19/8=912)

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

19/1.4 = 13.57
21/1.7 = 12.35

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

上一小节 RTX 3090 带宽在912GB/s到1006GB/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

并行计算课程-CUDA 密码pa22 ↩

2021年7月28日
分类于 Tutorials
需要 1 分钟阅读时间

AOCC

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

Install

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.

参考文献

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

2021年7月28日
分类于 Tutorials
需要 2 分钟阅读时间

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 uprof
PGI compiler
Numactl
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

2021年7月27日
分类于 Tutorials
需要 2 分钟阅读时间

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

并行化

-parallel

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

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

HLO

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

-O2

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

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

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

此选项还支持：

内部函数的内联
文件内过程间优化，包括：
   内联
   恒定传播
   正向替代
   常规属性传播
   可变地址分析
   死静态函数消除
   删除未引用变量
以下性能增益功能：
   恒定传播
   复制传播
   死码消除
   全局寄存器分配
   全局指令调度与控制推测
   循环展开
   优化代码选择
   部分冗余消除
   强度折减/诱导变量简化
   变量重命名
   异常处理优化
   尾部递归
   窥视孔优化
   结构分配降低与优化
   死区消除

-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选项建议用于循环大量使用浮点计算和处理大型数据集的应用程序。

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

IPO

Interprocedural Optimizations，过程间优化。

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

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

内联

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

PGO

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

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

具体选项详解

-mtune=processor

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

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

-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 字节。

-O1

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

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

遇到的问题

 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有什么区别呢

参考文献

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

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

2021年7月26日
分类于 Tutorials
需要 2 分钟阅读时间

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

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

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 来选择可用的最先进指令集

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

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

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并行

去除无用计算

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

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

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

需要进一步的研究学习

暂无

遇到的问题

暂无

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

参考文献

无

2021年7月25日
分类于 network
需要 1 分钟阅读时间

WebCrawler first try

常见的仿站软件尝试

wget -c -r -np -k -L -p 递归下载
webCopy
WinHTTrack
Octoparse
Teleport pro

遇到的问题

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

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

这样的问题有：

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

需要进一步的研究学习

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

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

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

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

参考文献

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

python crawler

2021年7月23日
分类于 Tutorials
需要 2 分钟阅读时间

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 建议

#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

需要进一步的研究学习

暂无

遇到的问题

暂无

参考文献

无

2021年7月23日
分类于 Tutorials
需要 1 分钟阅读时间

Analysis Software

tools

intel vtune
GNU gprof
linux perf
valgrind
memcheck
callgrind
cachegrind
Helgrind
ITAC (for MPI)
IPM (for MPI)
Charging software
paramon
paratunes

需要进一步的研究学习

暂无

遇到的问题

暂无

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

2021 IPCC

参考文献

无

2021年7月19日
分类于 Architecture
需要 2 分钟阅读时间

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——但确实以占用更多空间为代价。