跳转至

Tutorials

VNC

常用命令

# shaojiemike @ node5 in ~ [11:26:56]
$ vncserver -list

TigerVNC server sessions:

X DISPLAY #     RFB PORT #      PROCESS ID
:1              5901            148718 (stale)

# shaojiemike @ node5 in ~ [11:29:39]
$ vncpasswd
Password:

# shaojiemike @ node5 in ~ [11:34:08]
$ vncserver -kill :1
Killing Xtigervnc process ID 148718... which was already dead
Cleaning stale pidfile '/home/shaojiemike/.vnc/node5:1.pid'!

# shaojiemike @ node5 in ~ [11:36:15]
$ vncserver

New 'node5:2 (shaojiemike)' desktop at :2 on machine node5

Starting applications specified in /etc/X11/Xvnc-session
Log file is /home/shaojiemike/.vnc/node5:2.log

Use xtigervncviewer -SecurityTypes VncAuth -passwd /home/shaojiemike/.vnc/passwd :2 to connect to the VNC server.

客户端转发

ssh -L 5901:127.0.0.1:5901 -N -f -l shaojiemike node5.xydustc.me

需要进一步的研究学习

暂无

遇到的问题

暂无

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

参考文献

LLVM Mca : huawei HiSilicon's TSV110 work

几个对比图

x轴的含义是改变port值的意思,比如tsv110alu2是在tsv110的基础上将alu的值改成2

相关的 git commit

commit c9ca3a3c66a493d72cf7afc7ee975e2de399f2e5
Author: Elvina Yakubova <[email protected]>
Date:   Sat Nov 7 01:50:43 2020 +0300

    [AArch64] Add driver tests for HiSilicon's TSV110

commit 93b99728b1676d23ab5dabc606344230d25e7f4b
Author: Elvina Yakubova <[email protected]>
Date:   Sat Nov 7 01:22:35 2020 +0300

    [AArch64] Add pipeline model for HiSilicon's TSV110

    This patch adds the scheduling and cost model for TSV110.

    Reviewed by: SjoerdMeijer, bryanpkc

    Differential Revision: https://reviews.llvm.org/D89972

commit 123553921f86ac0fad7b742740aa45e8d380be02
Author: Bryan Chan <[email protected]>
Date:   Fri Nov 9 19:32:08 2018 +0000

    [AArch64] Support HiSilicon's TSV110 processor

    Reviewers: t.p.northover, SjoerdMeijer, kristof.beyls

    Reviewed By: kristof.beyls

    Subscribers: olista01, javed.absar, kristof.beyls, kristina, llvm-commits

    Differential Revision: https://reviews.llvm.org/D53908

    llvm-svn: 346546    
只有3个,感觉和2个功能很相关。

最近 Driver commit

类似的llvm check的设置

复现上面的图

要改的地方

应该每次都要重新编译安装

测试的汇编代码

  1. 判断llvm/test/MC/AArch64下的汇编能用吗?选个最大的,neon 不支持, armv8.2也并不支持。感觉有特别要求
    cat neon-diagnostics.s|llvm-mca -timeline -show-encoding -all-stats -all-views
    
  2. 选择osaca的benchmark里的add.c

AArch64SchedTSV110.td

locate at llvm/lib/Target/AArch64/AArch64SchedTSV110.td

td file

tablegen(LLVM class) definitions

部分指令解释

def : InstRW<[TSV110Wr_2cyc_1MDU],   (instregex "^(AND|BIC|EON|EOR|ORN|ORR)[WX]rs$")>;
BIC (bit clear) EON (Exclusive OR) ORR (OR operations on the values in Rn and Operand2)

InstRW的定义

// Map a set of opcodes to a list of SchedReadWrite types. This allows
// the subtarget to easily override specific operations.
//
// SchedModel ties this opcode mapping to a processor.
class InstRW<list<SchedReadWrite> rw, dag instrlist> {
  list<SchedReadWrite> OperandReadWrites = rw;
  dag Instrs = instrlist;
  SchedMachineModel SchedModel = ?;
  // Allow a subtarget to mark some instructions as unsupported.
  bit Unsupported = false;
}
TSV110Wr_2cyc_1MDU的定义
def TSV110Wr_2cyc_1MDU   : SchedWriteRes<[TSV110UnitMDU]>   { let Latency = 2; }

class SchedWriteRes<list<ProcResourceKind> resources> : SchedWrite,
  ProcWriteResources<resources>;

//定义TSV110上可用的每种处理器资源和数量,
//它有8条pipeline管道,每个管道都有自己的队列,微操作在那里等待
//它们的operands和issue将无序地发送到八个执行管道之一。
def TSV110UnitMDU  : ProcResource<1>; // Multi-Cycle

需要进一步的研究学习

暂无

遇到的问题

暂无

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

参考文献

LLVM Mca :with BHive (2019)

BHive

一种新的profiler,可以profile没有用户干预的内存访问的基本块。

基于这种profiler创建了BHive,来验证llvm-mca等模型。

BHive是用来评价llvm-mca这些模型的,实验基于各种收集来的一个基本块各种评价

I. INTRODUCTION

Automatically Profiling Basic Blocks

困难在于现有的 没有考虑 memory crash ??? .默认命中L1 cache

A key technical challenge with collecting a large basic block dataset is that there is no existing approach to profile an arbitrary basic block that has been removed from its program context.

(没懂?那为什么要removed from its program context) 因为要把常用的应用拆成小例子来评判,这些模型的准确性。

原理

运用隐含狄利克雷分布LDA,基于cpu资源的利用率,来cluster benchmark suite里的基本块

通过对各种类型最基本的代码块来进行profile,从而形成针对各种performance model的数据库。

现在已经有超过30万的基本块分析,来源于各种方向的应用,包括数值计算OpenBLAS,数据库SQLite,机器学习TensorFlow,密码学OpenSSL。

这么多的数据产生了一个用于评估performance model的新benchmark。

作者说performance modeling 研究的未来在于与其他先进技术的大规模定量比较

内存访问的处理

通过把虚拟页面映射到单个物理页面,来合法内存访问同时避免cache miss

II. 背景

Existing Performance Models

有两种model 1. 产生可以详细描述指令何时发射和退休的可解释执行路径的微架构模拟器,附带吞吐量预测。 2. 每条指令都有延迟、吞吐量查找表,相当于一个被寄存器分配器使用的额外开销估计器

各种model, 写到另一篇里了

  1. IACA
  2. llvm-mca
  3. OSACA
  4. Ithemal

