跳转至

笔记

  • 分类于 Tutorials
  • 需要 1 分钟阅读时间

Module Command

基本使用

命令 作用
module avail 或 module av 查看系统中可用的软件
module add 或 module load 加载模块
module rm 或 unload 卸载模块
module list 或 module li 显示已加载模块
module purge 卸载所有模块
module show 显示模块配置文件
module swap 或 module switch 将模块1 替换为 模块2
module help 查看具体软件的信息 
source /public1/soft/modules/module.sh 
source /public1/soft/modules/init/zsh 

$ cat module.sh 
#!/bin/sh
source /public1/soft/modules/init/bash
export MODULEPATH=/public1/soft/modulefiles

$ module list
No Modulefiles Currently Loaded.

$ module show intel/2022.1
-------------------------------------------------------------------
/public1/soft/modulefiles/intel/2022.1:

module-whatis   loads the environment of intel oneAPI 2022.1
unsetenv        MKLROOT
setenv          MKLROOT /public1/soft/oneAPI/2022.1/mkl/latest
prepend-path    MANPATH /public1/soft/oneAPI/2022.1/inspector/latest/man
unsetenv        INTEL_LICENSE_FILE
prepend-path    LIBRARY_PATH /public1/soft/oneAPI/2022.1/ipp/latest/lib
prepend-path    LD_LIBRARY_PATH /public1/soft/oneAPI/2022.1/ipp/latest/lib
prepend-path    CPATH /public1/soft/oneAPI/2022.1/ipp/latest/include
prepend-path    NLSPATH /public1/soft/oneAPI/2022.1/mkl/latest/lib/intel64/locale
prepend-path    PATH /public1/soft/oneAPI/2022.1/compiler/latest/linux/bin
setenv          TBBROOT /public1/soft/oneAPI/2022.1/tbb/latest
setenv          DAALROOT        /public1/soft/oneAPI/2022.1/dal/latest

需要进一步的研究学习

暂无

遇到的问题

暂无

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

参考文献

无

  • 分类于 Tutorials
  • 需要 3 分钟阅读时间

SlurmCommand

PBS vs SLURM

更详细在这里

查看仍在运行作业7454119的详细信息

scontrol show job 7454119
squeue -u USERNAME #来查看目前处于运行中的作业。

sacct查询已经结束作业的相关信息

format=jobid,jobname,partition,nodelist,alloccpus,state,end,start,submit
sacct --format=$format -j 7454119

[sca3190@ln121%bscc-a5 ~]$ sacct -D -T -X -u sca3190 -S 2021-11-10T00:00:00 -E 2021-11-30T00:00:00 --format "JobID,User,JobName,Partition,QOS,Elapsed,Start,NodeList,State,ExitCode,workdir%70"
JobID             User    JobName  Partition        QOS    Elapsed               Start        NodeList      State ExitCode                                                                WorkDir 
------------ --------- ---------- ---------- ---------- ---------- ------------------- --------------- ---------- -------- ---------------------------------------------------------------------- 
1050223        sca3190       LQCD    amd_256     normal 19-23:25:24 2021-11-10T00:34:36   fa[0208,0211]  NODE_FAIL      0:0                             /public1/home/sca3190/VEC_REORDER_LQCD/src 

[sca3190@ln121%bscc-a5 ~]$ sacct -D -T -X -u sca3190 -S 2021-11-10T00:00:00 -E 2021-11-30T00:00:00 --format "JobID,User,JobName,Partition,QOS,Elapsed,Start,NodeList,State,ExitCode,workdir%70,Timelimit,Submitline%20,Submit,Layout"
JobID             User    JobName  Partition        QOS    Elapsed               Start        NodeList      State ExitCode                                                                WorkDir  Timelimit           SubmitLine              Submit    Layout 
------------ --------- ---------- ---------- ---------- ---------- ------------------- --------------- ---------- -------- ---------------------------------------------------------------------- ---------- -------------------- ------------------- --------- 
1050223        sca3190       LQCD    amd_256     normal 19-23:25:24 2021-11-10T00:34:36   fa[0208,0211]  NODE_FAIL      0:0                             /public1/home/sca3190/VEC_REORDER_LQCD/src  UNLIMITED                      2021-11-10T00:11:29

