• 13:30Concurrency Changes35 Atomic Smart Pointers  Is shared_ptr thread safe?  Yes: control block manipulation thread safe  guarantees object is deleted exactly once  No: accessing pointer not thread coordination  Latches   A thread coordination point  Threads block at a latch point, until a given number of threads reach the latch point, at which point all threads are allowed to Library  Barriers   A sequence of phases  In each phase  a number of threads block until the requested number of threads arrive at the barrier, then  a phase completion callback is

control_block: atomic ref_count = 1; … control_block* ctrl; T12 Daniel Anderson -- danielanderson.net std::shared_ptr (the basics) T* ptr; shared_ptr s1: control_block: control_block* ctrl; shared_ptr s2: control_block* ctrl; atomic ref_count = 2; …13 Daniel Anderson -- danielanderson.net std::shared_ptr (the basics) control_block: T T* ptr; control_block* ctrl; atomic shared_ptr s2:14 Daniel Anderson -- danielanderson.net std::shared_ptr (the basics) control_block: T atomic ref_count = 0; …15 Daniel Anderson -- danielanderson.net std::atomic16

20; float* x; float* y; // … int block_size = 256; int grid_size = (N + block_size - 1) / block_size; add_gpu<<block_size>>>(N, x, y); // … } Ok, about the kernel y[i] = x[i] + y[i]; } TEST_CASE("cppcon-1", "[CUDA]") { // … add_gpu<<block_size>>>(N, x, y); // … } Ok, about the kernel parameters 10 |Memory“In a typical PC or cluster memory necessary for access by GPU. • May improve performance of your CPU code by: • Reducing the number of calls to the allocator. • Improving locality of objects. • Providing a way to instrument your

duration (e.g., the user-defined fn is allowed to block or take long time) Asynchronous Reclamation • Asynchronous reclamation is invoked when the number of retired objects reaches some threshold: • In In the Folly library: • The threshold is the max of 1000 and twice the number of hazard pointers in the process. • Otherwise, invoked every 2 seconds. • Steps: • Extract retired objects from lists in the objects back into the domain lists. • Reclaim unmatched objects. • Bounds the number of not-yet-reclaimed objects to approx. the number of hazard pointers • No guarantee for the timing of reclamation of individual

except for:  if consteval is part of core language, so no header needed  Within an if consteval block you can call immediate (consteval) functions, which you cannot do in /*A*/ above  if consteval code as unreachable can improve performance  E.g.: void do_something(int number_that_is_only_0_1_2_or_3) { switch (number_that_is_only_0_1_2_or_3) { case 0: case 2: handle_0_or_2(); Changes to Views Library  views::repeat(): A view repeating a given value infinitely or a specified number of times  E.g.: auto r11 { std::views::repeat(2, 3) }; // {2, 2, 2} auto r12 { std::views::repeat(2)

std::shared_ptr(block) Control Block T T T T T …my::shared_ptr Control Block T T T T T T … int ref_cnt; int size; my::shared_ptr(block)I will write it myself ™ Control Block T T T T T T … templateblock // Cast and initialize each T // return my::shared_ptr(block); } // FixMe: What about alignment? // ToDo: Are these reinterpret_casts to be modern C++FlexClass A tool in the shed#include template struct Block { auto fc_handles() { return fc::make_tuple(&data); } int size; int ref_cnt;

1 • Python 的模运算 a % b 的值始终是 [0, b) 区间内的正数，非常方便。 对稀疏数据结构造成的问题 • 如果这里的 x 是负数，则 x % B 也是负数，会造成对 m_block 的越界访问。 • 因此 % 会返回负数对 CFD 用户来说是个很大的坑点，很多人想当然地用 % 做循环边界， 然而这对负方向会不起作用。 解决： (a % b + b) % b • 我看一些 的值始终是向下取整，非常方便。 对稀疏数据结构造成的问题 • 也就是说，如果 x 是 [-3,0] 则 x / B 会是 0 ，如果 x 是 [0,3] 则 x / B 也是 0 。导致两个 同时跑到一个 block 上去，会出错。 高效的解决：位运算 >> • 如果 b 是 2 的幂次方，即： 2, 4, 8, 16, 32 等 。 • 则： a / pow(2,n) = a >> n • 也就是说 位，组合成一个 32 位的整数。 解决： & 替代 % ， >> 替代 / ， | 替代 + 块编号直接为对齐的坐标， << 改成 & 和 ~ 自动推算 B 和 Bmask ，顺便扁平化 Block 第 3 章：多层稀疏 用一个指针的数组来表示 图片解释：指针数组的原理 1 nul nul 2 3 nul nul nul nul 表示 nullptr （空指针） 图片解释：指针数组的稀疏

？我觉得应该叫 threadNum 才比较合理？ • 小彭老师也这么觉得，可能是历史遗留下 来的问题，就不追究了。 线程之上：板块 • CUDA 中还有一个比线程更大的概念，那就是板 块（ block ），一个板块可以有多个线程组成。这 就是为什么刚刚获取线程数量的变量用的是 blockDim ，实际上 blockDim 的含义是每个板块 有多少个线程。 • 要指定板块的数量，只需调节三重尖括号里第一个 threadIdx • 当前板块中的线程数量： blockDim • 当前板块的编号： blockIdx • 总的板块数量： gridDim • 线程 (thread) ：并行的最小单位 • 板块 (block) ：包含若干个线程 • 网格 (grid) ：指整个任务，包含若干个板块 • 从属关系：线程＜板块＜网格 • 调用语法： <<>> 区分板块和线程有点麻烦？“扁平化”他们！ 那么为什么中间要插一个板块呢？感觉很 不直观，不如直接说线程数量不就好了？ • 这还得从 GPU 的硬件架构说起。 SM （ Streaming Multiprocessors ）与板块（ block ） • GPU 是由多个流式多处理器（ SM ）组成的。每个 SM 可以处理一个或多个板块。 • SM 又由多个流式单处理器（ SP ）组成。每个 SP 可以处理一个或多个线程。 • 每个

Demo virtio-fs block vm-memory acpi linux-loader kvm-ioctls vm-virtio vsock net VFIO APIC vhost Cloud Hypervisor KVM File System Device Driver Host Linux Kernel vCPU block Memory Guest VM

YX 表示外层 大循环，后两个小写 yx 表示区间大小为 blockSize 的内层小循环 。 循环分块：用图片来直观感受 BM_y_blur BM_y_blur_tiled 分块以后，在 block 内部，即使是 Y 方向的跳跃访问，也是在 刚刚访问过的范围内，所以，只需缓存容量大于 blockSize*nblur 即可避免 cache miss 。 需要缓存： nx*nblur 需要缓存： 需要缓存： blockSize*nblur 循环分块：用图片来直观感受 BM_y_blur BM_y_blur_tiled 但是这样有一个很大的问题，如果插桩的读取范围跨越了 block 的边界，反而会变得跨度更大，导致缓存彻底失效。 需要缓存： nx*nblur 需要缓存： blockSize*nx*nblur 改进：只对 X 循环做分块 BM_y_blur_tiled BM_y_blur_tiled_only_x