Machine Code Profilers

  1. 通过 Agner Fog’s script 测量真实的,有周期,cache miss 等等。https://www.agner.org/optimize/testp.zip
  2. nanoBench也是。https://github.com/andreas-abel/nanoBench 可以指定processor?和 kernel模式。
  3. Unrolling
  4. 测量吞吐量的基本方法就是展开一个基本块的代码多次,然后测重复多次的代码。把展开的基本块latency除以unroll factor(典型值是100)
  5. 目的:
    1. 边缘化前几次warm up的latency值的影响。
    2. 减少收起数据的开销影响
  6. unroll factor就是循环展开次数。
  7. 局限性是,必须人工给代码块,不能自动profile一堆任意的基本块来系统性验证。???

III. PROFILING ARBITRARY BASIC BLOCKS

目标是在不需要手动干预的情况下分析任意基本块,以便测量的吞吐量与性能模型通常假定的定义和不变量相对应。关键的挑战是使这些基本块能够在不崩溃的情况下访问任意内存地址

由于基本块只是正常程序的一部分,导致根本不能单独正常运行。BHive做的事情就是,让他正常运行。

Handling Arbitrary Memory Accesses

这个代码块只有执行代码分配在0x4110a时,才能正常运行 1. Remapping Virtual Pages. 1. 一个基本块的所有虚拟内存页重新映射到一个物理页上,所以全部数据访问都命中L1。这样就可以执行97%的基本块。 2. 步骤 1. 把原本虚拟页全部unmap 1. 这会导致除了包含基本块指令的页之外的全部的连续的内存访问出问题??? 2. 在子进程里运行展开的基本块指令。 1. 这时对每个unmap的虚拟页的访问都会出错,但是主进程一种监视着。一旦中断就重新映射出错地址,然后重新开始跑。 2. Memory Initialization 1. 初始化一个中等大小0x12345600的物理页,允许都虚拟页都映射 3. Virtual page aliasing 1. 因为不同的虚拟页映射在同一个物理页的同一项导致memory dependences,要等待 2. 剔除6.28%的基本块 3. 可以通过增大物理页,来减小发生的概率。

Overall Profiling Workflow

通过重复运行基本块来计算吞吐量 1. Raw Measurement 1. 先从基本块里,产生不会memory crash的可执行部分。 2. unroll factor的选取。It uses 100 and 200 as the unroll factors for basic blocks smaller than 100 bytes; 50 and 100 for basic blocks between 100 bytes and 200 bytes; and finally 16 and 32 for basic blocks larger than 200 bytes 2. Filtering 1. 筛选执行代码满足理想化模型的执行结果,比如命中L1cache 2. L1 Cache Misses 1. 工具可以用硬件计数器监控指令和数据cache misses。拒绝所有cache miss的情况。 3. Unaligned Loads 1. 不连续的访存会很慢,解决方法就是去除所有有不连续的访存的。大约删除了0.18%的基本块 4. Subnormal Floating Point 1. 一些特殊的浮点数计算会比正常的浮点数计算慢20倍,去除了与MXCSR寄存器有关的0.1%的基本块。 2. https://stackoverflow.com/questions/8341395/what-is-a-subnormal-floating-point-number 5. Context Switches 1. 上下文切换(英语:context switch),又称环境切换,电脑术语,是一个存储和重建CPU的状态 (内文),因此令多个进程(process)可以分享单一CPU资源的计算过程。要切换CPU上的进程时,必需先行存储目前进程的状态,再将欲运行的进程之状态读回CPU中。 6. 可接受的评估公式 10%的误差??? 3. Throughput Calculation 1. 如果通过了基本块的筛选,用有记录的最小延迟计算吞吐量 4. Environment Variance 1. 由于环境的影响,导致结果有个稳定的偏移。至少执行5次,展开16次的基本块。取最小的5次作为结果。

Portability to Other Architectures

只要架构满足以下几点要求 1. 有将多个虚拟页面映射到几个物理页面的API。map multiple virtual pages to a few physical pages 1. without incurring a performance penalty due to unnecessary cache invalidation. We therefore require that the target processor has a physically tagged data cache(VIPT)??? 1. we additionally require that the page size is small enough so the indexing bits are not affected by address translation. 1. detecting cache misses, 2. and detecting or disabling floating-point underflow.

IV. BASIC BLOCK DATASET

应用的选择

  1. 尽可能还原现实生活的各个方面,
  2. 而且是用户的典型用法。
  3. Clang/LLVM (compiler), Redis (inmemory database), SQLite (database), and Gzip 是用高级语言C或者C++编写的,算法和数据结构有复杂的设计。
  4. OpenSSL (cryptography), OpenBLAS , Eigen (scientific computing),TensorFlow (machine learning) 代表的是核心循环是手动汇编优化过的高性能库。
  5. 其中Embree是 用Intel ispc (a data-parallel language)编写的。

We compiled all applications with the highest optimization settings defined by their build systems. 如果可以用上了AVX2。

使用DynamoRIO动态分析来提炼基本块。可以实现在运行时记录每个运行的基本块。我们采用动态分析,而不是静态反汇编。因为静态反汇编无法区别padding bytes from instructions。???

应用的例子除了FFmpeg and Gzip都是选择的官方的benchmark。 Eigen 采用的是 two sparse linear algebra workloads: sparse matrix-matrix multiplication (SpMM) and sparse matrix-vector multiplication (SpMV).

V. BASIC BLOCK CLUSTERING

一些基本块比其他的更难建模,???(建什么模,VI-B说明了什么)有内存依赖的基本块预测错误率更高。