OpenMP申请

1个task 64核 

#SBATCH --nodes=1
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=64

问题

IPCC比赛耗时特别多

建议sbatch 加入-t, --time=minutes time limit #SBATCH -t 5:00

第二年参加IPCC发现去年的一个程序跑了很久。

导出excel 获得jobID 1050223

$ sacct -D -T -X -u sca3190 -S 2021-11-10T00:00:00 -E 2021-11-30T00:00:00 --format "JobID,JobName,State,workdir%70"
JobID           JobName      State                                                                WorkDir 
------------ ---------- ---------- ---------------------------------------------------------------------- 
1050223            LQCD  NODE_FAIL                             /public1/home/sca3190/VEC_REORDER_LQCD/src

NODE_FAIL - Job terminated due to failure of one or more allocated nodes.

查看提交脚本，没有什么问题。 

#!/bin/bash
#SBATCH -o ./slurmlog/job_%j_rank%t_%N_%n.out
#SBATCH -p amd_256
#SBATCH -J LQCD
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=64
#SBATCH --exclude=
#SBATCH --cpus-per-task=1
#SBATCH --mail-type=FAIL
#SBATCH [email protected]

source /public1/soft/modules/module.sh
module purge
CC=mpiicc
CXX=mpiicpc
CXX_FLAGS=""
raw_flags="-fPIC -I../include  -std=c++11 -march=core-avx2"

MPIOPT=
computetimes="ibug_buffer"
taskname=so_${CC}_${CXX}_${CXX_FLAGS}

export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
module load intel/20.4.3
module load mpi/intel/20.4.3

make clean
make CC=$CC CXX=$CXX CXX_FLAGS="${CXX_FLAGS}${raw_flags}" TARGET=$taskname
mpirun ./$taskname 0.005  ../data/ipcc_gauge_48_96  48 48 48 96  12 24 24 12 > ./log/3_$taskname$computetimes.log
查看Log文件 
sca3190@ln121%bscc-a5 src]$ cat slurmlog/job_1050223_rank0_fa0208_0.out 
rm -rf liblattice.so dslash.o lattice_fermion.o lattice_gauge.o invert.o  check.o load_gauge.o main
mpiicpc -fPIC -I../include  -std=c++11 -march=core-avx2 -o dslash.o -c dslash.cpp
mpiicpc -fPIC -I../include  -std=c++11 -march=core-avx2 -o lattice_fermion.o -c lattice_fermion.cpp
mpiicpc -fPIC -I../include  -std=c++11 -march=core-avx2 -o lattice_gauge.o -c lattice_gauge.cpp
mpiicpc -fPIC -I../include  -std=c++11 -march=core-avx2 -o invert.o -c invert.cpp
mpiicpc -fPIC -I../include  -std=c++11 -march=core-avx2 -o check.o -c check.cpp
mpiicpc -fPIC -I../include  -std=c++11 -march=core-avx2 -o load_gauge.o -c load_gauge.cpp
mpiicpc --shared dslash.o lattice_fermion.o lattice_gauge.o invert.o check.o load_gauge.o -o liblattice.so 
mpiicpc -fPIC -I../include  -std=c++11 -march=core-avx2 -Wl,-rpath=./ -lmpi -o so_mpiicc_mpiicpc_  main.cpp -L./ -llattice
slurmstepd: error: *** JOB 1050223 ON fa0208 CANCELLED AT 2022-04-20T14:45:43 DUE TO NODE FAILURE, SEE SLURMCTLD LOG FOR DETAILS ***
[[email protected]] check_exit_codes (../../../../../src/pm/i_hydra/libhydra/demux/hydra_demux_poll.c:121): unable to run bstrap_proxy (pid 59376, exit code 256)
[[email protected]] poll_for_event (../../../../../src/pm/i_hydra/libhydra/demux/hydra_demux_poll.c:159): check exit codes error
[[email protected]] HYD_dmx_poll_wait_for_proxy_event (../../../../../src/pm/i_hydra/libhydra/demux/hydra_demux_poll.c:212): poll for event error
[[email protected]] HYD_bstrap_setup (../../../../../src/pm/i_hydra/libhydra/bstrap/src/intel/i_hydra_bstrap.c:772): error waiting for event
[[email protected]] main (../../../../../src/pm/i_hydra/mpiexec/mpiexec.c:1938): error setting up the boostrap proxies
猜测原因是： 卡在编译了。

以后最好不要在sbatch脚本里编译

需要进一步的研究学习

暂无

遇到的问题

暂无

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

参考文献

无

  • 分类于 Architecture
  • 需要 3 分钟阅读时间

Processing In/near Memory

缘由

  1. 指令为中心，数据移动带来的功耗墙，性能墙
  2. 内存计算的经典模式
  3. 3D的内存技术
    1. Through silicon vias
  4. ReRAM 新型结构

PIM分类

  1. 按照PIM core和memory的距离分类

  2. 新的内存工艺使得内存的最小电路单元具有计算能力(忆阻器)

  3. 基于现有的商业DRAM和处理器的设计(加速的上限低一些，但是落地推广应用的阻力也越小, 应用范围更广，编程困难低)
  4. 基于3D堆叠memory(HMC)的设计（Starting from HMC 2.0, it supports the execution of 18 atomic operations in its logic layer.）
  5. 在每个最小存储单元融入计算能力(可以结合忆阻器)
  6. 完整的处理器核，有cache hierarchy
  7. 简单一点的应用相关的硬件计算单元
  8. 或者更简单的Functional Units (FUs)

关键技术

  1. 传统器件
  2. 地址翻译
    1. 三种不同解决思路
      1. 全部由CPU负责指令的发射和翻译
      2. 使能PIM侧页表管理，翻译机制
      3. 物理地址空间隔离（交互时需要拷贝），PIM独立管理地址空间
  3. 数据映射
    1. 物理内存地址排列的冲突（比如 GPUbank）
      1. CPU高带宽访存（会把数据分散来实现高带宽） vs PIM空间局部性(连续数据会跨多个颗粒)
    2. 纯软件方案或者软硬件结合大方案
  4. 安全性
    1. 物理内存被暴露在PIM core下，需要新的机制来确保内存安全。
  5. 数据一致性
    1. 现有一致性协议拓展差
    2. 核数量超级多，成千上万
    3. 解决方法
      1. 内存空间隔离，避免共享
      2. 弱化一致性问题，只处理特殊条件下一致性（eg.任务迁移）
      3. 批量处理一致性请求
  6. 新型器件
  7. 计算误差
  8. 外围电路大
  9. 异构编程模型
  10. 应用场景和编程模型
  11. 高能效比
  12. 高并行和NUMA访问
  13. 识别PIM函数的条件（什么函数适合用PIM做）
    1. 在所有函数中能耗最高
    2. 数据移动占据应用大比例，或者说是唯一的
    3. 访存密集型（通过LLC miss rate来判断）

根据PIM距离Memory的距离分成三类 1. NDP GPU 2. ？ 3. ？

论文1

https://arxiv.org/pdf/2110.01709.pdf

论文2

hardware architecture and software stack for pim based on commercial dram technology

论文3

pim-enabled instructions a low-overhead locality-aware processing-in-memory architecture

论文4

展望