采用了一种技术???(是应用在提取上) 基于处理器的使用聚类基本块。 这个技术有助于性能模型的设计和使用者更细粒度了解performance model,让他们能集中以后新添加的资源在有困难的那一类基本块。

  1. Methodology
  2. 具体方法
    1. 找到每个基本块的硬件使用率的表示 port-mapping representation
    2. 根据其聚类
  3. 对每条指令结合port使用
    1. 运用 Abel and Reineke A. Abel and J. Reineke, “uops.info: Characterizing latency, throughput, and port usage of instructions on intel microarchitectures,” in ASPLOS, 2019的结果 ???
    2. 例如???
      1. xor %rax, %rbx in Haswell is {p0156 → 1}
  4. 使用Latent Dirichlet Allocation (LDA)来构建topic model 模型(python 训练模型)
    1. 在语言处理上的应用是基于统计词频
    2. 在实际运用的时候,微指令操作会根据使用的port而有小不同。
      1. topics是分类的类别,6类
      2. documents是基本块
      3. α = 1/6 and β = 1/13.
    3. 为了推断每个微指令操作所属的类别,我们使用了SciKit Learn transform对于LDA的随机变化推断的默认实现
    4. 计算每个基本块的最有可能的类别作为其分类结果
  5. Results
  6. LDA将结果聚类后,根据基本块的内容,手动进行注名以及说明
  7. example
  8. 根据运行时频率确定其权重, 基于sample-based profiler??? (A portable sampling-based profiler for java virtual machines,)确定。
  9. 高性能的库如预期一样,向量化的基本块占比较多。
  10. 其余的无向量化的较多。OpenSSL and Gzip有许多位操作的。
  11. Case Study on Data-Center Applications
  12. 目的:作为测试例子,看这个聚类方法能不能找得到隐藏的热点、工作负载
  13. Methodology
    1. 第一步:首先将其基本块分成之前的几类,还是使用LDA
    2. 第二步:分类结果标注
    3. 第三步:比较聚类结果的perplexity值???
    4. ???有没有结合google的应用
  14. Results
    1. 添加新应用后,该值只是略微增长。说明模型的代表性好。???

VI. PERFORMANCE MODEL EVALUATION