问题

  1. 由于核很小，不支持OS
  2. 但是可以支持message pass（reduce等）
  3. HPC应用经过数学变化后有些变成稀疏计算的，这时候变成memory-bound。所以PIM减少了数据移动，这时提升比较大。
  4. PIM的优势在于能效比，功耗的降低。而不是绝对性能。
  5. 单chip多核怎么通过PIM的思想，软件调度来实现？（不就是减少数据移动，和更近）

需要进一步的研究学习

暂无

遇到的问题

暂无

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

参考文献

无

  • 分类于 Architecture
  • 需要 2 分钟阅读时间

Microarchitecture: Micro-Fusion & Macro-Fusion

Micro-Fusion

历史原因

  1. 有很多对内存进行操作的指令都会被分成两个或以上的μops，如 add eax, [mem] 在解码时就会分成 mov tmp, [mem]; add eax, tmp。这类型的指令在前端只需要fetch与decode一条指令，相比原来的两条指令占用更少资源（带宽、解码资源、功耗），不过由于在解码后分成多个μops，占用资源（μop entries）增多，但是throughput相对较小，使得RAT以及RRF阶段显得更为拥堵。
  2. 随着技术的发展，CPU内部指令处理单元（execution unit）以及端口（port）增多。相对，流水线中的瓶颈会出现在register renaming（RAT）以及retirement（RRF）

为了突破RAT以及RRF阶段的瓶颈，Intel从Pentium M处理器开始引入了micro-fusion技术。

解决办法

在RAT以及RRF阶段，把同一条指令的几个μops混合成一个复杂的μop，使得其只占用一项(比如在ROB里，但是Unlaminated μops会占用2 slots)；

而在EU阶段，该复杂μop会被多次发送到EU中进行处理，表现得像是有多个已被分解的μops一样。（每个uops还是要各自运行）

可以micro-fused的指令

其中一条uops是load或者store

  1. 所有的store指令，写回内存的store指令分为两个步骤：store-address、store-data。
  2. 所有读内存与运算的混合指令（load+op），如：
    • ADDPS XMM9, OWORD PTR [RSP+40]
    • FADD DOUBLE PTR [RDI+RSI*8]
    • XOR RAX, QWORD PTR [RBP+32]
  3. 所有读内存与跳转的混合指令（load+jmp），如：
    • JMP [RDI+200]
    • RET
  4. CMP与TEST对比内存操作数并与立即数的指令（cmp mem-imm）。

例外的指令

不能采用RIP寄存器进行内存寻址： 

CMP [RIP+400], 27
MOV [RIP+3000], 142
JMP [RIP+5000000]
采用了RIP寄存器进行内存寻址的指令是不能被micro-fused的，并且这些指令只能由decoder0进行解码。

Macro-Fusion

历史原因

为了占用更少的资源，Intel在酷睿处理器引入macro-fusion(Macro-Op Fusion, MOP Fusion or Macrofusion)

解决办法

在IQ时读取指令流，把两条指令组合成一个复杂的μop，并且在之后decode等流水线各个阶段都是认为是一项uops。

macro-fused后的指令可以被任意decoder进行解码

可以macro-fused的指令

其他架构ARM,RISC-V见wikiChip

Intel的要求如下： 1. 两条指令要相互紧邻 2. 如果第一条指令在缓存行的第63个字节处结束，而第二条指令在下一行的第0个字节处开始，则无法进行fusion。 3. 两条指令要满足下表,更新的架构可能会拓展 4.

需要进一步的研究学习

暂无

遇到的问题

暂无

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

参考文献

https://www.cnblogs.com/TaigaCon/p/7702920.html

https://blog.csdn.net/hit_shaoqi/article/details/106630483

  • 分类于 Architecture
  • 需要 2 分钟阅读时间

Microarchitecture: Out-Of-Order execution(OoOE/OOE) & Register Renaming

乱序执行的步骤

简单来说每个阶段执行的操作如下：1

1）获取指令，解码后存放到执行缓冲区Reservations Stations 2）乱序执行指令，结果保存在一个结果序列中 3）退休期Retired Circle，重新排列结果序列及安全检查（如地址访问的权限检查），提交结果到寄存器

  1. 取指令/uops
  2. 指令(uops)dispatch 到instruction queue (/instruction buffer / reservation stations).
  3. 指令等待操作数指令可用，然后可以在前后指令前离开等待队列
  4. issue到对应port单元执行,并且在 scheduler(reservation station)里跟踪uops依赖。
  5. 结果缓存在(re-order buffer, ROB)
  6. 在Tomasulo算法中，重排序缓冲区（英语：re-order buffer, ROB）)可以使指令在乱序执行，之后按照原有顺序提交。
  7. 按照程序序结束(只有前面的指令都完成写回寄存器的操作)，该指令才能retire
  8. 在retire的时候，重新排序运算结果来实现指令的顺序执行中的运行结果

why out-of-order execution retire/commit in program order

  1. 对于程序员外部视角来看，程序还是按序执行的。
  2. 如果指令出错，可以精确定位exceptions 位置，并且执行回滚来复原。
  3. ？？？寄存器数据依赖(重命名打破？)

乱序执行的实现

scoreboard

只有当一条指令与之前已发射（issue）的指令之间的冲突消失之后，这条指令才会被发射、执行。

如果某条指令由于数据冲突而停顿，计分板会监视正在执行的指令流，在所有数据相关性造成的冲突化解之后通知停顿的指令开始执行。

Tomasulo 托马苏洛算法

通过寄存器重命名机制，来解决后两种数据依赖。

使用了共享数据总线（common data bus, CDB）将已计算出的值广播给所有需要这个值作为指令源操作数的保留站。

在指令的发射（issue）阶段，如果操作数和保留站都准备就绪，那么指令就可以直接发射并执行。

如果操作数未就绪，则进入保留站的指令会跟踪即将产生这个所需操作数的那个功能单元。

乱序执行的发展

随着流水线pipeline的加深和主存（或者缓存）和处理器间的速度差的变大。在顺序执行处理器等待数据的过程中，乱序执行处理器能够执行大量的指令。使得乱序执行更加重要。

Register Renaming

来由

已知可以通过乱序执行来实现，硬件资源的高效利用(避免计算指令等待访存指令的完成)。为了实现乱序执行，需要通过寄存器重命名来打破寄存器的之间的读写依赖。

例子1

对于原始代码

1. R1=M[1024]
2. R1=R1+2
3. M[1032]=R1
4. R1=M[2048]
5. R1=R1+4
6. M[2056]=R1

原本代码前后3条是没有关系的，可以并行的。需要使用寄存器重命名来解决R1的读后写依赖。

1. R1=M[1024] 4. R2=M[2048]
2. R1=R1+2     5. R2=R2+4
3. M[1032]=R1 6. M[2056]=R2

数据冲突

如果多条指令使用了同一个存储位置，这些指令如果不按程序地址顺序执行可能会导致3种数据冲突（data hazard）:

  • 先写后读（Read-after-write，RAW）:从寄存器或者内存中读取的数据，必然是之前的指令存入此处的。直接数据相关（true data dependency）

  • 先写后写（Write-after-write，WAW）：连续写入特定的寄存器或内存，那么该存储位置最终只包含第二次写的数据。这可以取消或者废除第一次写入操作。WAW相关也被说成是“输出相关”（output dependencies）。

  • 先读后写（Write-after-read，WAR）：读操作获得的数据是此前写入的，而不是此后写操作的结果。因此并行和乱序时无法改善的资源冲突（antidependency）。

后面两个WAW和WAR可以通过寄存器重命名解决（register renaming），不必等待前面的读写操作完成后再执行写操作，可以保持这个存储位置的两份副本：老值与新值。

前一条指令的读老值的操作可以继续进行，无需考虑那些后一条指令的写新值甚至该写新值指令之后的读新值的操作。产生了额外的乱序执行机会。当所有读老值操作被满足后，老值所使用的寄存器既可以释放。这是寄存器重命名的实质。