在3种Intel架构上验证4种已有的性能模型 1. Methodology 1. 说明各个测试软件的版本。 2. Dataset 1. basic block dataset discussed in Section IV 3. Platform 1. balabala 3种架构的 Intel cpus 4. Evaluation Metrics 1. 测量吞吐量t和预测吞吐量t'\(\(err(t,t')=|\frac{t-t'}{t}|\)\) 2. 不以预测精度,而是以预测结果的相对关系为评分标准。 5. 额外能评估每个模型如何保持基本块吞吐量的顺序。使用Kendall’s tau系数(越大效果越好),而不是相对误差。测量的原因是使用者可能关心的不是绝对的数值精度,而是相对关系的准确率。比如优化软件的时候关心的不是具体耗时,而是哪个优化策略耗时更短。 2. Results 1. 2. IACA 第二好的,在向量化类模拟的最好 3. llvm-mca 最差的,尤其是和loads有关时。 4. Ithemal 除了向量基本块都是最好的。在memory dependence (Ld/St)尤其好,但是向量基本块不好,可能与训练集没有向量基本块有关。 5. OSACA 第三。由于还在开发中,使用还遇到5个bug。在遇到一些不认识的指令的时候,会直接按照nops空指令处理。 3. Examples of Modeling Bugs 1. 最后一个例子是由于模型错误调度微指令导致的 2. Modeling bug due to unsigned division 1. 例子是 a 64-bit by 32-bit unsigned division. 2. ??? 3. Modeling bug due to zero-idioms 1. 2. 对这种结果固定的特殊指令的快速处理。 4. Modeling bug due to mis-scheduling 1. 对于数据依赖,上下指令的寄存器有写后读。 2. Ithemal’s and OSACA忽略了该依赖 3. 4. llvm-mca 没有注意到(%rcx)是memory,没有依赖可以提前发射。

CONCLUSION

现有的静态分析器对内存依赖向量化块的建模还有困难。

github代码说明

  1. benchmark/sources下是各种软件的各个部分的16进制基本代码块和其出现概率,用csv格式(逗号分隔值 (Comma-separated values))存储
  2. benchmark/throughput是在各种架构下的各基本块的测量吞吐量,单位cycles per hundred-iterations.
  3. benchmark/disasm可以把16进制代码通过nasm变成汇编,
  4. timing-harness 吞吐量的计算(猜的)Skylake microarchitecture\(\(\frac{6632-1030}{2333-100}*100=250.8 (cyc/hundred\ iters)\)\)

BHive 被质疑的局限性

uops 的文章, Accurate Throughput Prediction of Basic Blocks on Recent Intel Microarchitectures

4.2 Extending BHive

BHive 运行逻辑

  1. 读入16进制代码和循环次数
  2. hhex2bin转换为二进制
  3. create_shm_fd
  4. shm_open, shm_unlinkcreates and opens a new, or opens or unlink an existing, POSIX shared memory object. O_RDWR Open the object for read-write access.O_CREAT the shared memory object if it does not exist. 777是类似文件读写执行组权限的东西 On success, shm_open() returns a file descriptor (a nonnegative integer)

  5. POSIX可移植操作系统接口The Portable Operating System Interface 是IEEE为要在各种UNIX操作系统上运行软件,而定义API的一系列互相关联的标准的总称。

  6. ftruncate — truncate截短 a file to a specified length
  7. define SIZE_OF_HARNESS_MEM (4096 * 3)

  8. measure开始测量
  9. int fds[2] ???
  10. pipe用于创建pipe,用来进程间通信的单向数据通路,传入变量用来返回引用自pipe末端的文件描述符file descriptors。第一个指向the read end of the pipe,第二个指向the write end of the pipe
  11. mmap(void *addr, size_t length, int prot, int flags,int fd, off_t offset); munmap(void *addr, size_t length);- map or unmap files or devices into memory 在调用进程的虚拟地址空间里create a new mapping.
  12. fork()产生子进程
    1. fork()原理详解
      1. 复制之前的一模一样。
      2. fork() returns a zero to the newly created child process.
      3. fork() returns a positive value, the process ID of the child process, to the parent.
    2. 父进程
      1. define OFFSET_TO_COUNTERS 32

      2. 为什么声明一个偏移地址指针???
        1. struct pmc_counters 由5个uint64_t组成。 uint64 will always take 8 bytes。一个结构体40bytes
      3. attach_to_child(pid, fds[1]); pid是子进程pid
        1. ptrace(enum __ptrace_request request, pid_t pid,void *addr, void *data) - process trace 提供一种进程tracer跟踪控制另一个进程tracee的方法,可以修改被控制者的memory and registers.
        2. PTRACE_SEIZE Attach to the process specified in pid, making it a tracee of the calling process. Unlike PTRACE_ATTACH, PTRACE_SEIZE does not stop the process
        3. 子进程从fds[0]里读到x里,父进程把x的值写入 fds[1] ???
      4. check Performance Monitoring Counters (PMCs) supports
        1. rdpmc_open_attr initialize a raw ring 3 ReaDable PerforMance Counter
      5. last_failing_inst 和 mapping_done
      6. To kill child
        1. define MAX_FAULTS 1024 # 子进程产生的错误需要解决?

        2. wait挂起当前线程,直到有一个children结束,返回其PID
        3. WIFEXITEDWait_IF_EXITED 判断是否正常结束
        4. 如果错误打印出错信号(eg.11)指令指针寄存器RIP,指针寄存器RSP
        5. 函数是用汇编写的就离谱what is aux mem?
        6. 修改出错地方的寄存器,重新运行PTRACE_CONT Restart the stopped tracee process
        7. 最多执行MAX_FAULTS次
      7. 最后父进程杀死子进程
    3. 子进程
      1. 父进程测试是否支持PMCs,子进程使用
      2. harness.c :277

https://www.cnblogs.com/from-zero/p/13750852.html

需要进一步的研究学习

暂无

遇到的问题

  1. time 怎么算的the latency of the basic block?为什么打印15个呢?
  2. 还有中间的错误是怎么回事?
  3. 论文里的误差怎么算的?
  4. BHive整合了几个软件(整合了什么呢),应该是真实测量了得出真实吞吐量?还是也是模拟的?
  5. 和uops比怎么样
  6. 哪个数据是准确的,是BHive模拟的,还是真实测量的。
  7. 通过 Agner Fog’s script 测量真实的,有周期,cache miss 等等。https://www.agner.org/optimize/testp.zip
  8. nanoBench也是。https://github.com/andreas-abel/nanoBench 可以指定processor?和 kernel模式。
  9. 局限性是,必须人工给代码块,不能自动profile一堆任意的基本块来系统性验证。???
  10. BHvie的代码实现,移植到鲲鹏,然后根据PMU调准。

问题是x86的二进制或者汇编不能变成aarm64的二进制或者汇编。

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

参考文献

https://github.com/ithemal/bhive

LLVM-MCA: Install&RunTests

github

https://github.com/llvm/llvm-project/tree/main/llvm/tools/llvm-mca

Quick Start

安装

下载可执行文件上传服务器,解压

安装遇到的问题

  1. cannot find libtinfo.so.5
  2. sudo apt install libncurses5
  3. ln -s /usr/lib/libncursesw.so.6 /usr/lib/libtinfo.so.5 或者类似的 ln -s /usr/lib/libncurses.so.5 /usr/lib/libtinfo.so.5
  4. 在/snap/core下找到了,但是这是什么目录?是之前Ubuntu的包管理工具,但是已经不用了。

从源码安装

node5

由于之后要写代码的,还是从头安装更好。

cd llvm-project
mkdir build
cmake -S llvm -B build -G "Unix Makefiles" -DLLVM_ENABLE_PROJECTS="clang;llvm-mca" -DCMAKE_INSTALL_PREFIX="~/Install/llvm" -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_ASSERTIONS=On
cd build
make -j32
make install

kunpeng

cmake -S llvm -B build -G "Unix Makefiles" -DLLVM_ENABLE_PROJECTS=all -DCMAKE_INSTALL_PREFIX="~/Install/llvm" -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_ASSERTIONS=On
#change cmake or -DLLVM_ENABLE_PROJECTS="all"
error
g++: error: unrecognized command line option ‘-mllvm’
g++: error: unrecognized command line option ‘--tail-merge-threshold=0’
g++: error: unrecognized command line option ‘-combiner-global-alias-analysis’
change
cmake -S llvm -B build -G "Unix Makefiles" -DLLVM_ENABLE_PROJECTS="clang;llvm-mca" -DCMAKE_INSTALL_PREFIX="~/Install/llvm" -DLLVM_TARGETS_TO_BUILD=AArch64 -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_ASSERTIONS=On

使用

clang foo.c -O2 -target x86_64-unknown-unknown -S -o - | llvm-mca -mcpu=btver2
由于不是X86,llc --version 查看到target是 aarch64-unknown-linux-gnu
clang /home/shaojiemike/Download/llvm-project-main/lldb/test/API/lang/c/forward/foo.c -O2 -target aarch64-unknown-linux-gnu -S -o -|llvm-mca -timeline -show-encoding -all-stats -all-views
生成汇编代码,并默认管道到llvm-mca,并开启所有输出。

可以看出是用TSV110Unit的port,默认cpu是tsv110

名词解释

ALU/BRU

算数逻辑单元 ALU 负责处理整数运算指令. 跳转处理单元BRU 负责处理跳转指令. BRU 可以与 ALU 合并, 复用 ALU 的逻辑来计算跳转指令的条件和跳转地址, 也可以作为一个单独的功能单元接入到流水线中.

MDU

乘除法单元 MDU (mult-divide unit)

需要进一步的研究学习

  1. llvm-mca微指令怎么实现的,怎么把汇编变成微指令
  2. 在view里加memory的实现
  3. 考虑了cache命中等影响 https://github.com/andreas-abel/uiCA uops
  4. 鲲鹏架构 https://bbs.huaweicloud.com/community/usersnew/id_1513665626477516

遇到的问题

  1. llvm-mca -mcpu=help竟然会卡住,不知道为什么
  2. 所以说是华为已经写了一个叫tsv110的,实现2个功能?

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

参考文献

样例输出

Iterations:        100
Instructions:      200
Total Cycles:      70
Total uOps:        200

Dispatch Width:    4
uOps Per Cycle:    2.86
IPC:               2.86
Block RThroughput: 0.5


No resource or data dependency bottlenecks discovered.


Instruction Info:
[1]: #uOps
[2]: Latency
[3]: RThroughput
[4]: MayLoad
[5]: MayStore
[6]: HasSideEffects (U)
[7]: Encoding Size

[1]    [2]    [3]    [4]    [5]    [6]    [7]    Encodings:                    Instructions:
 1      1     0.33                         4     20 00 80 52                   mov  w0, #1
 1      1     0.50                  U      4     c0 03 5f d6                   ret


Dynamic Dispatch Stall Cycles:
RAT     - Register unavailable:                      0
RCU     - Retire tokens unavailable:                 0
SCHEDQ  - Scheduler full:                            0
LQ      - Load queue full:                           0
SQ      - Store queue full:                          0
GROUP   - Static restrictions on the dispatch group: 0


Dispatch Logic - number of cycles where we saw N micro opcodes dispatched:
[# dispatched], [# cycles]
 0,              20  (28.6%)
 4,              50  (71.4%)


Schedulers - number of cycles where we saw N micro opcodes issued:
[# issued], [# cycles]
 0,          3  (4.3%)
 2,          1  (1.4%)
 3,          66  (94.3%)

Scheduler's queue usage:
No scheduler resources used.


Retire Control Unit - number of cycles where we saw N instructions retired:
[# retired], [# cycles]
 0,           3  (4.3%)
 2,           1  (1.4%)
 3,           66  (94.3%)

Total ROB Entries:                128
Max Used ROB Entries:             59  ( 46.1% )
Average Used ROB Entries per cy:  32  ( 25.0% )


Register File statistics:
Total number of mappings created:    100
Max number of mappings used:         29


Resources:
[0.0] - TSV110UnitAB
[0.1] - TSV110UnitAB
[1]   - TSV110UnitALU
[2]   - TSV110UnitFSU1
[3]   - TSV110UnitFSU2
[4.0] - TSV110UnitLdSt
[4.1] - TSV110UnitLdSt
[5]   - TSV110UnitMDU


Resource pressure per iteration:
[0.0]  [0.1]  [1]    [2]    [3]    [4.0]  [4.1]  [5]    
0.66   0.67   0.67    -      -      -      -      -     

Resource pressure by instruction:
[0.0]  [0.1]  [1]    [2]    [3]    [4.0]  [4.1]  [5]    Instructions:
0.33    -     0.67    -      -      -      -      -     mov w0, #1
0.33   0.67    -      -      -      -      -      -     ret


Timeline view:
Index     0123456789

[0,0]     DeER .   .   mov  w0, #1
[0,1]     DeER .   .   ret
[1,0]     DeER .   .   mov  w0, #1
[1,1]     D=eER.   .   ret
[2,0]     .DeER.   .   mov  w0, #1
[2,1]     .DeER.   .   ret
[3,0]     .D=eER   .   mov  w0, #1
[3,1]     .D=eER   .   ret
[4,0]     . DeER   .   mov  w0, #1
[4,1]     . D=eER  .   ret
[5,0]     . D=eER  .   mov  w0, #1
[5,1]     . D=eER  .   ret
[6,0]     .  D=eER .   mov  w0, #1
[6,1]     .  D=eER .   ret
[7,0]     .  D=eER .   mov  w0, #1
[7,1]     .  D==eER.   ret
[8,0]     .   D=eER.   mov  w0, #1
[8,1]     .   D=eER.   ret
[9,0]     .   D==eER   mov  w0, #1
[9,1]     .   D==eER   ret


Average Wait times (based on the timeline view):
[0]: Executions
[1]: Average time spent waiting in a scheduler's queue
[2]: Average time spent waiting in a scheduler's queue while ready
[3]: Average time elapsed from WB until retire stage

      [0]    [1]    [2]    [3]
0.     10    1.7    1.7    0.0       mov    w0, #1
1.     10    2.0    2.0    0.0       ret
       10    1.9    1.9    0.0       <total>

IPCC Preliminary SLIC Optimization 6: Non-blocking MPI

非阻塞MPI

MPI_Send & MPI_receive

MPI_AllTogether()更慢,需要4s

手动向量化对齐

debug

 vx = _mm256_set_pd(x); #改成
 vx = _mm256_set_pd(x+3,x+2,x+1,x);

发现不对劲,打印更多输出。第一次循环肯定是对的因为和DBL_MAX比较。

需要进一步的研究学习

为什么明明有56GB的IB网,传输速度还是这么慢呢?写比较慢?

7*8=56 8条通道

遇到的问题

暂无

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

参考文献

Hybrid Multithreaded/OpenMP + MPI parallel Programs

混合编程需要注意的问题

https://www.nhr.kit.edu/userdocs/horeka/batch_slurm_mpi_multithread/ 看这个

还有个ppt 16

google hydrid openmpi openmp

intelmpi 编译

这里值得要注意的是,似乎直接用mpif90/mpicxx编译的库会报错,所以需要用

icc -openmp hello.cpp -o hello -DMPICH_IGNORE_CXX_SEEK -L/Path/to/mpi/lib/ -lmpi_mt -lmpiic -I/path/to/mpi/include 其中-DMPICH_IGNORE_CXX_SEEK为防止MPI2协议中一个重复定义问题所使用的选项,为了保证线程安全,必须使用mpi_mt库

对于intel的mpirun,必须在mpirun后加上-env I_MPI_PIN_DOMAIN omp使得每个mpi进程会启动openmp线程。

通过export OMP_NUM_THREADS来控制每个MPI产生多少线程。

OpenMPI 如何实现mult-thread(OpenMP)2

检查编译安装支持mult-thread

shell$ ompi_info | grep "Thread support"
          Thread support: posix (MPI_THREAD_MULTIPLE: yes, OPAL support: yes, OMPI progress: no, Event lib: yes)
shell$
"MPI_THREAD_MULTIPLE: yes"说明是支持的。

在C程序里支持mult-thread

#include <mpi.h>
int MPI_Init_thread(int *argc, char ***argv,
    int required, int *provided)

argc
        C/C++ only: Pointer to the number of arguments.
argv
        C/C++ only: Argument vector.
required
        Desired level of thread support (integer).
provided
        Available level of thread support (integer).
required 可选值 分别是0,1,2,3
MPI_THREAD_SINGLE
        Only one thread will execute.
MPI_THREAD_FUNNELED
        If the process is multithreaded, only the thread that called MPI_Init_thread will make MPI calls.
MPI_THREAD_SERIALIZED
        If the process is multithreaded, only one thread will make MPI library calls at one time.
MPI_THREAD_MULTIPLE
        If the process is multithreaded, multiple threads may call MPI at once with no restrictions.
MPI_Init_thread调用MPI_thread_SINGLE等同于调用MPI_Init。

注意

3.1.6的多线程支持还在初级阶段。开销很高(虽然我不知道为什么)

需要进一步的研究学习

学习MapReduce或者Hadoop? pthread vs openmp?

遇到的问题

暂无

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

参考文献

https://blog.csdn.net/Morizen/article/details/113863591

[2] OpenMPI-multThread

IPCC Preliminary SLIC Optimization 5: MPI + OpenMP

AMD

技术路线 描述 总时间 加速比 备注
Baseline 串行程序 161.7s s 1
more3omp 前面都是可以证明的有效优化 omp_num=32 14.08s
more3omp 前面都是可以证明的有效优化 omp_num=64 11.4s
deletevector 把sz大小的3个vector,移到全局变量,但是需要提前知道sz大小/声明一个特别大的 10.64s 可以看出写成全局变量也不会影响访问时间
enforce_Lscan IPCC opt 4 8.49s 19
enforce_Lscan_MPI_intel intel icpc 3.8s 42.36
Baseline2-max ppm 1.2GB ppm 10*1024*40*1024 928s
enforce_Lscan Baseline2 43.79s 21.2
enforce_Lscan_MPI_intel intel icpc + 双节点两个时间 + MPI(DoRGBtoLABConversion) 18.8s / 20s 46.4
enforce_Lscan_intel intel icpc + 单节点 15.8s 58.74 MPI(DoRGBtoLABConversion)负优化了2s
manualSIMD 13.9s
stream 13.6s
vec2mallocOMP 11.0s
mmap 10.6s
+ -O3 enforce_Lscan_intel 16.2s
+ -xHost 结果不对 17.8s
-Ofast 16.9s
-ipo 15.9s
-O3 -ipo 16.8s
-O3 -march=core-avx2 -fma -ftz -fomit-frame-pointer 16.0s
g++ suggested options -O3 -march-znver1 -mtune=znver1 -fma -mavx2 -m3dnow -fomit-frame-pointer 18.1s
g++ suggested options2 -O3 -march-znver2 -mtune=znver2 -fma -mavx2 -m3dnow -fomit-frame-pointer 19.79s
g++ -Ofast 16.9s
aocc -Ofast 16.3s
aocc suggested options 16.2s

MPI编程

由于是打算两节点两进程MPI,虽然没有OpenMP的共享内存,但是也希望通信能少一点。

PerformSuperpixelSegmentation_VariableSandM

下面关于同步区域的想法是错误的: 因为中心点移动会十分不确定,所以全部同步是最好的。

  1. 第一部分core的思路
  2. 上面numk个中心点直接一分为2,需要同步的是中间相连的\(\(width*(3S)\)\)个中心点(由于PerturbSeeds扰动,而且offset比较大,应该是中间相邻的2排,大约3S的高度的区域,上下1.5S高度)。
  3. distlab需要后面覆盖前面的(当然是计算了的区域)。klabels是取distvec更小对应的那个,应该要写个自定义归约。
  4. numk个中心点有奇数行和偶数行,经过思考后是一样的。
  5. 第二部分各中心maxlab的思路(从sz里提取numk个中心的数据)
  6. sz直接一分为2,最小同步的话,就是中间相邻中心点maxlab要max归约。
  7. 第三部分计算sz里的numk个中心点的质心和
  8. 同理,sz直接一分为2,vector相加归约同步

DoRGBtoLABConversion 0.61s

用MPI_Send写,但是一开始没注意是阻塞的,但是为什么这么慢呢?

对比之前的enforce_Lscan 8.49s
  1. DoRGBtoLABConversion 0.56s
  2. PerformSuperpixelSegmentation_VariableSandM 5.52s
  3. core 0.53s
  4. maxlab 0.02s
  5. sigma 0.03s
  6. DetectLabEdges 0.31s
  7. EnforceLabelConnectivity 1.19s
  8. PerformSuperpixelSegmentation_VariableSandM 0.88s

慢了10~20倍猜测: 1. printf的原因? no 不打印也一样 2. omp_num的值不对? maybe no 3. 不在两个节点上? no 4. g++ mpicxx? no 5. 没有用IB ? 貌似也不是 6. openmpi不支持openmp ? 探究方向

好像是openmp没正常运行omp_num的值为 1,32,64时间都一样。感觉是混合编程的编译问题, 而且好像是假Openmp并行,哪里有锁的样子。突然想起来,Quest的混合变成cmake需要打开multthread类似的支持,但是这里并没用。

好像也不是mpi_init_thread的问题

尝试intelmpi

果然有奇效。(结果是对的,后面我没截图了)。看到这里,可能你会觉得这个问题是OpenMPI有地方不支持openmp。但是后面有神奇的事情,如果NODELIST是fa,而不是fb就不能跑,会直接卡住。😰

首先没找到官方手册说明不同,然后研究一下这两个分区的不同。好吧从IB,cpu,内存都没区别。

限制nodelist再跑一遍。

加上打印时间,用fb分区

这个问题又没有了,但是fa分区由于经常跑可能会热一些。

最大的ppm例子

由于时间已经进5s了。所以我们需要更大的例子,再讨论2节点的开销收益,之前的例子是256034000。 这里生成了1024040960的ppm.再大ppm程序的数组都申请不到栈空间了,需要重新数据结构。

重跑当前最快的enforce_Lscan

icpc + enforce_Lscan_MPI(DoRGBtoLABConversion) icpc + enforce_Lscan g++ suggested options icpc + manualSIMD + lessLscan icpc + manualSIMD + LscanSimple icpc + manualSIMD + LscanSimple + stream icpc + manualSIMD + LscanSimple + stream + mallocOMPinit icpc + manualSIMD + LscanSimple + stream + mallocOMPinit + mmap icpc + manualSIMD + LscanSimple + stream + mallocOMPinit + mmap + unrollLoop

放弃的原因

https://www.bilibili.com/video/BV1a44y1q782 58mins-58min50s

需要进一步的研究学习

暂无

遇到的问题

  1. 混合编程写的有问题,双节点不快反慢。怎么写呢?
  2. 那段串行代码真的不能并行吗?
  3. 向量化为什么没有提升呢,是要循环展开吗?

姜师兄建议

  1. MPI非阻塞通信 gather reduce
  2. 手动向量化

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

参考文献

IPCC Preliminary SLIC Optimization 4: EnforceLabelConnectivity

node5/6

技术路线 描述 总时间 加速比 备注
Baseline 串行程序 207 s 1
more3omp 0.4+5+0.3 23.0s
时间细划,初始化omp 0.03+5+0.1 21.2s
不换算法,必须加锁 特别满
扫描行算法 0.03+2.2+0.1 18.5s
扫描行算法 + task动态线程池 26s
扫描行算法 + task动态线程池 + 延迟发射 26s
扫描行算法 + task动态线程池 + 延迟发射 26s
扫描行算法 + 化解重复,提高粒度:每个线程一行,不同线程杜绝同一行扫描行算法 但是没并行起来 106s
扫描行算法 + 常驻64线程 86s
## 初始时间
Time taken is 21.364595 6.066717 EnforceLabelConnectivityComputing
## 时间细划,初始化omp
细致划分,malloc size大小的空间不耗时,是初始化为-1耗时
Time taken is 16.963094 0.000025 EnforceLabelConnectivity   numlable
Time taken is 17.395982 0.432887 EnforceLabelConnectivity   xvec yvec
Time taken is 22.668060 5.272079 EnforceLabelConnectivity iteration
Time taken is 23.001499 0.333438 EnforceLabelConnectivity klabelsComputing
修改后
Time taken is 16.063057 0.000026 EnforceLabelConnectivity       numlable
Time taken is 16.095485 0.032428 EnforceLabelConnectivity       xvec yvec
Time taken is 21.116599 5.021114 EnforceLabelConnectivity iteration
Time taken is 21.237874 0.121275 EnforceLabelConnectivity klabelsComputing
## 改 dx4,dy4 实现访存连续性
但是可能会导致adjlabel的值不对,导致结果不对

flood fill

openmp线程池+不加锁

4分钟+, 满核结束不了,已经混乱了。

openmp线程池+加锁(单/多个)

5分钟+,满核结束不了,大翻车。

可能的原因: 1. 本来不是计算密集型,加锁导致是串行,而且还有sz次锁的获取与释放的开销。 2. 某个线程改了nlabels,其余运行时读取可能还要同步修改。

我又想到是不是只有一个锁,有没有多个锁的实现。还是超时结束不了。

omp_set_lock(&lock[nindex]); //获得互斥器
if( 0 > nlabels[nindex] && labels[oindex] == labels[nindex] )
{
    xvec[count] = x;
    yvec[count] = y;
    nlabels[nindex] = label;
    count++;
}
omp_unset_lock(&lock[nindex]); //释放互斥器
多个锁满足了nlabels的竞争,但是count的竞争还是只能一个锁。除非将数组保存变成队列才有可能,因为没计数器了。

openmp线程池+队列+(不)加锁

好耶,segmentation fault (core dumped)。果然读到外面去了。

不好耶了,并行的地方加了锁,还是会

double free or corruption (out) //内存越界之类的

debug 不加锁

200~400行不等seg fault。

debug 加锁

然后我打了时间戳 可以看出至少前面是正常的。 多运行几次,有时候segfault,有时corruption,我服了。 但是位置好像还是在上面的循环 每次报错位置还不一样,但是迭代的点还是对的。

队列的原子性操作需要自己加锁定义

https://stackoverflow.com/questions/32227321/atomic-operation-on-queuet

openmpfor+双队列+(不)加锁

munmap_chunk(): invalid pointer
黑人问号?纳尼

没办法,只能加锁,读取,写入都加锁,但是就是特别慢,4分钟+。

omp_set_lock(&lock); //获得互斥器
qindex = workq.front();
workq.pop();
omp_unset_lock(&lock); //释放互斥器

omp_set_lock(&lock2); //获得互斥器
if( 0 > nlabels[nindex] && labels[oindex] == labels[nindex] )
{
    nlabels[nindex] = label;
    workq2.push(nindex);
    saveq.push(nindex);
}
omp_unset_lock(&lock2); //释放互斥器
读取,写入不是同一个队列,尝试用2个锁,还是特别慢,5分钟根本跑不完。

队列换成栈是一样的

q.front()变成了q.top()

扫描行实现

扫描线算法至少比每像素算法快一个数量级。

Time taken is 16.144375 13.062605 PerformSuperpixelSegmentation_VariableSandM 循环
Time taken is 16.144399 0.000025 EnforceLabelConnectivity       numlable
Time taken is 16.177300 0.032901 EnforceLabelConnectivity       xvec yvec
Time taken is 48.978709 32.801409 EnforceLabelConnectivity iteration
Time taken is 49.086252 0.107543 EnforceLabelConnectivity klabelsComputing time=49086 ms
There are 86475718 points' labels are different from original file.
不知道哪里错了,需要debug。简单debug,发现小问题。
Time taken is 15.670141 0.000024 EnforceLabelConnectivity      numlable
Time taken is 15.718014 0.047873 EnforceLabelConnectivity      xvec yvec
Time taken is 22.103680 6.385666 EnforceLabelConnectivity iteration
Time taken is 22.219160 0.115480 EnforceLabelConnectivity klabelsComputing time=22219 ms
There are 0 points' labels are different from original file.
但是尴尬的是并没有快。哭哭哭~~。

优化一下变量,快了3秒,大胜利!!!

Time taken is 16.203514 0.000029 EnforceLabelConnectivity      numlable
Time taken is 16.234977 0.031463 EnforceLabelConnectivity      xvec yvec
Time taken is 18.428990 2.194013 EnforceLabelConnectivity iteration
Time taken is 18.527664 0.098674 EnforceLabelConnectivity klabelsComputing time=18527 ms
There are 0 points' labels are different from original file.

扫描行并行实现 + 上下建线程,左右在线程里跑

用task写

虽然我在总结里写了,很难控制。但是,哎,我就是不信邪,就是玩😉

喜提segfault,打印task调用,发现task从上到下,之字形调用,而且没用一个结束的。按照设想,横向x增加比调用task快的,现在好像task堵塞的样子。

好像是没加,但是结果不对

#pragma omp parallel num_threads(64)
{
    #pragma omp single
让我们仔细分析一下是怎么偏离预期的: 1. (0,2)调用(0,3),(0,3)调用(0,4)很正常。但是(0,3)竟然调用了(2,4),这说明(0,3)循环到(1,3)时,发现(1,4)是已经处理的,而(2,4)是未处理的。进一步说明了(0,4)在被(0,3)创建了之后,先一步循环到(1,4),并将其处理。 2. (0,4)先循环到(1,4),反手还调用(1,3)。然后由于(0,3)调用了(2,4)。导致(0,4)循环到后面以为到(2,4)就截止了。 3. 虽然我说不出有什么问题,但是这不受控制的混乱调用,肯定不是我们想见的。

尝试把占用时间的print去掉。时间不短(重复调用),还是错的。(后面才发现,错误是threadcount,threadq里,每次循环完忘记清空了。日~)

Time taken is 16.226124 0.000024 EnforceLabelConnectivity      numlable
Time taken is 16.258697 0.032573 EnforceLabelConnectivity      xvec yvec
Time taken is 26.320222 10.061525 EnforceLabelConnectivity iteration
Time taken is 26.401399 0.081177 EnforceLabelConnectivity klabelsComputing time=26401 ms
There are 86588716 points' labels are different from original file.

Time taken is 15.743455 0.000025 EnforceLabelConnectivity       numlable
Time taken is 15.773654 0.030198 EnforceLabelConnectivity       xvec yvec
Time taken is 26.348979 10.575326 EnforceLabelConnectivity iteration
Time taken is 26.442129 0.093150 EnforceLabelConnectivity klabelsComputing time=26442 ms
There are 0 points' labels are different from original file.
现在的想法是要有先后顺序,把对(x,y)一行都处理完,再发射task。或者采取延迟发射的。

延迟发射
  1. 把发射任务(x+delay,y)用队列存储,每次循环check一下,最后循环结束后,在全部发射。
  2. 或者标记(x+delay,y)发射(x,y)。但是对于循环结束后的,不好处理。

Time taken is 17.344073 0.000027 EnforceLabelConnectivity      numlable
Time taken is 17.377535 0.033462 EnforceLabelConnectivity      xvec yvec
Time taken is 28.461901 11.084366 EnforceLabelConnectivity iteration
Time taken is 28.544698 0.082797 EnforceLabelConnectivity klabelsComputing time=28544 ms
There are 86588716 points' labels are different from original file.
很奇怪,结果不对。难道是delay的值太小。

把delay的值从10调整到750,甚至是2600,大于宽度了,结果还是不对。这是不对劲的,因为这时相当于把对(x,y)一行都处理完,再发射task。

这时我才感觉到是其他地方写错了,错误是threadcount,threadq里,每次循环完忘记清空了。日~

delay = 2600 结果是对了,但是也太慢了,至少要比串行快啊?

Time taken is 15.538704 0.000026 EnforceLabelConnectivity      numlable
Time taken is 15.577671 0.038968 EnforceLabelConnectivity      xvec yvec
Time taken is 28.233859 12.656188 EnforceLabelConnectivity iteration
Time taken is 28.332256 0.098396 EnforceLabelConnectivity klabelsComputing time=28332 ms

delay = 20 快了一点,哭

Time taken is 15.631368 0.000025 EnforceLabelConnectivity       numlable
Time taken is 15.661496 0.030128 EnforceLabelConnectivity       xvec yvec
Time taken is 26.788105 11.126609 EnforceLabelConnectivity iteration
Time taken is 26.869487 0.081382 EnforceLabelConnectivity klabelsComputing time=26869 ms
There are 0 points' labels are different from original file.

逆向优化分析
  1. 打上时间戳

    end Time 84 32839 taken is 0.000000 dxy4
    end Time 84 32839 taken is 0.000000 threadcount
    end Time 84 32839 taken is 0.031285 core
    end Time 84 32839 taken is 0.000023 count
    
    说明还是并行没写好。

  2. 检查是否调用64核,htop显示是64核

  3. 猜测原因
    • 产生了大量重复的任务,还是划分的原因,上下限制了之后,左右的重复情况如何化解。
      • 每个进程一行,task分配到y%64号线程去。但是openmp的task好像不能指定线程号。
      • 任务压入第y%64个队列,线程从队列取任务。
      • eg,第3行的后面两个线程,threadcount=0,无作用。
    • 有许多任务量过小的情况,粒度不够,次数还多,导致调用产生的开销大
    • task的线程池就是不靠谱
  4. 可以行分割或列分割,根据输入

化解重复,提高粒度:每个线程一行,不同线程杜绝同一行

  • 任务压入第y%64个队列,线程从队列取任务。
    • 但是这里同一队列的写入与读取又冲突了。可以用64个双队列,一写一读。在交换的时候等待+同步。
    • 不同线程写入同一个也冲突,每个线程再来64个队列保存,同步的时候再汇总写入。

想法很美好,但是最后的效果并不是每次64线程,基本都只有1-5个任务。导致近似单线程还有调用开销。(node6有人,node5慢些)

Time taken is 36.212269 32.876626 PerformSuperpixelSegmentation_VariableSandM 循环
Time taken is 36.212297 0.000028 EnforceLabelConnectivity       numlable
Time taken is 36.247536 0.035239 EnforceLabelConnectivity       xvec yvec
Time taken is 106.097341 69.849805 EnforceLabelConnectivity iteration
Time taken is 106.204154 0.106813 EnforceLabelConnectivity klabelsComputing time=106204 ms
There are 0 points' labels are different from original file.
这个原因感觉是一开始只有1个,然后一般也就产生1/2个任务。将其初始任务改成64个就行。

但是如何一开始启动64个呢,我又提前不知道任务

常驻64线程

写完又是segFault,debug 1. [64][64][10000]太大了,每次的队列应该没这么多[64][64][100] 2. 对于结束的统计,要用同步一下,需要加critical。结果就对了 但是,这也太慢了

Time taken is 28.219408 0.000017 EnforceLabelConnectivity       numlable
Time taken is 28.271994 0.052586 EnforceLabelConnectivity       xvec yvec
Time taken is 83.591540 55.319546 EnforceLabelConnectivity iteration
Time taken is 83.696990 0.105450 EnforceLabelConnectivity klabelsComputing time=83696 ms
There are 0 points' labels are different from original file.

受控的分段任务

没时间研究

openmpfor+特殊双数组(1+4?)

没时间研究

需要进一步的研究学习

感觉要自己写个结构体 1. 数据可以无序 2. 最好数据各异 3. 支持并行读每个元素(数组? 4. 支持并行写一堆元素,并且维护size大小

遇到的问题

暂无

并行总结

在这次并行中,让我意识到几点 1. 任务的划分一定不能重复,相互干扰。比如,四邻域泛洪任务重复会导致竞争问题,需要加锁。但是,描绘线,任务不重复,直接避免了加锁的低效。而且重复会导致计算重复,同时占用线程。 2. 并行任务的结果,如果不是一定要存在同一个变量就分开存,既不需要线程私有变量,最后归约;也不会存同一个位置导致竞争。比如,这次的任务会产生一堆不相关的index,那直接每个线程一个数组存,既不会冲突,之后还能接着并行。或者用更大的sz大小数组存index,结果更不会冲突了。 3. 对于任务数增加且不确定的情况,不推荐使用task进程。因为自动调度很难控制,既不知道迭代了多少,也不确定之后会不会有隐藏的竞争。 推荐类似双队列的调度,确定一批任务,并行一批任务,同步一批任务的结果,然后重新并行。 1. 问题:中间并行一批任务的时候还是记得分开存结果。同步的时候再处理一下就行。 2. 双队列可能有任务量过少的问题,导致变单线程。 3. 想到了一种启动64常驻线程,产生任务又等待任务的结构。但是问题是:任务的保存要满足产生任务的写入和处理任务的读取。在不考虑写爆的情况(循环),维护数组的写入与读取位置是可行的。任务的结束通过每个线程在读取不到任务时,判断自己发布的所有任务也被完成了,标记自己发布的任务完成了。所有发布的任务都完成,再结束。

好吧,我感觉我分析了一堆,就是在放屁。还是串行快,这个问题就难划分。就不是并行的算法。

编程总结

这次编程遇到的问题,大多数如下:

  1. 对每次循环开始时所以变量的清空,重新赋初值
  2. 结束时,全部清空。

参考文献