重命名存储对象

任何被读或写的存储都是可以被重名。

  1. 最常考虑的是通用整数寄存器与浮点寄存器。
  2. 标志寄存器、状态寄存器甚至单个状态位也是常见的重命名的对象。
  3. 内存位置也可以被重命名，虽然这么做不太常见。

通用(逻辑)寄存器和物理寄存器

对于某种ISA，有固定的供编译器/汇编器访问使用的寄存器。例如，Alpha ISA使用32个64位宽整数寄存器，32个64位宽浮点寄存器。

但是一款特定的处理器，实现了这种处理器体系结构。例如Alpha 21264有80个整数寄存器、72个浮点寄存器，作为处理器内物理实现的寄存器。

寄存器个数设计考虑

如果寄存器个数很多，就不需要寄存器重命名机制。比如IA-64指令集体系结构提供了128个通用寄存器。但是这会导致一些问题:

  1. 编译器如果需要重用寄存器会很容易导致程序尺寸大增。
  2. 程序的循环连续迭代执行就需要复制循环体的代码以使用不同的寄存器，这种技术叫做循环展开。
  3. 代码尺寸增加，会导致指令高速缓存的未命中（cache miss）增加，处理器执行停顿等待从低级存储中读入代码。这对运算性能的影响是致命的。
  4. 大量的寄存器，需要在指令的操作数中需要很多位表示，导致程序尺寸变大。
  5. 很多指令集在历史上就使用了很少的寄存器，出于兼容原因现在也很难改变。

实现方法简述

  1. tag索引的寄存器堆（tag-indexed register file）
  2. 保留站（reservation station）方法
  3. 通常是每个执行单元的输入口都有一个物理寄存器堆

相关寄存器部件

  1. 远期寄存器堆（Future File）：
  2. 处理器对分支做投机执行的寄存器的状态保存于此。
  3. 使用逻辑寄存器号来索引访问。
  4. 历史缓冲区（History Buffer）：
  5. 用于保存分支时的逻辑寄存器状态。
  6. 如果分支预测失败，将使用历史缓冲区的数据来恢复执行状态。
  7. 排缓冲区（Reorder Buffer，ROB）：
  8. 为了实现指令的顺序提交，处理器内部使用了一个Buffer。如果在该缓冲区中排在一条指令之前的所有都已经提交，没有处于未提交状态的（称作in flight），则该指令也被提交（即确认执行完毕）。
  9. 因此重排缓冲区是在远期寄存器堆之后，体系结构寄存器堆之前。提交的指令的结果写入体系寄存器堆。
  10. 体系结构寄存器堆（Architectural Register File）或者引退寄存器堆（Retirement Register File，RRF）：
  11. 存储了被提交的体系寄存器的状态。通过逻辑寄存器的号来查询这个寄存器堆。
  12. 重排序缓冲区（reorder buffer）中的引退（retired）或者说提交（committed）指令，把结果写入这个寄存器堆。

所属部件

  1. 编译器
  2. 会尽力检测出类似这样的问题，并把不同的寄存器分配给不同的指令使用。但是，受指令集体系结构的限制，汇编程序可以使用的寄存器名字的数量是有限的。
  3. 硬件实现
  4. 在处理器指令流水线执行时把这些指令集体系结构寄存器映射为不同的物理寄存器。
  5. 比如下图的Renamer / Allocator（也称为Resource Allocation Table (RAT)）将架构寄存器映射到物理寄存器。 它还为loads and stores分配资源，并将uops分到不同端口。

需要进一步的研究学习

暂无

遇到的问题

暂无

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

参考文献

https://zh.wikipedia.org/zh-cn/%E4%B9%B1%E5%BA%8F%E6%89%A7%E8%A1%8C

https://easyperf.net/blog/2018/04/22/What-optimizations-you-can-expect-from-CPU

  1. 对于CPU雪藏的致命问题 ↩

  • 分类于 Architecture
  • 需要 2 分钟阅读时间

Microarchitecture: Zero (one) idioms & Mov Elimination

微架构的关系

寄存器重命名是乱序执行Tomasulo算法的一部分

寄存器重命名可以实现: 1. 部分mov消除 2. NOPs 3. zero (one) idioms 对于这些指令，无序发射到scheduler。可以直接在reorder buffer写入结果。

Zero (one) idioms

Zero (one) idioms 是不管原寄存器src值是什么，结果/目的寄存器dst一直/一定是0 (1)的一类指令。比如：XOR一个寄存器和自己。

  1. 由于是在寄存器重命名阶段(Rename)时实现的
  2. 所以不需要发射到port执行单元执行，占用硬件资源。也没有延迟
  3. 但是需要划分前面部分的decode的带宽，和ROB(reorder buffer)的资源 
    sub eax, eax
xor eax, eax

例子

使用uarch-bench 

xor eax, eax
dec edi
jnz .loop
由于第一条指令是Zero idioms；后两条指令可以macro-fusion。

所以各部分平均执行次数为

指令个数 UOPS_ISSUED UOPS_EXECUTED UOPS_RETIRED
3 2 1 2

特殊的情况

有些架构可能不支持srcImm0-dstReg的指令的Zero idioms 

mov eax, 0

mov Elimination

1. 由于是在寄存器重命名阶段(Rename)时实现的 1. 所以不需要发射到port执行单元执行，占用硬件资源。也没有延迟 2. 但是需要划分前面部分的decode的带宽，和ROB(reorder buffer)的资源

例子

add eax,4
mov ebx,eax ; //寄存器重命名，ebx指向eax即可
sub ebx,ecx
dec edi
jnz .loop
由于第二条指令是mov Elimination；后两条指令可以macro-fusion。

所以各部分平均执行次数为

指令个数 UOPS_ISSUED UOPS_EXECUTED UOPS_RETIRED
5 4 3 4

被覆盖的结果是否能消除

mov eax, 1 ; will be eliminated?
mov eax, 2 
dec edi
jnz .loop
第一个mov被覆盖了。这是属于编译器的工作。CPU做不到这点(即使做得到，为了实现这点设计的硬件开销也会很大，不值得)

无效操作是否能消除

一般和0的立即数作用有关 

xor eax, eax 
sub ebx, eax ; will be eliminated? (eax is always 0)
第二条指令在IvyBridge也不会消除。这同样是编译器的工作

但是llvm-mca通过ZeroRegister的实现，可以消除。

类似的还有 

mov eax, 0
mov ebx, 0
cmp eax, ebx ; eax and ebx are always equal
一般也不会消除。这同样是编译器的工作

需要进一步的研究学习

暂无

遇到的问题

暂无

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

参考文献

https://randomascii.wordpress.com/2012/12/29/the-surprising-subtleties-of-zeroing-a-register/

https://easyperf.net/blog/2018/04/22/What-optimizations-you-can-expect-from-CPU

https://zh.m.wikipedia.org/zh-hans/%E5%AF%84%E5%AD%98%E5%99%A8%E9%87%8D%E5%91%BD%E5%90%8D

  • 分类于 Tutorials
  • 需要 1 分钟阅读时间

Git Push 2 Homepage

ibug的网站部署思路

  1. 基于ibug.github.io
  2. 图片和markdown两个仓库
  3. 对于acsa的网站
  4. 设置了action产生public/*.html
  5. 通过webhook来实现，服务器接收仓库的event信息。
    1. acsa的nginx接收location转发snode5
    2. snode5的nginx转发到127.0.0.2:9000上
    3. webhook.service接收到信息，然后git clone。并返回信息

hugo网站的action文件

根据公开的仓库，hugo的html文件会产生在gh-pages分支下 

name: build

on:
  push:
    branches: [master]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          #submodules: true  # Fetch Hugo themes (true OR recursive)
          fetch-depth: 0    # Fetch all history for .GitInfo and .Lastmod

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: 'latest'
          #extended: true

      - name: Build
        run: hugo --minify

      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        if: github.ref == 'refs/heads/master'
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./public

webhook的实现

接收端转发到内网的机器上（通过修改vim /etc/nginx/sites-enabled/default） 

server{
   location /_webhook/ {
                proxy_pass http://snode5.swangeese.fun;
                proxy_set_header Host $http_host;
    }
}
记得reload systemctl reload nginx

Nginx中location的作用是根据Url来决定怎么处理用户请求(转发请求给其他服务器处理或者查找本地文件进行处理)。location支持正则表达式，配置十分灵活。我们可以在一个虚拟主机(nginx中的一个server节点)下配置多个location以满足如动静分离，防盗链等需求。

在snode5上nginx也需要转发 

 location /_webhook/ {
         proxy_pass http://127.0.0.2:9000;
     }

需要进一步的研究学习

暂无

遇到的问题

暂无

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

参考文献

无

  • 分类于 Programming
  • 需要 1 分钟阅读时间

Go Install and Command

Install

wget https://go.dev/dl/go1.18.3.linux-amd64.tar.gz
rm -rf /usr/local/go && tar -C /usr/local -xzf go1.18.3.linux-amd64.tar.gz
(maybe need sudo)
sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.18.3.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
go version

Command usage

$ cd $HOME/go/src/hello
$ go run main.go #直接运行
Hello, World!!
$ go build # 产生可执行文件
$ ./hello
Hello, World!!

包管理

Packages

Go packages are folders that contain one more go files.

Modules

A modules (starting with vgo and go 1.11) is a versioned collection of packages.

go get github.co­m/a­nda­nhm­/go­-pr­ett­ytimee
go mod init github.co­m/a­nda­nhm­/go­-pr­ett­ytime

go list -m -u all 来检查可以升级的package，

使用go get -u need-upgrade-package 升级后会将新的依赖版本更新到go.mod

也可以使用 go get -u 升级所有依赖

作者：若与 链接：https://www.jianshu.com/p/760c97ff644c 来源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

需要进一步的研究学习

暂无

遇到的问题

暂无

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

参考文献

https://devhints.io/go

  • 分类于 Programming
  • 需要 1 分钟阅读时间

Go mod

简介

go modules 是 golang 1.11 新加的特性。现在1.12 已经发布了，是时候用起来了。Modules官方定义为：

模块是相关Go包的集合。modules是源代码交换和版本控制的单元。 go命令直接支持使用modules，包括记录和解析对其他模块的依赖性。modules替换旧的基于GOPATH的方法来指定在给定构建中使用哪些源文件。

使用

初始化项目

mkdir Gone
cd Gone
go mod init Gone
对应go.mod文件 
module Gone
go 1.14
go.mod文件一旦创建后，它的内容将会被go toolchain全面掌控。

go toolchain会在各类命令执行时，比如go get、go build、go mod等修改和维护go.mod文件。

go.mod 提供了module, require、replace和exclude 四个命令

module 语句指定包的名字（路径） require 语句指定的依赖项模块 replace 语句可以替换依赖项模块 exclude 语句可以忽略依赖项模块

自动添加依赖

对于main.go里的import 

package main

import (
    "crypto/hmac"
    "crypto/sha1"
    "encoding/hex"
    "encoding/json"
    "fmt"
    "io/ioutil"
    "log"
    "net/http"
    "os"
    "os/exec"
    "strings"
)

……
执行 go run main.go 运行代码会发现 go mod 会自动查找依赖自动下载，并修改go.mod（安装 package 的原則是先拉最新的 release tag，若无tag则拉最新的commit）

自己发布module包

结合github很简单实现

需要进一步的研究学习

暂无

遇到的问题

暂无

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

参考文献

https://www.jianshu.com/p/760c97ff644c