博客 · Livinfly

『索尼设计，塑造现代』读记

Thu, 18 Dec 2025 09:07:40 +0000

大部分就是对书里的简单摘记。

摘记

开发新技术的能力，而且也知道为这些技术创造市场和寻找客户的方法。
坚信公司发展的唯一途径是把它作为一个品牌。
Sonus（声音，拉丁语），Sonny Boy（小男孩）
大贺典雄与盛田的故事，指出早期磁带录音机的问题。
一旦某个建议被采纳，提出这个建议的人就要承担这个任务。
自己研发和生产关键零部件。
CD的容量，不是没有逻辑的60，120 min，而是放下世界顶尖歌剧的时长，74 min。（围绕产品讲故事，以及品牌故事）
定期的设计评论会，鼓励设计师主动提案。
TV-501 Mr.Nello 有趣的设计与命名，显像管可以旋转，方便睡觉看。
确实很多先于时代的创新，简约银黑设计也是经典。
漫画之后，便是产品设计选集了,不少设计毫不过时。
（随眼缘随机选一些）
HB-101 (1984) 家用电脑的键盘 + 摇杆的形式，第一次见这种形式的 PC，何尝不是macbook“无头骑士”，扩展卡带也可以直接插
WM-2 (1981) 有点帅的，包括 walkman 的字体。
WM-EX1 (1994)
my first sony (1987) 有点可爱
D-50MK2
D-SJ301 神秘 CD 播放器
NW-A1000 (2005)
NW-S203F (2006)
NW-MS70D (2003)
MDR-E484 (1988)
DSC-T700 (2008)
SCPH-90000 PS2 (2000)
PSP-1000 (2004)
SDR-4X II (2003)
SEP-10BT (2007)
ERS-7 (2003)

后感

后面对索尼的发展历程想再了解一些，简单过了下从叱咤全球到卖大楼，索尼究竟经历了什么？【生意03】哔哩哔哩 bilibili 。

从发展顺序来讲吧。

我认为是天胡开局，技术、资金、人脉、创始人眼界、国际形势，都是很好的。

当时电子消费品刚刚起步，商品的全球化还没那么深刻，索尼从战后的「遗产」中拣出收音机发家，后面几次重要技术突破，很大程度上是因为创始人背后的家族资金能够兜底，方向没错，坚持下来了，就是先进领先。创始人的品味、背景在早期成功中占了很大的部分。

然而在正式脱离第一代创始集团的掌控后，包括消费电子逐渐从硬件中心转为软件中心以及软硬融合的时候，在互联网高歌猛进的时候，索尼就没有很好的人才，并且内部存在转向的难度，曾经老创始人的绝对话语权，到新一代领导人上也显得弱了许多。

再是老创始人被投其所好的人，跨级直接交流，个人喜好导致公司数个大的决策失误，纵使有无数资金，但是逐渐陷入泥沼，最后只能删裁求生。

后续想要继续看看讨论大的公司、组织，甚至国家的形式，关于长期发展的可能、方法的探讨的资料。

『论文阅读』DCP: Addressing Input Dynamism in Long-Context Training via Dynamic Context Parallelism

Wed, 26 Nov 2025 13:11:10 +0000

封面来源：@UMEDAYO_sekaume

tags: #rg/ContextParallelism #rg/TrainingSystem #rg/VarlenSeq #rg/SparseUsed

Motivation

实际常见的 seq varlen，token relationship (sparse) 下，static 的 CP，效果不好。

Background

分块的 attention 计算
Context Parllelism，ulysses, SP, ring attention, ring attention (head-tail)，等 placement 的优化。
varlen，虽然内存、计算是均衡了，通信是冗余的，不管长短都要通信。可以 CP 长，DP 短，见下图。
token relationship，在多样任务下的多种的 mask，会把不下一个 / 其他 device 用不到的 kv block 给传输过去。

有/无序列依赖的算子。

Method

块表示。
- 根据 mask，把 data，分析作为单 head 的 Q, KV, C, O（C 指计算块）的 block 来分析，求解 memory 和 communication 的均衡解，即 placement。
- Q, KV, C, O 块之间存在依赖。
超图划分。
- 考虑到 inter- 通信效率不如 intra-，自然进行层级 placement。
- 根据这些计算、内存、通信等限制条件，汇总为总的计算不均衡容忍度与内存不均衡容忍度，把求解最优分配问题，转变为均衡 Hypergraph 超图划分问题。
- 这是个 NP-hard 问题，使用高效的启发式求解器，PaToH, KaHyPar。
计算通信调度。
- 因为块的计算顺序是无关的，顺序执行可能不能充分利用硬件性能，即不能够很好的 overlap 通信与计算，所以提出多划分执行调度。
- 目标是，将计算块划分到 T 个阶段，最小化每个 device 上的最大计算 / 通信。
- 相当于是一个多维分配问题的 NP-Complete 问题，使用贪心启发式的方法找到均衡的划分。
- 每个阶段计算的通信不超过 1 / T，从无需通信开始。
执行器。
- 核心是块缓冲和指令集，包括块注意力（输入输出块分布可能不连续，所以魔改增加 offset，与 FlexAttn, FlashMask）、块规约、块拷贝、通信启动、通信等待。
其他
- plan 和 model execution 做 overlap，dataloader 预取数据。
- 与其他并行策略，可以 DCP 应占据 TP-CP-DP-PP 中（CP-DP）的分配顺序。

Experiment

Mirco-benchmark (attention op) 设置：在 4 个 AWS EC2 p4de.24xlarge（32张A100 GPU）上，使用 LongDataCollections 数据集，比较 DCP 与 RFA、LoongTrain、TransformerEngine。
End-to-end eval 设置：在 8 个 AWS EC2 p4de.24xlarge 实例（64 张 A100 GPU）上，使用 LongAlign 和 LongDataCollections 数据集，训练 8B 参数 GPT 模型，比较 DCP 与集成在 Megatron-LM 中的增强版 TransformerEngine。
其他块大小与通信量、plan 时间、稀疏度的关系，计算不均衡容忍度与通信量。

Future

做 training，plan 可以有效被 overlap；

如果做 serving，plan 取 1024 大小，需要 10s 不太可用；

先考虑 prefill，但比如如果我是提前为几种常见的 sparse 类型去做预处理，

或者找最类似的情况选 plan，注意 data 均匀（不影响非序列依赖算子的计算量），可能大概还行？

再考虑 decode，q = 1 的话，q block 实际没有了。

nano-vLLM 简单梳理

Tue, 25 Nov 2025 11:27:18 +0000

封面来源：@takeez3

nano-vLLM 作为 Python 简洁实现的朴素 vLLM，对 vLLM 的主要结构能有一个简单的认识。

项目代码简洁，除了少数几个地方变量可能需要琢磨下，其他地方阅读通畅，非常建议阅读源码！

仓库代码：GeeeekExplorer/nano-vllm: Nano vLLM 我 fork 的带有少量英文注释的仓库代码：Livinfly/nano-vllm at private/mengmm

目前 nano-vLLM 仅支持单机多卡 TP。

config 为了简洁，基本是硬编码。

下面将按照文件结构进行介绍，对照上图阅读。

entrypoint

最初可以先看 example.py、bench.py，了解配置、参数流的传输路径。

经过形式上的 llm.py 进入 engine。

engine

LLM Engine

从 __init__() 或者 generate() 看起，下面为了介绍方便，从 __init__() 开始介绍。

LLM Engine，具体由以下几部分组成，他们的初始化在 __init() 中完成。

config
- 模型、kv cache、分布式并行、调度等相关配置。
multiprocessing 分布式配置
- 主要是启动了多个执行 ModelRunner 的进程，后续用于做单机多卡的 TP。
- 基本逻辑见后续 step() 中。
Model Runner
- 模型运行的执行者。
- 主进程，拥有所有其他 GPU 的 event。
- event，因为不是很懂分布式，可以简单理解成给主进程了个调用的方式。
Tokenizer
- 分词器，用于 text 文本和 token_ids 词元编码的编解码，简单理解成人类的语言和大模型的语言相互翻译。
Scheduler
- 调度器，负责调度模型处理的请求。

然后，我们看外界调用的接口 generate()，收起忽略掉 if use_tqdm: 的 debug 调试信息，核心逻辑如下。

把新请求的 prompt 请求加入调度器的队列。具体地，在正式加入调度器之前，会使用 Tokenizer 进行编码，转变成适合模型处理的形式。
加入完毕，逐个 step 处理出完成的结果 output，增量更新整体的结果 outputs。
返回 text 和 token_ids，作为结果和方便调试的输出。

接下来，我们看具体处理输出的函数 step()。

先用我们先前加入 prompt 的 Scheduler 进行 schedule() 调度，得到本次 step 需要处理的 seqs 序列，即需要处理的请求；同时返回本次 step 处理的序列的类型，是 prefill 还是 decode。
传入 model_runner，call 分布式调用 run，模型处理出本次输出的 token_ids。
Scheduler 把新生成的 token_ids 加入 seq 中，并且对 seq 生成是否结束做出判断，同时进行对应的更新。
把生成结束的 seq 返回为 output，同时输出测试使用的 num_tokens 表示处理了多少个 token。

至此，整个框架的主要结构、流程已经介绍完毕，接下来将是一些细节上的实现。

scheduler

我们由主要逻辑 generate() 出发，首先了解 scheduler 的实现细节。

首先从 __init__ 开始。

涉及到一次能调度多少 seqs、tokens 的配置
Block Manager，设置好 num_kvcache_blocks、kvcache_block_size，后续在调度过程中，判断 kv cache 是否够分配，分配、回收块的内存。
- num_kvcache_blocks 在 scheduler 初始化前的 model_runner 初始化的时候确认的。
调度序列
- waiting 等待调度序列
- running 运行中序列（处理过，有 kv cache）

核心逻辑 schedule()。

调度 prefill
- 对 seq 进行 kv cache 分配的可行判断，分配。
- seq 状态的更新，schedule 调度序列的更新。
- 如果存在 prefill 的 seq 调度完，直接返回，prefill 优先，一次调度只调度一种计算类型的 seq。
调度 decode
- 显然只有 prefill 调度完了，或者放不下了，才会到 decode
- 对 running 的序列做进一步处理
- 判断是否可以 append，即 decode 后生成一个 token 的内存占用
- 不能就 preempt() 抢占后续 running 中的 seq，供自己使用
  - 具体地，抢占就是把 seq 放回 waiting 中，释放它的 kv cache。
  - 如果没有能再抢占的序列了，还是不能满足它，则结束 decode 的调度。
  - 特别地，如果此时没有一个 seq 被调度，则报错。
- 可以就正常分配内存。
把新调度的 seq 放到 running 的最前面。

scheduler 调度策略是原 vLLM v0 的默认策略，只支持一个 step prefill 或 decode。具体地，nano-vLLM 优先 prefill，抢占式调度。

block_manager

既然 scheduler 中有提到 block_manager，因为都是很硬的内存分配、共享块的代码，比较琐碎，简单带过。

为了能减少内存碎片，进行 share-prefix 前缀共享，Block 涉及了 hash, ref_count。

具体的内存分配的话，就是先判断能不能，然后再具体分配；追加到最后的块里，还是新开辟一个块。

sequence

琐碎，同样简单带过。

为了序列化、反序列化传输方便，只有必要的序列信息和与块相关的信息。

model_runner

__init__()

模型载入
分布式的通信的配置
- 前面提到的 call 调用 run 的具体实现，就是主进程监听 step() 的 call，收到后广播给其余进程，具体是通过进程 Shared Memory 共享内存，来写、读的。
- 模型的 TP，在配置完 rank、world_size 后，在模型结构侧自动进行切分。
Sampler
- 最后模型输出概率的采样器
warmup，找到模型运行的峰值内存等信息
allocate_kv_cache，根据 warmup 得到的内存信息，进行分配 kv cache。
cuda graph 相关设置（我目前只知道，会 padding）

首先先来看下，allocate_kv_cache()，逻辑简单。

根据模型信息、本地内存信息、TP 信息，算出合理的 config.num_kvcache_blocks
分配当前 rank 模型的 kv_cache，同时绑定到 / 被引用，每层 attention 的 k_cache, v_cache 中。

然后，我们看核心 run()。

prepare_(prefill / decode)，为 run_model 准备上下文，input_ids 新增 token 和 position 位置编码，同时，prepare_block_tables 在 Q 和 KV 没对齐的时候，block 长度对齐。
prepare_sample，为每个 seqs 确定采样 temperature
run_model，运行模型，算出 logits
sample，采样出 token_ids

layers

都是一些算子的实现，主要提以下几个：

attention，k 和 v 在forward 时候，在进入 attention 算子计算前，进行存储。
QKVParallelLinear，ColumnParallelLinear，RowParallelLinear，涉及 TP，Q / K / V/ O 的运算。

models

模型具体并行涉及 TP 相关知识，核心层在 QKVParallelLinear，RowParallelLinear，可以参考 nano vllm源码阅读——TP并行 - 知乎

模型 loader 有些转化，看 Qwen3ForCausalLM.packed_modules_mapping 和 utils.loader。

模型结构比较简单，到最后会回到我在 layers 中提到的几个核心算子。

迷途之子 BanG Dream! It's Mygo!!!!! 观后感

Sun, 16 Nov 2025 14:08:01 +0000

抽帧开始看着有些怪怪的，大概是gbc吃得太好了。

—分割线—

开始就抛出了大的矛盾/谜题，后面将怎么样一步步解题。

—分割线—

心计阳光大咧千早爱音，胆小敏感小众姐高松灯，爱灯椎名立希，我的问题长崎素世

—分割线—

很多情节解释的重要桥段采用第一视角叙事的方式，包括很多的拉近镜头（食材展示x），情绪感给得充沛。

故事就是围绕 Crychic 与 MyGO!!!!! 的展开的，开始的 Crychic 的解散，给出主要矛盾/谜题，然后以爱音转校生，认识同学高松灯为切入点，逐渐展开爱音、灯、爽世的回忆、经历构建人物形象；第一视角的叙事也从爱音、灯、爽世再到灯，虽然会有在一个人物的回忆过后，感觉对这个人物的进一步矛盾深度塑造就有些停滞了（如爱音，不过核心灯不是），但是大概是情节紧吧，至少每一集都留够了矛盾，我补番能迫不及待看下一集，想想当时要等一周、讨论一周才能看一集，相比讨论是十分精彩的「无法预测的命运之舞台」了，少不了的乐队正式演出前赶完歌，完美收场（x）。

爱音，MyGO!!!!!。
- Crychic 问题解决的开始，想着有问题就直接找人面对面沟通，虽然自己也有逃避。
- 爱音那一段开始的逃避的情况，我不喜欢（因为我目前状态也是这样x）
灯，Crychic + MyGO!!!!!，所有人幸福的乐队。
- 无疑是两个乐队最大的纽带。
爽世，Crychic > MyGO!!!!! & Crychic + MyGO!!!!!。
- 扣手手的小动作，会去迎合别人，对 Crychic 持维持态度，春日影的意外演出在她心里一直时抹不过去的事情。
- 被祥子喷伪善后，一度不想玩了，不想再受这样的痛苦了。（初步理解是好不容易付出真心对待的事物吧）后面因为毕竟是真心想要和他们交朋友，所以又回去了。
立希，灯。
- 刻画不算多（？），提到灯唱出她的内心，不过没有具体写，看后面能不能收回吧。
乐奈，有趣的女人喵。
祥子 Oblivionis，我是来结束这个乐队的。
- 结束，后面又开始一个乐队，不是很懂原因，挖坑反正，看起来是纯利益关系的乐队的感觉。
睦 Mortis，祥子 + 爽世。
- 传话筒。
- 可以看出其实玩乐队开心过的，不过还没有具体描写，不知道到底发生了什么。
海玲 Timoris，立希（？）
- 雇佣兵。
初华 Doloris，祥子。
- 我已经在等 ave mujica 的 saki 酱了。
若麦 Amoris，流量（？）
- 网红喵。

不懂 live 诗朗诵，真有吗（x

人物喜欢上的话，睦的偏冷、平静的声音，一直是我的偏好。

还是因为 GBC 在我看之前看过了，所以制作对我来说就是相对贫穷，包括有些地方人物眨眼能半分钟不眨，没有交互到人物的时候，人物是完全静态的。

剧情总体就是很优秀，是我大概少有看到的沉重开局（？），当然能评价为谜语人，不过环环相扣感还是不错的，女女关系性，扭起来（x），带着周更时候的讨论氛围，我觉得可能还能再加一些分，本身的深度的话，因为我没怎么去看讨论，相信还是可以有些挖点的。

音乐的话，总体很不错，因为剧情一直有紧张感，大多时候的背景音乐都是沉重的，出现的完整曲子也都还不错，live 曲和情绪是到位的，主要制作人是之前白色相簿的制作人。硬要说，OP 的话，因为剧情大多数时候都比较低沉，感觉相性没这么好。

「春日影」，作为灯与祥子共同谱写的写给 Crychic 的情诗，然后被 MyGO!!!!! 演出，有种再婚在前夫前带着前夫的孩子出去玩的既视感。

中间还有些应该 BanG Dream 系列的（可能是 ll 的角色客串？不过还没看过 ll 呢）

戛然而止，看起来必吃后面的 Ave Mujica 了，看之前顺便找下名字缘故。

『学习笔记』CMU 15-445 (2024 fall) Note

Thu, 13 Nov 2025 06:46:14 +0000

封面来源：@wusem0108

#00: Course Overview & Logistics

C++ 17 编写 / 调试 bootcamp 熟悉 C++ 11 的特性

C++ 前置要求，见 P12，同时 P0 页面也有进一步给出一些资料。

Lecture #01: Relational Model & Algebra

数据库 database 是相互关联的数据的有组织的集合。

数据库管理系统 DBMS (database management systems)，是管理数据库的软件。

扁平文件 Flat File Strawman

扁平文件。

逗号分隔值 comma-separated value (csv)

实体文件 entity file (artists.csv, albums.csv)。

不同的行分隔不同的记录，同一行内用逗号 comma 来分隔不同的属性 attributes。

schema (attribute 1, attribute 2, …)

需要考虑的问题

数据完整性 Data Integrity
实现 Implementation
持续性 Durability

数据库管理系统 Database Management System

数据模型 data model 是描述数据库的数据的概念集合。

Relational (most common)
NoSQL (key/value, document, graph)
Array / Matrix / Vector (for machine learning)

关系模型 Relational Model

由 Ted Codd (at IBM Research) in the late 1960s 提出，用于解决早期DBMS中逻辑层与物理层紧密耦合。

以简单数据结构（关系）存储数据库
物理存储由DBMS实现决定
通过高级语言访问数据，DBMS 确定最佳执行策略

关系模型三要素

结构 Structure：关系定义及其内容，独立于物理表示
完整性 Integrity：确保数据库内容满足特定约束
操作 Manipulation：访问和修改数据库内容的编程接口

一些术语

关系 (Relation)：无序的属性关系集合（等同于表 table）
元组 (Tuple)：关系中属性值的集合（也称为域 domain）
n元关系 (n-ary)：具有n个属性的关系（等同于 n 列的表 table）
主键 (Primary Key)：唯一标识表中单个元组的属性
外键 (Foreign Key)：指定一个关系中的属性映射到另一个关系的元组
约束 (Constraint)：用户定义的必须满足的条件（如唯一键、外键约束）

数据操作语言 Data Manipulation Languages (DMLs)

存储和便利数据库的方法。

过程式 Procedural

明确指定数据库管理系统应该如何获取数据，需要写 how，如 for 等逻辑
非过程式 Non-procedural （声明式 Declarative）

只指定需要什么数据，而不指定如何获取，需要写 what，由 DBMS 来选定逻辑。

关系代数 Relational Algebra

关系代数 Relational Algebra 是遍历、操作关系元组集合的基础操作集合，可以构建一个链 chain 的 query。

Selection

$\sigma_{predicate}(R)$，SQL: SELECT * FROM R WHERE <predicate>

输入一个关系 Relation，指定谓词 predicate（充当过滤器 filter 的角色），输出满足谓词的元组 tuple 的集合（关系 Relation）。

Projection

$\pi_{A_1,A_2,. . . ,A_n}(R)$，SQL: SELECT b_id-100, a_id FROM R WHERE a_id = ‘a2’

输入一个关系 Relation，指定一些属性 attribute，输出一个关系 Relation，元组 tuples 包含指定属性 attribute。

可以改变属性 attribute 顺序与属性的值。

注意：

attribute 通常可以包含字母(a-z, A-Z)、数字(0-9)和下划线(_)，所以 b_id-100 是取 b_id 的值再减 100。

Union

$(R \cup S)$，SQL: (SELECT * FROM R) UNION ALL (SELECT * FROM S)

输入两个关系 Relation，输出一个关系 Relation 包含所有（至少出现在其中一个关系 Relation 中）的元组 tuple。

注意：

输入的两个关系 Relation 必须有相同的属性 attribute；

SQL 中 UNION 对重复行只保留一份，UNION ALL 都保留。

Intersection

$(R \cap S)$，SQL: (SELECT * FROM R) INTERSECT (SELECT * FROM S)

输入两个关系 Relation，输出一个关系 Relation 包含所有（同时出现在两个关系 Relation 中）的元组 tuple。

注意：

输入的两个关系 Relation 必须有相同的属性 attribute。

Difference

$(R - S)$，SQL: (SELECT * FROM R) EXCEPT (SELECT * FROM S)

输入两个关系 Relation，输出一个关系 Relation 包含所有（在 R 且不在 S 中）的元组 tuple。

注意：

输入的两个关系 Relation 必须有相同的属性 attribute。

Product

$(R \cross S)$，SQL: (SELECT * FROM R) CROSS JOIN (SELECT * FROM S) 或 SELECT * FROM R, S

输入两个关系 Relation，输出一个关系 Relation 包含所有（可能的笛卡尔积组合，产生 |R| * |S| 个）的元组 tuple。

Join

$(R \bowtie S)$，SQL: SELECT * FROM R JOIN S USING (ATTRIBUTE1, ATTRIBUTE2…)

输入两个关系 Relation，输出一个关系 Relation 包含所有（连接两个关系 Relation 中相同的 attribute，合并不同的 attribute 到同一个个 tuple，组合复制）的元组 tuple。

注意：

关于不匹配，即相同属性 attribute，属性值没有同时出现的情况。

还有其他的 Join

Theta Join：基于任意条件的连接（如R.a > S.b）；

Outer Join：保留不匹配的行；

Cross Join：等同于Product操作

效率区别：$(R \bowtie (\sigma_{b_id=102}(S)))$，$\sigma_{b_id=102}(R \bowtie S)$

给定 SQL (Structured Query Language) 这样的高级的声明式表示，能够让 DBMS 去决定处理逻辑。

其他数据模型 Other Data Models

Document Data Model 文档数据模型

记录文档的集合，包含命名字段 / 值对 field / value的层次结构。

value 包括标量 scalar、数组 array、指向其他文档的指针 pointer。

现代实现使用 JSON，之前包括 XML 等对象 object 表示。

通过耦合对象 object 和数据库，避免"关系-对象阻抗不匹配"。

有优点，但也有前面 flat file 提到的一些缺点。

Vector Data Model 向量数据模型

表示用于最近邻搜索 nearest-neighbor search （准确 / 估计）的一维数组

用于基于 ML 模型生成的嵌入 embedding 的语义搜索 semantic search

许多关系型DBMS已添加向量索引功能（如 pgvector）

Databases are ubiquitous.

Lecture #02: Modern SQL

声明式的 query，起源于 IBM System R in the 1970s。

SQL 是在关系型数据库管理系统上，与关系型数据库交互的标准语言。

关系语言 Relational Languages

数据操作语言(DML)：SELECT, INSERT, UPDATE, DELETE
数据定义语言(DDL)：定义表 tables、索引 indexes、视图 views 等对象的结构
数据控制语言(DCL)：管理安全性 Security 和访问控制
其他：视图定义、完整性约束、事务管理

关键区别：关系代数基于集合 set (无序，无重复)，而SQL基于包 bag (无序，允许重复)

后面都是些语法说明，就散记写查的。

GROUP BY，聚合默认是整个结果集为一个组，如果要按某一字段划分，组内分别聚合，则需要 GROUP BY。

WHERE 在 GROUP BY 前，原始数据行；HAVING 在 GROUP BY 后，过滤分组结果。

ON用于连接条件，WHERE用于过滤。

SQL 查询的执行顺序是：

FROM/JOIN（确定数据源）
WHERE（过滤原始行）
GROUP BY（分组）
HAVING（过滤分组结果）
SELECT（选择输出列）
ORDER BY（排序结果）

HAVING 阶段 SELECT 还不存在。

字符串大小写敏感 case sensitive，只允许单引号。

% 匹配任意子串，_ 匹配任一字母。
函数 SUBSTRING(S, B, E) and UPPER(S)…
连接符 ||

INTO 输出重定向

输出控制。

Lecture #03: Database Storage (Part I)

存储 Storage

易失性设备 Volatile Device，byte-addressable，memory 内存

非易失性设备 Non-Volatile Device，block/page addressable，better at sequential access，disk 磁盘，SSD HDD

persistent memory

NVMe (non-volatile memory express)

缓存池 buffer pool 来控制 disk 和 memory 之间的数据移动。

DBMS vs. OS

顶层设计目标

支持超过可用内存的数据库。

像是虚拟内存 virtual memory 的顶层设计目标，

其中的一个实现方式是把文件内容 mmap 到进程中，但如果 mmap 发生 page fault，进程会堵塞。

所以永远不在 DBMS 中使用 mmap。

The operating system is not your friend.

使用以下的指令来使用 OS。

madvise 告诉 OS 什么时候想读某 page
mlock 不要换出某范围的内存
msync 刷新某范围的内存

虽然 OS 有不少可以提供的函数功能，但为了可控和性能，DBMS 自己实现。

文件存储 File Storage

文件层级 file hierarchy

单文件 single file (e.g. SQLite)

DBMS 的存储管理器，管理 database 的文件（page 的集合）

DBMS 的 page 的三个概念

硬件页 hardware page (usually 4 KB)
系统页 OS page (4 KB)
database page (1-16 KB)

存储设备保证了原子写入 atomic write，在 HW page 下。

超出的时候，DBMS 需要为安全写出产生额外开销，所以，一般只读的工作负载，开大点的 page size。

数据库堆 Database Heap

有许多方式找到页 page 的位置，如堆文件 heap file（页 page 的无序集合）。

链表 Linked List，页头有指针指向 free page 和 data page，查找只能串型查找
页面目录 Page Directory

页布局 Page Layout

每格页 page 包含 header

Page size
Checksum
DBMS version
Transaction visibility
Self-containment (Oracle…)

Slotted-pages 开槽页

维护槽 slot 的个数，最后使用的槽 slot 的偏移 offset，槽 slot 的阵列。

槽 slot 头到尾增长，data tuple 尾到头增长
Log-Structured 日志结构

元组布局 Tuple Layout

元组头 Tuple Header，元数据
元组数据 Tuple Data
唯一标识符 Unique Identifier，常见 page_id + (offset / slot)
非规范化的元组数据 Denormalized Tuple Data

两个有关联的表，DBMS 可以预连接 pre-join，这样，就只需要从一个表读，而不是两个不同的表，更高效。

但更新会更贵，因为每个 tuple 需要的空间更大。

Lecture #04: Database Storage II

日志结构存储 Log-Structured Storage

开槽页 Slotted-Page 面向元组 tuple-oriented 的问题

碎片化 Fragmentation
无效磁盘 I/O，面向块的非易失性存储，每次都要读整块取更新一个元组 tuple
随机磁盘 I/O 效率低

如果只能创建新页 page 且不能复写 overwrite，可以解决上面的问题。

基于 LSFS (log-structured file systems) 和 LSM Tree (log-structured merge tree)。

DBMS 存储元组的改变的日志记录，在内存中的数据结构中应用改变 MemTable，再依次把改变写到磁盘中 SSTable。

PUT / DELETE，原地更新在内存中。

读一条记录的时候，先检查 MemTable，不存在的话找 SSTables，从新到旧，使用二分。

为了优化，在内存中维护 SummaryTable，跟踪其他的元数据 min/max key…, key filter。

压缩 Compaction

在写负载重的任务中，SSTable 会很多，周期性使用合并排序，压缩最近的跨页 page 的元组修改。

权衡 Treadeoff

顺序写快，对只附加的存储好
写可能慢
压缩开销大
对写入放大影响，每个逻辑写，会产生多个物理写。

索引组织的存储 Index-Organized Storage

数据直接存在索引结构里，索引即数据，天然有序。

数据表示 Data Representation

填充 Padding 和 重排 Reordering 实现 word-aligned，提高访存效率。

Lecture #05: Storage Models & Compression

数据库工作负载 Database Workloads

OLTP (Online Transaction Processing)

对单个实体 entity 的快速、简单、重复的查询，写多读少。Write Heavy

OLAP (Online Analytical Processing)

时间久、复杂的查询，读多写少，分析数据。 Read Heavy

HTAP (Hybrid Transaction + Analytical Processing)

混合。

存储模型 Storage Models

元组 tuple 的存储

N-Ary Storage Model (NSM)

N 元组存储模型、行存储 row store，在 OLTP write-heavy 的任务中表现好，因为一次就能拿到所有的属性。

但不好压缩。

Decomposition Storage Model (DSM)

分解存储模型、行存储 column store，在 OLAP read-heavy 的任务表现好，因为常分析属性的子集。

在行存储的情况下，把 tuple 放一起有固定长度偏移 fixed-length offsets 或 嵌入元组编号 embedded tuple ids。

Partition Attributes Across (PAX)

跨属性分割。

综合前两种方式的列的访问，和行的局部性。

数据库压缩 Database Compression

在只读分析的工作负责中的常用优化。

块、元组（NSM）、属性、列（DSM）。

压缩率和压缩速度。

列压缩 Columnar Compression

run-length encoding (RLE)

游程编码、运行长度编码。

值 + 起始偏移 + 连续长度。

DBMS 需要预先排序。

Bit-Packing Encoding

根据数据范围，只存有效位。

Mostly Encoding

Bit-Packing 基础上，加上特殊标记，表示在什么时候会超过最大值，维持 look-up table 来存储。

Bitmap Encoding

表示第 i 个值在不在。

常常把位图分成小段，避免占用大块连续内存。

适用于种类少的时候。

Roaring Bitmaps 可以用来压缩稀疏数据。

Delta Encoding

存储和相邻数值的差值。

Incremental Encoding

记录常见的前后缀，对排序后的数据好。

Dictionary Compression

需要支持保序编码 order-preserving encodings，使得能直接在编码后的数据上操作。

Lecture #06: Buffer Pools

buffer pool manager 控制 page 在内存和存储的移动。

优化目标是时 Temporal 空 Spatial 的控制，

page directory = page_id => page_address

page table = frame_id => page_id

lock，能够回滚 roll back 修改。

latch，不需要回滚，锁操作过程。

Least Recently Used (LRU)

CLOCK

在 sequential flooding 顺序扫描中表现不佳。

LRU-K

localization优化局部性、减少对剩余的污染。

priority hints

Direct I/O (via the O DIRECT flag) 来绕过操作系统的 cache

缓冲池的优化 Buffer Pool Optimizations

Multiple Buffer Pools

多个缓冲池，不同的用途用不同的缓冲池。

采用 Object ID 或 Hash 来找到 page_id 应该找哪个缓存池。

Pre-fetching

预取，特别是在顺序扫描的时候。

Scan Sharing (Synchronized Scans)

同步扫描，共享一个扫描。

Buffer Pool Bypass

缓冲池旁路，如顺序扫描等操作，不通过缓冲池，而通过开辟内存的另外的地方。

防止污染缓冲池。

由于 DBMS 能有更多的信息做判断，所以总是比 OS 的操作好，Evictions, Allocations, Pre-fetching。

Lecture #07: Hash Tables

DBMS 的 hash table 在内部使用，不需要加密，指关心速度和冲突率，哈希函数目前的 sota 是 facebook xxhash3。

静态哈希策略 Static Hashing Schemes

Linear Probe Hashing

线性探测哈希，没找到就向后找，删除用 tombstones 来替换。

短的字符串直接存，长的才哈希。

为了维护不同大小的哈希表，维护版本，复用原本的哈希表。

Google’s absl::flat_hash_map 是 sota

Cuckoo Hashing

布谷鸟哈希，多个哈希函数 / 种子，都被占了的时候，踢出原本在的，让它重新哈希。

动态哈希策略 Dynamic Hashing Schemes

能够空间不足的时候，重建哈希表。

Chained Hashing

链哈希。拉链法，hash 到链表的桶，然后遍历链表。

Extendible Hashing

可扩展哈希。拉链法没有限制链表的长度，可扩展哈希，使用必要时分裂当前桶的操作来缓解这一点。

全局深度、局部深度，具体逻辑暂时没有去了解。

Linear Hashing

线性哈希。不在超出的时候立刻分裂，按照指针，一个一个分裂，避免一次性处理过多。

Lecture #08: Indexes & Filters I

table index 表索引，常不用 hash table，因为不支持范围扫描、部分键查找。

B- Tree 在所有节点存值，B+ Tree 只在叶子节点存值。

B+ Tree 的设计选择：

节点大小 Node size、合并阈值 Merge Threshold、变长键 Variable Length Keys（指针、变长节点（内存效率不好）、填充、键映射）

内部节点，M/2 − 1 <= num of keys <= M − 1。

节点内搜索：

线性、二分、插值。

优化方法：

前缀压缩、去重、后缀截断、指针变换、大量插入（自底向上的构建）、写优化（Bϵ-Tree，懒写入）

Lecture #09: Indexes II

过滤器 filter，回答元素是否在集合中。

快速回答，加速查询。（可能假阳性 false positive）

布隆过滤器 Bloom filter

位图 bitmap 实现的概率过滤器，假阳性率可以计算出来，需要定义位图的大小、哈希函数的数量大小。

Insert，算出每个 hash value，对位图大小取模 modular，bitmap 的对应位置 1。

lookup，找有无这样的位图。

变体

计数布隆过滤器 Counting Bloom filter，用整数序列代替位图，支持删除操作。

布谷鸟过滤器 Cuckoo filter，Cuckoo Hash 的思路，存储元素的内存占用，支持删除操作。

精简范围过滤器 Succinct range filter，不可变的过滤器，支持范围查询。

跳表 Skip List

多级链表，没有重平衡的需要。

操作

find，顶层链表开始，逐级下移直到找到目标或确定不存在。

insert，通过抛硬币随机决定新节点的层数，从底层向上逐层插入。

delete，先标记节点为删除状态（避免并发读取问题），后续清理时从顶层向下移除节点。

实现简单，反向扫描复杂，缓存不友好。

字典树 Trie

按字符/位存储键值的前缀信息，每个节点代表一个字符/位，指针指向子节点，操作时间复杂度取决于键的长度。

压缩优化

水平压缩，用数组替代映射表（如256字节数组），减少指针开销。

垂直压缩（Radix Tree），合并单子节点路径，减少树深度，提升查询效率。（假阳性）

倒排索引 Inverted Index

关键词搜索，不同于前面提到的点检索、范围检索，将术语映射到包含该术语的记录列表（posting list）。

从关键词查找文档。

实现方案

Lucene，有限状态转换器（FST, finite state transducer），每条边存储权重，通过权重和计算精确位置。

PostgreSQL，B+树存储词典，小posting list直接存ID，大列表用嵌套B+树。

向量索引 Vector Index

语义搜索，处理嵌入向量（embedding）的相似性查询。

倒排文件分区 Inverted File ，通过聚类将向量分组，查询时定位到相关组，如 IVFFlat。

可导航小世界，Navigable Small Worlds，构建向量邻居图，通过贪婪搜索逼近目标，如 FAISS, HNSWlib。

Lecture #10: Index Concurrency Control

物理正确性：确保数据结构内部指针有效，不访问无效内存

逻辑正确性：保证事务读取到预期值

锁(Locks)：高层逻辑原语，保护数据库内容（如表、元组），事务期间持有，系统自动处理死锁检测

闩锁(Latches)：底层原语，保护内部数据结构，短期持有（如单次操作），需开发者手动避免死锁

闩锁的实现方式 Latch Implementations

compare-and-swap (CAS)

Test-and-Set Spin Latch (TAS)

使用CAS指令自旋等待，std::atomic

单指令加锁/解锁（x86），DBMS完全控制，高竞争时效率低，缓存一致性问题（多线程轮询）。

Blocking OS Mutex

用户空间自旋+内核级互斥量，std::mutex

实现简单，开销大（~25ns/次），需OS调度，不推荐DBMS内部使用。

Reader-Writer Latches

支持读写模式，多读并发，std::shared mutex

允许多个读同时进行，提高读密集型场景性能，需管理读写队列避免饥饿，存储开销大（需额外元数据）。

哈希表闩锁 Hash Table Latching

Page Latches

每页一个读写闩锁，读多写少场景，单页内操作频繁。

Slot Latches

每个槽独立闩锁，高并发写入场景，槽间访问分散。

无闩锁，CAS指令实现的 Linear Probe Hash。

B+Tree Latching

Basic Latch Crabbing Protocol

find，从根节点出发，获取子节点闩锁，再释放父节点闩锁。

insert / delete，自顶向下获取所有需要的闩锁，子节点安全（插入：节点未满；删除：节点半满以上），则释放祖先节点。

Improved Latch Crabbing Protocol

insert / delete，先用 read latch 像 find 到叶子节点，叶子安全直接操作，不安全释放，重新执行上面的协议。

Leaf Node Scans

如扫描和删除，不同遍历方向导致的死锁。（因为分裂 / 合并，需要同时访问两个相邻的节点）

解决方法：

无等待模式 No-wait mode，获取失败则重试；

根据进度来安排有限度。

Lecture #11: Sorting & Aggregation Algorithms

Query plan

数据库把 SQL 编译成操作树——Query plan。

排序 Sorting

Top-N Heap Sort，External merge sort

Two-way Merge Sort

General (K-way) Merge Sort

Double Buffering Optimization，双倍缓冲区，可用缓冲区减半，但取数据和计算同步进行。

Comparison Optimizations，如 Code specialization，例如 template specialization；字符串的后缀截断 suffix truncation。

Using B+Trees，利用 B+Tree index，无需计算，顺序访问。

聚合 Aggregation

Sorting

先过滤再排序，减少排序的数据。

Hashing

不追求顺序的时候。

分区
再哈希

Lecture #12: Joins Algorithms

数据库设计的目标是减少重复信息，因此常通过规范化 normalization theory 将数据拆分到多个表中，再使用 join 重组数据。

通常将较小的表作为外表（outer table）。

Join Operators

实际一般混合使用。

Early Materialization

将匹配的所有列值复制到中间结果中，后续操作无需回基表，但占用更多内存。

Late Materialization

仅复制连接键和记录ID。适合列存储，减少内存占用。

Cost Analysis

主要成本指标：磁盘 I/O 次数。

不考虑输出结果的 I/O，因为所有算法的输出相同。

注意选择合理的连接类型。

Nested Loop Join

外部 for 循环中的表称为外表，而内部 for 循环中的表称为内表。

希望“较小”的表作为外表。

简单嵌套循环连接

将外表中的每个元组与内表中的每个元组进行比较。

成本： M+(m×N)

块嵌套循环连接

对于外表中的每个块，获取内表中的每个块，并比较这两个块中的所有元组。

成本： M+((R中的块数)×N)

块大小：如果 DBMS 有 BB 个可用缓冲区来计算连接，它可以使用 B−2B−2 个缓冲区来扫描外表。页数较少的表将作为外表。它将使用一个缓冲区来扫描内表，一个缓冲区来存储连接的输出。

成本： M+(MB−2)×N

索引嵌套循环连接

先前的嵌套循环连接算法性能不佳，因为 DBMS 必须进行顺序扫描来检查内表中的匹配项。

外表将是没有索引的那个表。内表将是有索引的那个表。

成本：M+(m×C)

Sort-Merge Join

该算法的最坏情况是如果两个表中所有元组的连接属性都包含相同的值，这在实际数据库中极不可能发生。在这种情况下，合并的成本将是 M⋅NM⋅N，因为对于每个外部页，我们将不得不匹配整个内部表。但大多数时候，键几乎是唯一的，因此可以假设合并成本大约为 M+NM+N。

假设 DBMS 有 BB 个缓冲区可用于该算法：

表 RR 的排序成本： 2M×(1+⌈logB−1⌈MB⌉⌉) 表 SS 的排序成本： 2N×(1+⌈logB−1⌈NB⌉⌉)

合并成本： (M+N)

Hash Join

基本哈希连接

Build Phase：扫描外表，根据哈希函数 h1 构建内存中的 Hash Table。

Probe Phase：扫描内表，对每条元组使用 h1 在 Hash Table 中查找匹配。

一个优化是使用布隆过滤器

布隆过滤器是一种概率数据结构，可以放入 CPU 缓存中，并回答“键 x 在哈希表中吗？”的问题，回答要么是“绝对不在”，要么是“可能在”。提供了额外元数据，横向信息传递。

Grace 哈希连接 / 分区哈希连接

优化原理：当哈希表太大无法放入内存时，将两个表都使用同一个哈希函数 h1 分区并写入磁盘。然后，逐对加载对应的分区到内存中进行连接。

递归分区：如果单个分区仍然过大，使用另一个哈希函数 h2 进行递归分区，直到每个子分区都能放入内存。

代价：3(M + N)，源于对两个表的两次读写（分区+探测）。

Hybrid Hash Join：一种自适应优化，用于处理数据倾斜。它将热分区（频繁出现的键）保留在内存中，并在 Build Phase 时立即进行连接，而不是将其溢出到磁盘。

下面将是用 AI 对 Note 进行进一步提炼，复制（略加修改得来的）

Lecture #13: Query Processing I

查询计划与执行概览

查询计划 (Query Plan) 是一个由算子 (Operators) 组成的有向无环图 (DAG)。

流水线 (Pipeline)：一系列算子，数据在其中连续流动，无需中间存储。

流水线破坏者 (Pipeline Breaker)：必须等待其子算子产出所有元组 (Emit All Their Tuples) 后才能开始工作的算子，例如 Join (构建端)、子查询 (Subqueries)、排序 (Order By)。

处理模型 (Processing Models)

处理模型定义了系统如何执行一个查询计划 (Query Plan)。

A. Iterator Model / Volcano Model / Pipeline Model

原理：每个算子实现一个 Next() 函数。调用时返回单条元组 (Single Tuple) 或 null。通过递归调用子算子的 Next() 来拉取 (Pull) 数据。
控制流 (Control Flow)：自顶向下拉取 (Pull)。
优点：
- 输出控制简单，适合流水线 (Pipelining)。
- 几乎所有的基于行 (Row-Based) 的系统都使用它。
缺点：每个元组都调用 Next()，导致高频函数调用，可能成为性能瓶颈。

B. Materialization Model

原理：每个算子一次处理所有输入 (All Input)，并一次性物化 (Materialize) 所有输出 (All Output)。

控制流 (Control Flow)：自顶向下拉取，但每次处理一批。

优点：

函数调用次数少，适合OLTP (Online Transaction Processing) 负载，因为这类查询通常只涉及少量元组。

可结合Late Materialization (延迟物化) 优化。

缺点：不适合中间结果集大的查询，可能导致内存爆炸。

C. Vectorized / Batch Model

原理：每个算子一次处理并返回一批数据 (a Batch of Tuples)。Batch 是一组元组的集合（如 100-1000 个）。

控制流 (Control Flow)：自顶向下拉取，但每次处理一个 Batch。

优点：

显著减少函数调用次数。

更适合利用 SIMD (Single Instruction Multiple Data) 指令进行向量化计算，优化 CPU 利用率。

非常适合 OLAP (Online Analytical Processing) 负载。

现代趋势：许多现代系统（如 Snowflake, Amazon Redshift）采用此模型。

访问方法 (Access Methods)

定义了如何访问表中存储的数据，是查询计划中的叶节点。

A. 顺序扫描 (Sequential Scan)

原理：迭代表中的每一页，评估谓词 (Predicate) 并决定是否发出元组。

优化方法：

预取 (Prefetching)

缓冲池旁路 (Buffer Pool Bypass)：避免顺序淹没 (Sequential Flooding)。

区域映射 (Zone Map)：无损数据跳过 (Lossless Data Skipping)，通过预计算聚合值判断是否需要访问该页。

延迟物化 (Late Materialization)：列存数据库中，延迟组合元组直至查询计划上层。

近似查询 (Approximate Queries)：有损数据跳过 (Lossy Data Skipping)，对数据子集进行采样以快速得到近似结果。

B. 索引扫描 (Index Scan)

原理：DBMS 选择一个索引 (Index) 来查找查询所需的元组。

索引选择因素：索引包含的属性、查询引用的属性、值域 (Value Domains)、谓词组合 (Predicate Composition)、键是否唯一等。

C. 多索引扫描 (Multi-Index Scan)

原理：使用多个索引，分别计算满足条件的记录ID集合 (Sets of Record IDs)，然后根据谓词（如 AND）合并这些集合（使用位图/Bitmaps、哈希表/Hash Tables 或 布隆过滤器/Bloom Filters），最后获取记录并应用剩余谓词。

修改查询 (Modification Queries)

INSERT, UPDATE, DELETE 算子负责检查约束 (Constraints) 和更新索引。

万圣节问题 (Halloween Problem)：一个更新 (Update) 操作改变了元组的物理位置，导致扫描算子 (Scan Operator) 多次访问该元组。

解决方案：跟踪每个查询已修改的记录ID (Record IDs)。

例子

“给所有工资小于25000的员工加薪百分之十”

“所有工资小于25000的哪些记录被无限次数得加薪了百分之十，直到工资大于等于25000为止。”

重复扫描了修改后的元组。

表达式求值 (Expression Evaluation)

WHERE 子句被表示为一棵表达式树 (Expression Tree)。

传统方式：遍历树并逐个求值，速度慢。

优化方式：

代码生成 (Code Generation) / JIT编译 (JIT Compilation)：直接编译表达式为高效代码。
常量折叠 (Constant Folding)：预先计算常量表达式。
公共子表达式消除 (Sub Expression Elimination)：识别并消除重复子表达式。
向量化求值 (Vectorized Evaluation)：对批次元组同时求值。

Lecture #14: Query Execution II

并行执行背景

并行执行通过多个工作线程 Worker 处理查询，带来关键优势：

提升性能：更高的吞吐量与更低的延迟

提升响应与可用性

降低总拥有成本 Total Cost of Ownership

并行与分布式数据库

并行数据库 Parallel DBMS
资源物理位置相近，通过高速互联通信，通信快速、廉价、可靠。

分布式数据库 Distributed DBMS
资源可能分布在全球，通过较慢的公网互联，通信成本高且必须考虑故障。

两者对应用程序均呈现为单一逻辑数据库。

进程模型 Process Models

定义了系统如何处理多用户并发请求。

进程每工作线程 Process per Worker
每个工作线程是独立的操作系统进程。
依赖操作系统调度，可使用共享内存或消息传递。
一个进程崩溃不会导致整个系统崩溃。
例如 IBM DB2, Postgres, Oracle。

线程每工作线程 Thread per Worker
单一进程内包含多个工作线程。
DBMS 拥有完全的调度控制权，上下文切换开销更小。
一个线程崩溃可能杀死整个数据库进程。
近 20 年的现代 DBMS 普遍采用，如 Microsoft SQL Server, MySQL。

嵌入式数据库 Embedded DBMS
数据库系统运行在应用程序的地址空间内，由应用程序负责调度。
例如 DuckDB, SQLite, RocksDB。

调度 Scheduling
DBMS 需要为每个查询计划决定在何处、何时以及如何执行，它比操作系统掌握更多信息，应优先由其决策。

查询间并行 Inter Query Parallelism

同时执行多个不同的查询。
对于只读查询，协调简单；对于更新操作，会产生复杂冲突。

查询内并行 Intra Query Parallelism

并行执行单个查询中的操作，降低长查询的延迟。
遵循生产者/消费者 Producer/Consumer范式。

intra-operator 并行（水平）
将算子分解为独立的片段 Fragment，在不同数据子集上执行相同功能。
使用交换算子 Exchange Operator 合并子算子结果：
收集 Gather：将多个工作线程的结果合并为单一输出流。
分发 Distribute：将单一输入流拆分为多个输出流。
重分区 Repartition：在多个输入流和输出流之间重新组织数据。

inter-operator 并行（垂直）
也称为流水线并行 Pipelined Parallelism，重叠算子执行，无需物化中间结果，数据直接从一阶段流入下一阶段。广泛用于流处理系统。

Bushy 并行
intra-operator 和 inter-operator 并行的混合模式，工作线程同时执行查询计划不同段的多个算子。同样使用交换算子合并中间结果。

I/O 并行

为避免磁盘成为瓶颈，将数据库拆分到多个存储设备。

多磁盘并行 Multi Disk Parallelism
通过存储设备或 RAID 配置，由操作系统/硬件将数据库文件分布到多个存储设备。对 DBMS 透明。

数据库分区 Database Partitioning
将数据库拆分为不相交的子集，分配到不同的磁盘。
可以在文件系统级别实现，对应用程序理想情况下是透明的。

Lecture #15: Query Planning & Optimization

SQL是声明式语言 Declarative Language，仅说明要计算什么，而非如何计算。

查询优化器 Query Optimizer 负责将SQL语句转换为最优的可执行查询计划 Executable Query Plan。

查询优化是DBMS中最难构建的部分。

逻辑 vs. 物理计划

逻辑计划 Logical Plan 大致对应于关系代数表达式。
物理计划 Physical Plan 定义了使用特定访问路径 Access Path 的具体执行策略。
逻辑计划与物理计划之间并非总是一一对应。

查询优化类型

基于规则的优化 Rule Based Optimization
使用静态启发式规则 Heuristics 来匹配查询模式并转换计划，无需检查数据本身。
例如谓词下推 Predicate Pushdown、投影下推 Projection Pushdown。

基于成本的优化 Cost Based Optimization
读取数据并估算等效计划的执行成本 Cost，选择成本最低的计划。

成本估算 Cost Estimations

成本模型评估的指标包括：CPU、磁盘I/O、内存、网络。
为避免穷举所有可能计划（对于n路连接有 $4^n$ 种顺序），优化器必须限制搜索空间。

统计信息 Statistics
DBMS在内部目录 Internal Catalog 中维护关于表、属性和索引的统计信息。
关键统计信息：
$N_R$：关系R中的元组数量
$V(A,R)$：属性A的不同取值数量

选择基数 Selection Cardinality

$SC(A,R)$：属性A的平均记录数，计算公式为 $\frac{N_R}{V(A,R)}$

选择性 Selectivity

谓词P的选择性 Selectivity 是满足条件的元组比例，等效于该谓词为真的概率。
复杂选择性计算依赖于三个关键假设：

均匀数据 Uniform Data：取值分布是均匀的。
独立谓词 Independent Predicates：不同属性上的谓词相互独立。
包含原则 Inclusion Principle：连接键的域相互重叠，内表中的每个键在外表中都存在。
这些假设在真实数据中常常不成立。

直方图与采样

直方图 Histograms 用于处理倾斜 skewed 数据，减少存储开销。
等宽直方图 Equi-Width Histogram：每个桶的取值区间宽度相同。
等深直方图 Equi-Depth Histogram：每个桶的总出现次数大致相同。

采样 Sampling 对具有相似分布的表的较小副本应用谓词，以估算选择性。

单关系查询计划

主要挑战是选择最佳访问方法 Access Method（顺序扫描、索引扫描等）。
OLTP查询通常是可优化查询 Sargable，存在一个可通过简单启发式规则选择的最佳索引。

多关系查询计划

随着连接数增加，可选计划数量急剧增长，必须限制搜索空间。

生成式 / 自底向上优化 Generative / Bottom up Optimization
从无到有构建计划。例如 IBM System R, Postgres。
使用动态编程确定最佳连接顺序，构建左深树 Left Deep Tree。

转换式 / 自顶向下优化 Transformation / Top down Optimization
从期望的结果开始，向下寻找最优计划。例如 Microsoft SQL Server, CockroachDB。执行分支限界搜索 Branch and Bound Search，将逻辑算子转换为物理算子。

嵌套子查询 Nested Sub Queries

DBMS将WHERE子句中的嵌套子查询视为接受参数并返回单个值或值集合的函数。

重写 Rewriting
通过解相关 De correlating 或扁平化 Flattening 将嵌套子查询重写为JOIN。

分解 Decomposition
将嵌套查询分解，将结果存储到临时表中。

表达式重写 Expression Rewriting

将查询表达式转换为最小的表达式集合。

不可能谓词 Impossible Predicates
在优化时评估表达式，消除不可能条件。

合并谓词 Merging Predicates
合并冗余的谓词范围。

Lecture #16: Concurrency Control Theory

动机

并发控制需解决两个核心问题：
丢失更新问题 Lost Update Problem (并发控制 Concurrency Control)：如何避免同时更新记录时的竞态条件。
持久性问题 Durability Problem (恢复 Recovery)：如何在发生断电等故障时确保数据库处于正确状态。

事务 Transactions

事务 Transaction 是在共享数据库上执行一个或多个操作（如SQL查询）的序列，以完成某个高级功能。它是数据库变更的基本单位，必须是原子性 Atomic的。

简易系统 Strawman System
一次只执行一个事务，通过复制整个数据库文件来实现。该方法性能低下，无法并发。

定义

数据库可表示为一组固定的命名数据对象 Data Objects。
事务 Transaction 是对这些对象的读 Read和写 Write操作序列。
事务边界由客户端定义，以BEGIN开始，以COMMIT或ABORT结束。
正确性标准由ACID准则保证。

ACID：原子性 Atomicity

保证事务中的所有操作要么全部发生，要么全部不发生。

方法一：日志记录 Logging
记录所有操作以便在事务中止时撤销 Undo。被现代系统广泛使用。

方法二：影子分页 Shadow Paging
事务修改页的副本，仅在提交时才使页面可见。运行时性能通常较差，恢复简单，实践中较少使用。

ACID：一致性 Consistency

确保数据库所代表的“世界”在逻辑上是正确的。

数据库一致性 Database Consistency：数据库准确建模现实世界并遵循完整性约束。
事务一致性 Transaction Consistency：确保事务一致性是应用程序的责任。

ACID：隔离性 Isolation

为事务提供一种幻觉 Illusion，使其感觉在系统中是单独运行的。并发执行事务的结果应与某种串行执行的结果相同。

并发控制 Concurrency Control
并发控制协议 Concurrency Control Protocol 决定如何在运行时正确交错执行多个事务的操作。

悲观并发控制 Pessimistic：假定事务会冲突，从而预先防止问题发生。之前加锁。 乐观并发控制 Optimistic：假定冲突很少发生，在提交时再处理冲突。之后修正。

执行调度 Execution Schedule
DBMS执行操作的顺序称为执行调度 Execution Schedule。目标是最大化并发的同时确保输出“正确”。

可串行化调度 Serializable Schedule：一个与某种串行执行等效的调度。

冲突 Conflict
两个操作在不同事务中，针对同一对象，且至少有一个是写操作时，发生冲突。 读-写冲突 Read Write Conflicts (“不可重复读 Unrepeatable Reads”)
写-读冲突 Write Read Conflicts (“脏读 Dirty Reads”)
写-写冲突 Write Write conflict (“丢失更新 Lost Updates”)

冲突可串行化 Conflict Serializability
两个调度是冲突等效 Conflict Equivalent的，当且仅当它们包含相同事务的相同操作，并且每对冲突操作的顺序相同。
一个调度是冲突可串行化 Conflict Serializable的，当且仅当其依赖图 Dependency Graph (优先图 Precedence Graph) 是无环的。

视图可串行化 View Serializability
一种更弱的可串行化定义，允许冲突可串行化 Conflict Serializable和盲写 Blind Writes（不先读值就直接写）。允许更多调度，但难以有效执行，实践中不常用。

调度宇宙 Universe of Schedules
串行调度 ⊂ 冲突可串行化调度 ⊂ 视图可串行化调度 ⊂ 所有调度

ACID：持久性 Durability

已提交事务的所有更改在崩溃或重启后必须是持久的 Durable。通常使用日志记录 Logging或影子分页 Shadow Paging来确保，要求更改存储在非易失性存储器 Non Volatile Memory中。

Lecture #17: Two-Phase Locking

事务锁 Transaction Locks

DBMS使用锁 Locks来动态生成可串行化 Serializable的执行调度，以保护数据库对象在并发访问时的安全。

锁 Locks 与 闩 Latches 的区别：
锁 Locks 保护数据库中的值免受并发事务影响。
闩 Latches 保护DBMS内部数据结构免受并发线程影响。

基本锁类型：
共享锁 Shared Lock (S LOCK)：允许多个事务同时读取同一对象。
排他锁 Exclusive Lock (X LOCK)：允许事务修改对象，阻止其他事务获取任何其他锁。

事务必须向锁管理器 Lock Manager请求锁，锁管理器根据当前锁的持有情况授予或阻塞请求。事务在不再需要锁时必须释放它们。

两阶段锁 Two Phase Locking

两阶段锁 2PL 是一种悲观并发控制 Pessimistic Concurrency Control协议，用于动态判断是否允许事务访问数据库中的对象。

阶段一：增长阶段 Growing Phase
事务从锁管理器请求它所需的所有锁。

阶段二：收缩阶段 Shrinking Phase
事务在释放第一个锁后进入此阶段，此阶段只允许释放锁，不允许获取新锁。

2PL本身足以保证冲突可串行化 Conflict Serializability，但它容易导致级联中止 Cascading Aborts（一个事务中止导致另一个事务必须回滚），并且仍然可能存在脏读 Dirty Reads和死锁 Deadlocks。

强严格两阶段锁 Strong Strict Two Phase Locking

也称为严谨两阶段锁 Rigorous 2PL，是2PL的一种变体，事务仅在提交时才释放所有锁。

优点：避免了级联中止，并且可以通过恢复修改元组的原始值来回滚已中止事务的更改。
缺点：生成更保守/悲观的调度，限制了并发性。

调度宇宙 Universe of Schedules
串行调度 ⊂ 强严格2PL调度 ⊂ 冲突可串行化调度 ⊂ 视图可串行化调度 ⊂ 所有调度

死锁处理 Deadlock Handling

死锁 Deadlock 是事务之间相互等待释放锁的循环。2PL中处理死锁有两种方法：检测和预防。

方法一：死锁检测 Deadlock Detection
DBMS创建一个等待图 Waits For Graph，其中节点是事务，如果事务 Ti 正在等待事务 Tj 释放锁，则存在一条从 Ti 到 Tj 的有向边。
系统定期检查等待图中是否存在环，并选择牺牲者事务 Victim Transaction来中止以打破死锁。选择牺牲者时可以考虑的属性包括：时间戳 Timestamp（新旧）、进度、已锁定的项目数量、需要随之回滚的事务数量、过去已重启的次数（避免饥饿 Starvation）。

方法二：死锁预防 Deadlock Prevention
在死锁发生之前阻止事务引起死锁。事务被分配优先级（通常基于时间戳，旧事务优先级更高）。

等待-死亡 Wait Die（“老等少”）：如果请求事务的优先级高于持有事务，则等待；否则，请求事务中止（死亡）。
伤害-等待 Wound Wait（“少等老”）：如果请求事务的优先级高于持有事务，则持有事务中止（被伤害）并释放锁；否则，请求事务等待。

锁粒度 Lock Granularities

为了在锁开销和并发度之间取得平衡，DBMS使用锁层次结构 Lock Hierarchy来处理不同粒度级别的锁。

数据库锁层次结构 Database Lock Hierarchy
数据库级 Database level（较罕见）
表级 Table level（非常常见）
页级 Page level（常见）
元组级 Tuple level（非常常见）
属性级 Attribute level（罕见）

当事务获取层次结构中某个对象的锁时，它隐式获取了其所有子对象的锁。

意向锁 Intention Locks
意向锁是隐式锁，用于表明在较低级别持有显式锁，从而避免较粗粒度的锁与较细粒度的锁冲突。

意向共享锁 Intention Shared (IS)：表示在较低级别使用共享锁进行显式锁定。
意向排他锁 Intention Exclusive (IX)：表示在较低级别使用排他锁或共享锁进行显式锁定。
共享意向排他锁 Shared Intention Exclusive (SIX)：该节点为根的子树以共享模式显式锁定，并且在较低级别正以排他模式锁进行显式锁定。

通过层次锁，当事务获取大量低级别锁时，DBMS可以自动切换到更粗粒度的锁，这减少了锁管理器必须处理的请求数量。

Lecture #18: Timestamp Ordering Concurrency Control

时间戳排序并发控制 Timestamp Ordering Concurrency Control

时间戳排序 T/O 是一类乐观并发控制 Optimistic Concurrency Control协议，它假设事务冲突很少，不使用锁，而是使用时间戳 Timestamps来确定事务的可串行化顺序 Serializable Order。

每个事务 Ti 被分配一个唯一的、单调递增的固定时间戳 TS(Ti)。如果 TS(Ti) < TS(Tj)，则DBMS必须确保执行调度等效于 Ti 在 Tj 之前出现的串行调度。

时间戳分配策略 Timestamp Allocation：可以使用系统时钟 System Clock或逻辑计数器 Logical Counter，也可使用混合方法。

乐观并发控制 Optimistic Concurrency Control

乐观并发控制 OCC 是另一种使用时间戳验证事务的乐观协议，在冲突较少时（如只读事务或访问不相交数据子集）效果最好。

OCC为每个事务创建一个私有工作空间 Private Workspace。所有修改都在此空间中进行，其他事务无法读取该空间中的更改。

OCC包含三个阶段：
读阶段 Read Phase：跟踪事务的读集 Read Set和写集 Write Set，将所有访问的元组复制到私有工作空间以确保可重复读 Repeatable Reads。 验证阶段 Validation Phase：当事务提交时，检查其是否与其他事务冲突。
写阶段 Write Phase：若验证成功，则将私有工作空间的更改应用到数据库；否则中止并重启事务。

验证阶段 Validation Phase
DBMS在事务进入验证阶段时为其分配时间戳。为确保只允许可串行化调度，DBMS检查 Ti 与其他事务的 RW 和 WW 冲突，并确保所有冲突单向发生。

前向验证 Forward Validation：检查正在提交的事务与所有其他正在运行的事务的时间戳顺序。
后向验证 Backward Validation：检查正在提交的事务与已提交事务的读/写集。

潜在问题 Potential Issues：
将数据复制到私有工作空间的开销高。
验证/写阶段可能成为瓶颈。
中止比在其他协议中更浪费，因为事务已执行完毕。
时间戳分配可能成为瓶颈。

动态数据库与幻读问题 Dynamic Databases and The Phantom Problem

当事务执行插入、更新和删除时，会出现新的复杂情况。

幻读问题 Phantom Problem：当事务只锁定现有记录，而忽略了正在创建中的记录时，会导致不可串行化的执行。

解决幻读问题的方法：
重新执行扫描 Re Execute Scans：在提交时重新运行查询以检查结果是否一致，确保没有因新记录或删除记录而遗漏更改。
谓词锁 Predicate Locking：基于查询的谓词获取锁，确保任何满足谓词的数据都不能被其他事务修改。类似精度锁 Precision Locking。
索引锁 Index Locking：利用索引键来保护数据范围，确保没有新数据可以落入锁定的范围内。
键值锁 Key Value Locks：对索引中的单个键值加锁，包括不存在值的虚拟键。
间隙锁 Gap Locks：对键值后的间隙加锁，防止在间隙中插入。
键范围锁 Key Range Locks：对从一个现有键到下一个键的范围加锁。
层次锁 Hierarchical Locking：允许事务以不同模式持有更广泛的键范围锁，减少锁管理器开销。

如果没有合适的索引，事务必须锁定表中的每一页或整个表本身以防止幻读。

隔离级别 Isolation Levels

可串行化 Serializability 允许程序员忽略并发问题，但强制执行它可能允许的并行性太少并限制性能。可以使用较弱的一致性级别来提高可扩展性。

隔离级别 Isolation Levels 控制一个事务在多大程度上暴露于其他并发事务的操作。

异常现象 Anomalies：
脏读 Dirty Read：读取未提交的数据。
不可重复读 Unrepeatable Reads：再次读取得到不同结果。
丢失更新 Lost Updates：事务覆盖另一个并发事务的数据。
幻读 Phantom Reads：插入或删除导致相同的范围扫描查询得到不同结果。

隔离级别 Isolation Levels（从强到弱）：
可串行化 SERIALIZABLE：无幻读、所有读可重复、无脏读。可能实现方式：严格两阶段锁 + 幻读保护（如索引锁）。
可重复读 REPEATABLE READS：可能出现幻读。可能实现方式：严格两阶段锁。
读已提交 READ COMMITTED：可能出现幻读、不可重复读和丢失更新。可能实现方式：排他锁使用严格两阶段锁，读后立即释放共享锁。
读未提交 READ UNCOMMITTED：所有异常都可能发生。可能实现方式：排他锁使用严格两阶段锁，读操作不加共享锁。

SQL-92标准定义的隔离级别只关注基于两阶段锁的DBMS中可能出现的异常。应用程序在开始执行查询之前设置每个事务的隔离级别。

Lecture #19: Multi-Version Concurrency Control

多版本并发控制 Multi Version Concurrency Control

多版本并发控制 MVCC 是一个比并发控制协议更广泛的概念，涉及DBMS设计和实现的各个方面，是过去十年间几乎所有新DBMS最广泛使用的方案。

MVCC为单个逻辑对象维护多个物理版本。事务写入对象时，DBMS创建该对象的新版本；事务读取对象时，读取该事务开始时存在的最新版本。

核心优势：写者不阻塞读者 Writers Do Not Block Readers，读者不阻塞写者 Readers Do Not Block Writers。

其他优势：
只读事务无需任何锁即可读取数据库的一致性快照 Snapshot。
天然支持快照隔离 Snapshot Isolation。
支持时间旅行查询 Time Travel Queries（若无垃圾回收）。

快照隔离 Snapshot Isolation

为事务提供其开始时数据库的一致性快照。快照中的数据值仅来自已提交事务，事务在完成前完全与其他事务隔离。

写冲突 Write Conflicts：若两个事务更新同一对象，先写者获胜 First Writer Wins。

写偏斜异常 Write Skew Anomaly：在快照隔离中，两个并发事务修改不同对象可能导致不可串行化的调度。

MVCC设计考量

1. 并发控制协议 Concurrency Control Protocol
在之前讨论的方法（两阶段锁、时间戳排序、乐观并发控制）之间选择。

2. 版本存储 Version Storage
DBMS如何存储逻辑对象的不同物理版本，以及事务如何找到对其可见的最新版本。

通过元组的指针字段为每个逻辑元组创建版本链 Version Chain（一个按时间戳排序的链表）。索引始终指向链的"头"（最新或最旧版本，取决于实现）。

仅追加存储 Append Only Storage
同一表空间内存储所有物理版本，更新时将新版本追加到表中并更新版本链。
旧到新 Oldest to Newest：查找需要遍历链。
新到旧 Newest to Oldest：每次新版本都需要更新索引指针（无需遍历链，通常是更好的方法）。

时间旅行存储 Time Travel Storage
维护一个单独的时间旅行表 Time Travel Table存储旧版本。每次更新时，将元组的旧版本复制到时间旅行表，并在主表中用新数据覆盖该元组。

增量存储 Delta Storage
不存储完整的旧元组，只存储增量 Deltas（元组间的更改）。事务可以通过反向遍历增量并应用它们来重建旧版本。写操作比时间旅行存储快，但读操作更慢。

3. 垃圾回收 Garbage Collection
需要移除可回收的 Reclaimable物理版本。如果一个版本没有活跃事务可以"看到"，或者它是由已中止事务创建的，则该版本可回收。

元组级垃圾回收 Tuple Level GC
后台清理 Background Vacuuming：单独的线程定期扫描表并查找可回收版本。可使用脏页位图 Dirty Page Bitmap优化。
协同清理 Cooperative Cleaning：工作线程在遍历版本链时识别可回收版本。仅适用于旧到新链。

事务级垃圾回收 Transaction Level GC
每个事务负责跟踪自己的旧版本。DBMS无需扫描元组。每个事务维护自己的读/写集。

4. 索引管理 Index Management
主键索引 Primary Key Indexes 始终指向版本链头。更新主键属性被视为删除 DELETE 后接插入 INSERT。

二级索引 Secondary Indexes 管理更复杂：
逻辑指针 Logical Pointers：使用每个元组的固定标识符，需要一个额外的间接层 Indirection Layer将逻辑ID映射到元组的物理位置。
物理指针 Physical Pointers：使用指向版本链头的物理地址。更新版本链头时需要更新每个索引，开销很大。

MVCC重复键问题 MVCC Duplicate Key Problem
MVCC DBMS索引（通常）不存储带有其键的元组的版本信息。因此，每个索引必须支持来自不同快照的重复键，因为相同的键在不同快照中可能指向不同的逻辑元组。

5. 删除操作 Deletes
只有当逻辑删除的元组的所有版本都不可见时，DBMS才会从数据库中物理删除该元组。

删除标志 Deleted Flag：维护一个标志（在元组头或单独的列中）来指示逻辑元组已被删除。
墓碑元组 Tombstone Tuple：创建一个空的物理版本来指示逻辑元组已被删除。使用单独的池存储墓碑元组以减少存储开销。

Lecture #20: Database Logging

崩溃恢复 Crash Recovery

恢复算法 Recovery Algorithms 用于在发生故障后确保数据库一致性、事务原子性和持久性。

关键原语 Key Primitives
撤销 UNDO：移除未完成或已中止事务的影响的过程。
重做 REDO：重新应用已提交事务的影响以实现持久性的过程。

缓冲池管理策略 Buffer Pool Management Policies

偷取策略 Steal Policy
允许偷取 STEAL：允许未提交事务覆盖非易失性存储中对象的最新已提交值。
禁止偷取 NO STEAL：不允许。

强制策略 Force Policy
强制 Force：要求事务的所有更新在事务被允许提交前（即向客户端返回提交消息前）反映到非易失性存储上。
非强制 NO FORCE：不要求。

策略组合
禁止偷取 + 强制 NO STEAL + FORCE：最容易实现的策略。无需撤销中止事务的更改（因为更改未写入磁盘），也无需重做已提交事务的更改（因为所有更改在提交时保证已写入磁盘）。但所有待修改数据必须能放入内存，且频繁写入可能导致存储设备磨损。

影子分页 Shadow Paging

DBMS在写入时复制页面，维护数据库的两个独立版本：
主版本 master：仅包含已提交事务的更改。
影子版本 shadow：包含未提交事务更改的临时数据库。

更新仅在影子副本中进行。当事务提交时，影子副本被原子性地切换为新的主版本。

恢复 Recovery
撤销 UNDO：移除影子页面。保留主版本和数据库根指针不变。
重做 REDO：完全不需要。

缺点 Disadvantages
复制整个页表开销大。提交开销高，需要刷新页表、根页和每个更新页，导致大量对随机非连续页的写入。导致数据碎片化。需要垃圾回收。仅支持一次一个写入事务或批处理事务。

日志文件 Journal File

事务修改页面之前，DBMS将原始页面复制到单独的日志文件中。重启后，如果存在日志文件，DBMS收集原始页面并无视性地用这些原始页面覆盖当前页面，将数据恢复到未提交事务之前的状态。

预写日志 Write Ahead Logging

DBMS在更改磁盘页面之前，将所有对数据库的更改记录到日志文件 Log File（在稳定存储上）。日志包含必要信息以在崩溃后执行撤销和重做操作来恢复数据库。

DBMS必须在将数据库对象刷新到磁盘之前，将对应于该对象更改的日志文件记录写入磁盘。

实现 Implementation
DBMS首先在易失性存储中暂存事务的所有日志记录。所有与更新页面相关的日志记录必须在页面本身被允许在非易失性存储中被覆盖之前写入非易失性存储。直到所有日志记录写入稳定存储，事务才被视为已提交。

缓冲池策略 Buffer Pool Policies
大多数DBMS采用非强制 + 偷取 NO FORCE + STEAL策略，因为它具有更优的运行时性能。但在恢复阶段，非强制要求数据库重做，偷取要求数据库撤销，因此恢复时间比强制+禁止偷取慢。

变更数据捕获 Change Data Capture
预写日志也可用于将更改传播到其他数据源。

日志方案 Logging Schemes

物理日志 Physical Logging：记录对数据库中特定位置所做的字节级更改。例如 git diff。
逻辑日志 Logical Logging：记录事务执行的高级操作。不一定局限于单个页面。每个日志记录写入的数据比物理日志少，但在非确定性并发控制方案中，存在并发事务时难以实现恢复，且恢复时间更长，因为必须重新执行每个事务。
生理日志 Physiological Logging：混合方法，日志记录针对单个页面，但不指定页面的数据组织。即，根据页面中的槽号识别元组，而不指定更改在页面中的确切位置。因此DBMS可以在日志记录写入磁盘后重新组织页面。是DBMS中最常用的方法。

检查点 Checkpoints

基于预写日志的DBMS的主要问题是日志文件会无限增长。崩溃后，DBMS必须重放整个日志，如果日志文件很大，这将花费很长时间。

DBMS可以定期设置检查点 Checkpoint，将所有缓冲区刷新到磁盘。

设置检查点的频率取决于应用程序的性能和停机时间要求。设置检查点太频繁会导致DBMS运行时性能下降。但两次检查点之间等待时间过长同样不利，因为系统重启后的恢复时间会增加。

阻塞式检查点实现 Blocking Checkpoint Implementation
DBMS停止接受新事务并等待所有活跃事务完成。
将所有当前驻留在主内存中的日志记录和脏块刷新到稳定存储。
将检查点 CHECKPOINT条目写入日志并刷新到稳定存储。
这种实现方式在设置检查点时必须停止一切以确保一致性快照，对运行时性能不利，但使恢复变得容易。

Lecture #21: Database Crash Recovery

崩溃恢复 Crash Recovery

恢复算法 Recovery Algorithms 确保在发生故障时数据库的一致性、事务的原子性和持久性。每个恢复算法包含两部分：
正常事务处理期间采取的行动，确保DBMS能够从故障中恢复。
故障发生后采取的行动，将数据库恢复到确保事务原子性、一致性和持久性的状态。

ARIES 恢复算法

利用语义进行恢复和隔离的算法 Algorithms for Recovery and Isolation Exploiting Semantics (ARIES) 是1990年代早期IBM为DB2系统开发的恢复算法。

三个核心概念 Three Key Concepts
预写日志 Write Ahead Logging：任何更改在数据库更改写入磁盘之前，都记录在稳定存储的日志中（对应 STEAL + NO-FORCE 策略）。
重做期间重演历史 Repeating History During Redo：重启时，回溯操作并将数据库恢复到崩溃前的确切状态。
撤销期间记录更改 Logging Changes During Undo：将撤销操作记录到日志，确保在发生重复故障时操作不会重复执行。

预写日志记录 WAL Records

扩展DBMS的日志记录格式，包含全局唯一的日志序列号 Log Sequence Number (LSN)。所有日志记录都有一个LSN。

关键 LSN
flushedLSN：内存中，磁盘上日志的最后一条LSN。
pageLSN：页面中，对该页面最近更新的LSN。
recLSN：脏页表 Dirty Page Table 中，自上次刷新后页面最旧更新的LSN。
lastLSN：活跃事务表 Active Transaction Table 中，事务 Ti 的最新记录（由事务管理）。
MasterRecord：磁盘上，最新检查点的LSN。

DBMS将页面 i 写入磁盘之前，必须至少将日志刷新到 pageLSNi ≤ flushedLSN 的位置。

正常执行 Normal Execution

事务提交 Transaction Commit
DBMS首先将 COMMIT 记录写入内存中的日志缓冲区。
然后将包括该事务 COMMIT 记录在内的所有日志记录刷新到磁盘。
这些日志刷新是顺序的、同步的磁盘写入。
COMMIT 记录安全存储在磁盘上后，DBMS向应用程序返回确认。
稍后，DBMS会向日志写入特殊的 TXN END 记录，表明该事务在系统中完全结束。

事务中止 Transaction Abort
中止事务是ARIES撤销操作仅应用于单个事务的特殊情况。

prevLSN 字段：对应事务的前一个LSN。DBMS使用这些值维护每个事务的链表，便于遍历日志查找其记录。

补偿日志记录 Compensation Log Record (CLR)：描述为撤销先前更新记录操作而采取的行动。包含更新日志记录的所有字段，外加 undoNextLSN 指针（即下一个要撤销的LSN）。CLR像任何其他记录一样被添加到日志中，但它们永远不需要被撤销。DBMS在通知应用程序事务已中止之前，无需等待CLR刷新到磁盘。

中止事务时，DBMS首先将 ABORT 记录附加到内存中的日志缓冲区。然后以相反顺序撤销事务的更新，从数据库中移除其影响。对于每个被撤销的更新，DBMS在日志中创建CLR条目并恢复旧值。在所有被中止事务的更新被反转后，DBMS写入 TXN END 日志记录。

检查点 Checkpointing

DBMS定期设置检查点 Checkpoint，将其缓冲池中的脏页写入磁盘。用于最小化恢复时必须重放的日志量。

非模糊检查点 Non Fuzzy Checkpoints
DBMS在设置检查点时停止事务和查询的执行，以确保它将数据库的一致性快照写入磁盘。
停止任何新事务的开始。
等待所有活跃事务执行完成。
将脏页刷新到磁盘。
影响运行时性能，但显著简化了恢复。

稍好的阻塞检查点 Slightly Better Blocking Checkpoints
DBMS在设置检查点时记录其开始时的内部系统状态。
停止任何新事务的开始。
在DBMS设置检查点时暂停事务。
记录两个关键组件：活跃事务表 Active Transaction Table (ATT) 和脏页表 Dirty Page Table (DPT)。

活跃事务表 Active Transaction Table (ATT)
跟踪DBMS中正在运行的事务。包含：
transactionId：唯一事务标识符
status：事务当前"模式"（运行中、提交中、撤销候选）
lastLSN：事务写入的最远LSN
ATT包含每个没有 TXN END 日志记录的事务。

脏页表 Dirty Page Table (DPT)
包含缓冲池中被未提交事务修改的页面的信息。每个脏页有一个条目，包含 recLSN（即首次导致页面变脏的日志记录的LSN）。
DPT包含缓冲池中所有脏页。

模糊检查点 Fuzzy Checkpoints
DBMS允许其他事务继续运行。这是ARIES在其协议中使用的。
DBMS使用额外的日志记录来跟踪检查点边界：
检查点开始 CHECKPOINT BEGIN：指示检查点的开始。此时DBMS获取当前ATT和DPT的快照。
检查点结束 CHECKPOINT END：当检查点完成时。包含在写入 CHECKPOINT BEGIN 日志记录时捕获的ATT + DPT。
检查点完成后，CHECKPOINT BEGIN 记录的LSN被记录在 MasterRecord 中。

ARIES 恢复 ARIES Recovery

崩溃后启动时，DBMS将执行以下三个阶段：

分析阶段 Analysis Phase
从通过数据库 MasterRecord LSN 找到的最后一个检查点开始。
向前扫描日志从检查点开始。
如果DBMS找到 TXN END 记录，则从事务表ATT中移除其事务。
所有其他记录，将事务添加到ATT，状态为 UNDO，提交时，将事务状态更改为 COMMIT。
对于 UPDATE 日志记录，如果页面 P 不在 DPT 中，则将 P 添加到 DPT 并将 P 的 recLSN 设置为该日志记录的LSN。

重做阶段 Redo Phase
目标是DBMS重演历史 Repeating History，以重建其到崩溃时刻的状态。它将重新应用所有更新（甚至是已中止的事务）并重做CLR。
DBMS从包含 DPT 中最小 recLSN 的日志记录开始向前扫描。
对于每个具有给定LSN的更新日志记录或CLR，DBMS重新应用更新，除非：
受影响页面不在 DPT 中，或
受影响页面在 DPT 中，但该日志记录的LSN小于页面的 recLSN（更新已传播到磁盘），或
受影响页面的 pageLSN（在磁盘上）≥ LSN。
重做操作时，DBMS重新应用日志记录中的更改，然后将受影响页面的 pageLSN 设置为该日志记录的LSN。没有额外的日志记录或强制刷新。
在重做阶段结束时，为所有状态为 COMMIT 的事务写入 TXN END 日志记录，并将它们从ATT中移除。

撤销阶段 Undo Phase
DBMS反转所有在崩溃时处于活跃状态的事务。这些是在分析阶段后ATT中状态为 UNDO 的所有事务。
DBMS使用 lastLSN 以反向LSN顺序处理事务，以加速遍历。在每个步骤中，选择ATT中所有事务中最大的 lastLSN。当它反转事务的更新时，DBMS为每个修改写入一个CLR条目到日志中。
一旦最后一个事务被成功中止，DBMS将日志刷新出去，然后准备开始处理新事务。

崩溃问题 Crash Issues
如果在恢复的分析阶段数据库崩溃，则再次运行恢复。
如果在恢复的重做阶段数据库崩溃，则再次重做所有操作。
为了提高在重做阶段恢复期间的性能，假设它不会再次崩溃，并在后台异步刷新所有更改到磁盘。
为了提高在撤销阶段恢复期间的性能，在新事务访问页面之前延迟回滚更改，并重写应用程序以避免长时间运行的事务。

Lecture #22: Introduction to Distributed Databases

分布式数据库系统 Distributed DBMSs

分布式DBMS将单个逻辑数据库划分到多个物理资源上。应用程序（通常）不知道数据在分离的硬件上被拆分。系统依赖单节点DBMS的技术和算法来支持分布式环境中的事务处理和查询执行。一个重要设计目标是容错性 Fault Tolerance。

并行数据库 Parallel Database 与 分布式数据库 Distributed Database 的区别：
并行数据库：节点物理位置相近，通过高速LAN互联，通信成本低且可靠，设计协议时无需过多考虑节点崩溃或丢包。
分布式数据库：节点可能相距甚远，通过可能缓慢且不可靠的公网互联，通信成本和连接问题不可忽略（节点会崩溃，数据包会丢失）。

系统架构 System Architectures

无共享 Shared Nothing
每个节点拥有自己的CPU、内存和磁盘。节点仅通过网络进行通信。
增加容量更困难，因为DBMS必须将数据物理移动到新节点。确保所有节点一致性也更困难。
优势是潜在性能更好、效率更高。

共享磁盘 Shared Disk
所有CPU可以通过互联直接读写单个逻辑磁盘，但各自拥有私有内存。每个计算节点的本地存储可作为缓存。在基于云的DBMS中更常见。
执行层可以与存储层独立扩展。添加新存储节点或执行节点不会影响另一层中数据的布局或位置。
节点必须相互发送消息以了解其他节点的当前状态。节点拥有自己的缓冲池，被认为是无状态的。

共享内存 Shared Memory
CPU通过高速互联访问公共内存地址空间。CPU也共享同一个磁盘。
每个处理器对所有内存中的数据结构具有全局视图。每个处理器上的DBMS实例必须“知道”其他实例。
实践中大多数DBMS不使用此架构，因为它是在操作系统/内核级别提供的，并且会导致问题。

设计问题 Design Issues

分布式DBMS旨在维护数据透明性 Data Transparency，意味着用户不应需要知道数据的物理位置，或表是如何分区或复制的。数据存储的细节对应用程序是隐藏的。一个在单节点DBMS上工作的SQL查询在分布式DBMS上应该同样工作。

关键设计问题：
应用程序如何找到数据？
查询应如何在分布式数据上执行？应将查询推送到数据所在位置，还是应将数据汇集到公共位置执行查询？
数据库应如何跨资源划分？
DBMS如何确保正确性？

分区方案 Partitioning Schemes

分布式系统必须将数据库跨多个资源（包括磁盘、节点、处理器）进行分区 Partitioning。在NoSQL系统中此过程有时称为分片 Sharding。

分区方案的目标是最大化单节点事务 Single Node Transactions（仅访问一个分区内数据的事务），这使得DBMS无需协调在其他节点上运行的并发事务的行为。而分布式事务 Distributed Transaction 访问一个或多个分区中的数据，这需要昂贵且困难的协调。

实现方式 Implementation
简单数据分区 Naive Data Partitioning：每个节点存储一个表。易于实现，但不可扩展，在跨表连接查询或存在非均匀访问模式时效果不佳。
垂直分区 Vertical Partitioning：将表的属性拆分到不同的分区中。每个分区还必须存储用于重建原始记录的元组信息。
水平分区 Horizontal Partitioning：将表的元组拆分为不相交的子集。选择能在大小、负载或使用情况上平均划分数据库的列，这些键称为分区键 Partitioning Key。

DBMS可以基于哈希 Hashing、数据范围 Data Ranges 或谓词 Predicates 进行物理分区（无共享）或逻辑分区（共享磁盘）。

一致性哈希 Consistent Hashing
将每个节点分配到某个逻辑环上的一个位置。然后每个分区键的哈希值映射到环上的一个位置。顺时针方向上最接近该键的节点负责该键。
当添加或移除节点时，键仅在相邻节点之间移动，因此只有 1/n 的键被移动。
复制因子 Replication Factor 为 k 意味着每个键在顺时针方向的 k 个最近节点处被复制。

逻辑分区 Logical Partitioning：节点负责一组键，但并不实际存储这些键。常用于共享磁盘架构。
物理分区 Physical Partitioning：节点负责一组键，并物理存储这些键。常用于无共享架构。

分布式并发控制 Distributed Concurrency Control

分布式事务访问一个或多个分区中的数据，这需要昂贵的协调。

集中式协调器 Centralized Coordinator
充当全局“交通警察”，协调所有行为。客户端与协调器通信以获取其想要访问的分区上的锁。收到确认后，客户端将其查询发送到这些分区。给定事务的所有查询完成后，客户端向协调器发送提交请求。然后协调器与事务涉及的分区通信以确定是否允许事务提交。
集中式协调器可用作中间件 Middleware，接受查询请求并将查询路由到正确的分区。
集中式方法在多个客户端尝试获取相同分区上的锁时会产生瓶颈，但对于分布式两阶段锁，它拥有锁的中央视图，可以更快地处理死锁。

去中心化协调器 Decentralized Coordinator
节点自行组织。客户端直接将查询发送到其中一个分区。这个主分区 Home Partition 将结果返回给客户端，并负责与其他分区通信并相应提交。

联邦数据库 Federated Databases

这是一种将多个DBMS连接成单个逻辑系统的分布式架构。在大型公司中更流行。
查询可以访问任何位置的数据。这很困难，因为存在不同的数据模型、查询语言以及每个独立DBMS的限制。此外，没有简单的方法来优化查询，并且涉及大量数据复制。
通常通过一个中间件 Middleware 层来实现，该层将查询转换为系统中使用的特定DBMS可读的格式，并通过连接器与多个后端DBMS交互，然后处理从DBMS返回的结果。

Lecture #23: Distributed OLTP Databases

OLTP 与 OLAP

联机事务处理 On line Transaction Processing (OLTP)
短生存期的读写事务
小数据足迹
重复性操作

联机分析处理 On line Analytical Processing (OLAP)
长时间运行的只读查询
复杂连接
探索性查询

去中心化协调器设置 Decentralized Coordinator Setup

基本场景包含一个应用服务器和多个数据分区。其中一个分区被选为主节点 Primary Node。
事务的开始请求从应用服务器发送到主节点，查询则直接发送到各个节点。
提交请求从应用服务器发送到主节点，主节点负责在所有参与节点间协调是否允许提交。
使用两阶段锁 2PL、多版本并发控制 MVCC、乐观并发控制 OCC 等策略来判断事务是否能在每个节点上安全提交。

复制 Replication

DBMS跨冗余节点复制数据以提高可用性。

设计决策 Design Decisions
副本配置 Replica Configuration
传播方案 Propagation Scheme
传播时序 Propagation Timing
更新方法 Update Method

副本配置 Replica Configurations
主从复制 Primary Replica：所有更新都发送到每个对象的指定主节点。主节点将更新传播到其副本，无需原子提交协议。如果不需要最新信息，只读事务可以访问副本。如果主节点宕机，则举行选举选出新的主节点。
多主复制 Multi Primary：事务可以在任何副本更新数据对象。副本必须使用原子提交协议相互同步。

K安全 K safety：确定复制数据库容错能力的阈值。K值表示每个数据对象必须始终可用的副本数量。如果副本数量低于此阈值，则DBMS停止执行并自行脱机。较高的K值可降低数据丢失风险。

传播方案 Propagation Scheme
同步 Synchronous（强一致性）：主节点将更新发送到副本，然后等待它们确认已完全应用更改。然后主节点可以通知客户端更新已成功。确保DBMS不会因强一致性而丢失任何数据。在传统DBMS中更常见。
异步 Asynchronous（最终一致性）：主节点立即向客户端返回确认，而无需等待副本应用更改。此方法中可能发生陈旧读取 Stale Reads。如果可以容忍某些数据丢失，此选项是一种可行的优化。常用于NoSQL系统。

传播时序 Propagation Timing
连续传播 Continuous Propagation：DBMS在生成日志消息时立即发送。注意提交和中止消息也需要发送。大多数系统使用此方法。
提交时传播 On Commit Propagation：DBMS仅在事务提交后才将事务的日志消息发送到副本。这不会浪费时间为中止的事务发送日志记录。它假设事务的日志记录完全适合内存。

主动 vs 被动 Active vs Passive
主动-主动 Active Active：事务在每个副本上独立执行。最后，DBMS需要检查事务在每个副本上是否以相同结果结束，以查看副本是否正确提交。这很困难，因为现在事务的排序必须在所有节点之间同步，因此不太常见。
主动-被动 Active Passive：每个事务在单个位置执行，并将整体更改传播到副本。DBMS可以发送更改的物理字节（更常见）或逻辑SQL查询。大多数系统是主动-被动。

原子提交协议 Atomic Commit Protocols

当多节点事务完成时，DBMS需要询问所有涉及的节点是否可以安全提交。根据协议，可能需要多数节点或所有节点同意才能提交。

所有原子提交协议都有一个共同结构。它们通常有资源管理器 Resource Managers (RMs) 的概念，这些RMs在不同节点上管理资源数据库。RMs需要共同协调以决定每个事务的命运：提交或中止。

原子提交协议需要保证以下属性：
稳定性 Stability：一旦事务的命运被决定，就不能改变。
一致性 Consistency：所有RMs最终处于相同状态，即使在故障之后。
活跃性 Liveness：协议总有某种方式向前推进。

两阶段提交 Two Phase Commit
客户端向协调器发送提交请求。
第一阶段：协调器发送准备 Prepare消息，询问参与者节点当前事务是否允许提交。如果参与者验证事务有效，则向协调器发送同意 OK。如果协调器从所有参与者收到同意，系统进入第二阶段。如果有人向协调器发送中止 Abort，协调器则向客户端发送中止。
第二阶段：如果所有参与者都发送了同意，协调器向所有参与者发送提交 Commit，告诉这些节点提交事务。一旦参与者响应同意，协调器可以告诉客户端事务已提交。
如果事务在第一阶段被中止，参与者会从协调器收到中止，并应响应同意。
要么所有人都提交，要么没有人提交。协调器也可以是系统中的参与者。
在崩溃情况下，所有节点都会跟踪每个阶段结果的非易失性日志。节点会阻塞，直到能确定下一步行动。

优化 Optimizations
早期准备投票 Early Prepare Voting：如果DBMS向一个远程节点发送查询，并且知道这将是该节点执行的最后一个查询，那么该节点将在查询结果中同时返回其对准备阶段的投票。
准备后早期确认 Early Acknowledgement after Prepare：如果所有节点都投票提交事务，协调器可以在提交阶段完成之前向客户端发送事务成功的确认。

Paxos
Paxos（以及Raft）在现代系统中比2PC更普遍。2PC是Paxos的一种退化情况；Paxos使用 2F + 1 个协调器，只要至少 F + 1 个协调器正常工作就能取得进展，而2PC设置 F = 0。

Paxos是一种共识协议，协调器提出一个结果，然后参与者对该结果是否应该成功进行投票。如果大多数参与者可用，该协议不会阻塞，并且在最佳情况下具有可证明的最小消息延迟。

对于Paxos，协调器称为提议者 Proposer，参与者称为接受者 Acceptors。

Multi Paxos：如果系统选举一个单一领导者在一段时间内监督提议更改，那么它可以跳过提议阶段。系统使用另一轮Paxos定期更新领导者是谁。当发生故障时，DBMS可以回退到完整的Paxos。

CAP 定理

CAP定理指出，分布式系统不可能同时始终保证一致性 Consistency、可用性 Availability 和分区容错性 Partition Tolerance。只能选择这三者中的两个。

一致性 Consistency 等同于所有节点上操作的线性一致性 Linearizability。
可用性 Availability 是所有处于运行状态的节点都能满足所有请求的概念。
分区容错性 Partition Tolerance 意味着系统在节点之间就值达成共识时出现某些消息丢失的情况下仍能正确运行。

如果为系统选择了一致性和分区容错性，则在大多数节点重新连接之前不允许更新，通常在传统或NewSQL DBMS中完成。

PACELC 定理 是现代版本，考虑了一致性 vs 延迟 Consistency vs Latency 的权衡：在分布式系统中出现网络分区的情况下，必须在可用性和一致性之间做出选择，否则，即使系统在没有网络分区的情况下正常运行，也必须在延迟和一致性之间做出选择。

Lecture #24: Distributed OLAP Databases

决策支持系统 Decision Support Systems

数据仓库 Data Warehouse 是一种后端OLAP数据库，用于存储和分析历史数据。
ETL 是一个中间步骤，代表提取、转换、加载 Extract, Transform, and Load，将OLTP数据库组合成数据仓库的通用模式。
ELT 是一种现代趋势，代表提取、加载、转换 Extract, Load, and Transform，原始数据加载到OLAP数据库后，转换工作在OLAP数据库本身上完成。

决策支持系统 Decision Support Systems 通过分析数据仓库中存储的历史数据，帮助人们对未来的问题和事务做出决策。

星型模式 Star Schema
包含两种类型的表：事实表 Fact Tables 和维度表 Dimension Tables。
事实表包含应用程序中发生的多个"事件"，包含每个事件的最小唯一信息，其余属性是对外部维度表的外键引用。
维度表包含在多个事件中重复使用的冗余信息。
星型模式中只能有一层维度表，查询通常更快，因为连接更少。

雪花模式 Snowflake Schema
与星型模式类似，但允许从事实表引出多个维度，有时包含多个事实表。
冗余较少，占用存储空间更小，但查询需要更多连接，因此查询通常比星型模式慢。

执行模型 Execution Models

分布式DBMS的执行模型指定了在查询执行期间节点之间如何通信。

将查询推送到数据 Pushing a Query to Data
DBMS将查询（或其中一部分）发送到包含数据的节点。它在数据驻留的位置执行尽可能多的过滤和处理，以最小化昂贵的数据传输。然后将结果发送回执行查询的位置。在无共享 Shared Nothing 系统中更常见。

将数据拉取到查询 Pulling Data to Query
DBMS将数据带到执行查询所需的节点。换句话说，节点检测它们可以对哪些数据分区进行计算，并相应地从存储中拉取数据。然后，本地操作传播到一个节点，该节点对所有中间结果执行操作。通常是共享磁盘 Shared Disk 系统会这样做。

查询容错 Query Fault Tolerance
大多数无共享分布式OLAP DBMS设计为假设节点在查询执行期间不会发生故障。如果一个节点在查询执行期间发生故障，则整个查询失败，迫使整个查询从头开始重新执行。
DBMS可以在执行期间对查询的中间结果进行快照 Snapshot，以便在节点发生故障时恢复，但此操作开销很大。

查询计划 Query Planning

分布式查询优化更加困难，因为它必须考虑集群中数据的物理位置和数据移动成本 Data Movement Costs。

查询计划片段 Query Plan Fragments
生成单个全局查询计划，然后将物理算子分发到节点，将其分解为特定于分区的片段。大多数系统实现此方法。
另一种方法是将SQL查询重写为特定于分区的查询。这允许在每个节点进行本地优化。

分布式连接算法 Distributed Join Algorithms

对于分析工作负载，大部分时间花在连接和从磁盘读取上。

场景1：一个表在每个节点复制，另一个表跨节点分区。每个节点并行连接其本地数据，然后将结果发送到协调节点。

场景2：两个表都在连接属性上分区，ID在每个节点上匹配。每个节点对本地数据执行连接，然后发送到一个节点进行合并。

场景3：两个表在不同键上分区。如果其中一个表很小，则DBMS将该表广播 Broadcast 到所有节点。这回到场景1。本地连接被计算，然后这些连接被发送到一个公共节点以执行最终连接。这称为广播连接 Broadcast Join。

场景4：最坏情况。两个表都没有在连接键上分区。DBMS通过跨节点重新洗牌 Reshuffling 来复制表。本地连接被计算，然后结果被发送到一个公共节点进行最终连接。这称为洗牌连接 Shuffle Join。

半连接 Semi Join
一种连接算子，结果仅包含左表的列。分布式DBMS使用半连接来最小化连接期间发送的数据量。

云系统 Cloud Systems

供应商提供数据库即服务 Database as a Service 产品，即托管的DBMS环境。

托管式DBMS Managed DBMS
没有对DBMS进行重大修改以使其"感知"它在云环境中运行。它为客户端提供了一种抽象所有备份和恢复的方法。大多数供应商部署此方法。

云原生DBMS Cloud Native DBMS
明确设计用于在云环境中运行的系统。通常基于共享磁盘架构。例如 Snowflake, Google BigQuery, Amazon Redshift, Microsoft SQL Azure。

无服务器数据库 Serverless Databases
当客户变得空闲时，无服务器DBMS Serverless DBMS 会驱逐租户，将系统中的当前进度设置检查点 Checkpointing 到磁盘。当不主动查询时，用户只需为存储付费。

数据湖 Data Lakes
一个集中式存储库，用于存储大量结构化、半结构化和非结构化数据，而无需定义模式或将数据摄取到专有内部格式中。数据湖通常在摄取数据时更快，因为它们不需要立即进行转换。但它们需要用户编写自己的转换管道。

OLAP 商品化 OLAP Commoditization

近十年的一个趋势是将OLAP引擎子系统拆分为独立的开源组件。

系统目录 System Catalogs
DBMS在其目录中跟踪数据库的模式和数据文件。 Notable examples: HCatalog, Google Data Catalog, Amazon Glue Data Catalog。

查询优化器 Query Optimizers
用于基于启发式和成本的查询优化的可扩展搜索引擎框架。 Notable examples: Greenplum Orca, Apache Calcite。

数据文件格式 Data File Formats
新的开源二进制文件格式，使跨系统访问数据更容易。 Notable examples: Apache Parquet, Apache ORC, Apache CarbonData, Apache Iceberg, HDF5, Apache Arrow。

执行引擎 Execution Engines
用于在列式数据上执行向量化查询算子的独立库。 Notable examples: Velox, DataFusion, Intel OAP。

千恋万花 Senrenbanka 玩后感

Mon, 10 Nov 2025 04:56:40 +0000

2025.11.08

花六小时玩了芳乃线，打完也去看其他说明，了解了下其他线的故事。

剧情确实白开水，一开始兴致勃勃、后面也变成「我知道就是一段无所谓的日常」的样子，失去耐心；没有对特别高潮剧情导致音乐在我这也没什么记忆点，平平无奇吧。

虽然，带些伏笔、收回，但是还是小打小闹，再加上太多无所谓的日常，进一步消解。

首先男主对话里时不时加着色色心理描写，实在呃呃了。

进角色个人线后，特别是后半段，怎么就是男女主都是在疯狂发情，无趣。（不知道其他线是怎么样）

然后，进入个人线后，其他角色永远都是助攻，不干自己情感的事，用大家的形容就是，美美「神隐」，更让剧情无聊。

感觉在原本的骨架上可以交织一起，形成更有趣的展开的，不过就变成加长版、角色之间有点点关系的 mirror。

唉，没有冲突就是不精彩吧。

虽然如此，我中间还是几度觉得它如果能做成番剧，搭配上Q版的表现，其实会是部不错的萌萌番吧（？）

传说之下 Undertale 玩后感

Tue, 04 Nov 2025 07:54:07 +0000

很早就有所听闻的游戏，“狂妄之人”的 BGM 已经在很多地方听过。（不过因为我只打一周目，实际自己玩没有遇到这个 BGM 呢，哈哈哈）

神作，一周目来看，也是足够 9 / 10 的游戏，一周目能够体验到的如音乐、设定等就已经够让他称为极佳的作品。

不过由于我不太有刷多周目的习惯（当然，如果能比较快的给出不同线中的区别的可能还好），所以，我 345:16 分钟的一周目后，我便转头看其他结局，和游戏的其他细节，不过涉及其他彩蛋的，我还没有过多了解。

具体地，这位 UP 主的视频很不错，heya 0 , heya 1 , heya 2 ，看完从他的 ID 大约也是出自 UT (Undertale) 的？非常热爱了。

多周目的结局，特别是对于第四面墙的打破，存档，时间线，每一个人物都表现得栩栩如生的对不同行为的不同反应，是把这款游戏能推到 10 / 10 的绝对助力。

我也录下来我的游玩过程，当然，说话声音可能小，可能无聊，总之是录下来了。

这几天就也会上传吧，实况。

吐槽无法拉伸的小小窗口，不过录像刚好又能借用监控录像的画面。

然后，确实确实，小花之类的有些画面还是有些邪典感觉的，有些呃呃，不过不会影响他是神作。

ISPC 的故事

Wed, 08 Oct 2025 17:13:55 +0000

封面来源：@sesmkun

原文来自 The story of ispc: all the links ，叙述深入浅出，写得很有意思。简述提取了笔者觉得比较核心的观点。

简述

起源

Larrabee（LRB）的失败。

自动向量化不是一种编程模型

自动向量化可能而且确实会失败，使用它的程序员需要深入理解自动向量化编译器，需要去关心为什么代码没有成功向量化，而编译器版本一更新，生成的代码又是不可预测的了。

只考虑外层循环向量化，忽略内层的会存在的程序实例之间通信的情况，决定了注定做不好。

SPMD 编程模型

编程模型的存在，是为了更好地把程序映射到硬件上。

volta 诞生 & 全力投入 volta

主要其实是在指出 Intel 存在的弊病，大公司高度政治化的环境，抨击技术上贡献寥寥，但在政治上投入很多的蛀虫。

C 语言的影响及在 SIMD 上实现 SPMD

volta / ispc 遵循了 C 的设计哲学。

编译器优化与转换

为 SIMD 硬件编译 SPMD 程序是一种编译器转换，这与编译器优化完全是两回事。

增加几步掩码的操作，可能会带来性能的损耗，但是它的结果是确定的，它的方法是通用的，这种转化，使得它的可用性提高。

初步基准测试结果

volta 结合来自 GPU 的编程模型与 LLVM 得到的初版，丝毫不逊色于其他团队专家反复优化的编译器。

又继续抨击内部团队政治斗争。

首批用户与现代 CPU 的到来

在内部并行编程模型比拼中，对于性能上的领先，作者更加专注于开始将它用于更复杂的、其他模型无法处理的程序。

有分叉控制流，当时还不被支持为向量指令的操作等，带来的开销，但能更快？

乱序执行掩盖了大量的瑕疵。英特尔 CPU 非常擅长运行糟糕的代码。

构建 AVX 后端及回馈 LLVM

自动向量化器处理的代码，由于 AVX 的出现，会需要把用 SSE 内部函数编写的代码用 AVX 的内部函数重写，这样的反复显然吃力不讨好。

完善 volta 支持 AVX 的时候，反哺 LLVM。

关于优化和性能的更多内容

GPU 能够在运行时获取如 gather 或 scatter 的相干性情况，而 CPU 需要在编译的时候尽量搞清楚。

对显著影响性能的情况，引入适当的情况判别优化，尽量不伤害程序的可预测性。

开源发布与 volta 的终结

作者全然是为了 volta 才留在 Intel，不同意开源后，立刻决定提交辞呈。最终，RIP volta, ispc 长存，Intel SPMD Program Compiler，参半的结局。

保留提交信息，虽然会把有些尴尬的探索公之于众，但能留下更多历史细节吧。

传播理念与离开英特尔

InPar 与英伟达的 GTC 大会同期举行，这意味着会议重点 heavily 偏向 GPU。说到"重点 heavily 偏向 GPU"，我的意思是我们的论文是唯一一篇关于 CPU 的。然而，在听众的大力支持下，我们赢得了最佳论文奖。我们的奖品是一块顶级的英伟达 GPU。

显得幽默了。

在演讲后的问答环节中，一位研究生坚持认为，我在结果中报告的在一台 40 核机器上实现的 180 倍加速纯粹归功于多线程，我怎么确定 SIMD 起了任何作用？而且，据他说，现在没有一个有趣的工作负载不是大规模并行且能在 GPU 上运行良好的，因此让东西在 CPU 上跑得快并没有什么意义。

我其实当时了解到 ISPC 出来比 CUDA 晚的时候，有类似的疑惑，能在 GPU / CUDA 上做得更加彻底，所以这意义到底有多大呢？

继续提到为了防止 ISPC 死于职场政治斗争的个人努力，不进一步正规化。

于是，我辞职了，那次是认真的。当我解释原因时——正是他批准了我最初请求的人员编制，让我意识到是时候离开了——Geoff 有点惊讶，但他表现得非常冷静，令人佩服。

这看起来非常反直觉，但又是自然的。

回顾与反思

设计一个东西来解决你自己的问题可能很危险：最坏的情况是，它对其他任何人都没用。但这总比设计一个对你没用、但你想象别人会想要的东西要好。

然后是作者认为的 ISPC 的不足：侧重于 32 位数据类型、每个源文件固定一个 SIMD 向量宽度、unmasked 关键字、显式向量与 SPMD、嵌入 C++。

最后是变扭的，由于公司利益被拒绝的 PR。（~~虽然最后 Jean-Luc 以他的提交权限为代价，合入了~~）

后记

Excellence withers without an adversary: the time for us to see how great it is, how much its force, is when it displays its power through endurance. I assure you, good men should do the same: they should not be afraid to face hardships and difficulties, or complain of fate; whatever happens, good men should take it on good part, and turn it to a good end; it is not what you endure that matters, but how you endure it.

— Seneca, On Providence

我是否会在一个没有几个我一心想要证明他们是错的、且颇具影响力的混蛋的环境中写出它？

我并不认为混蛋是进步的必要因素，但我忍不住去想，最终他们是否以其特有的方式为 ispc 做出了"贡献"。

这里就只是作者的一些哲思了。

附录（原文 AI 翻译）

以下中文版由 DeepSeek 翻译。

ispc 的故事：起源（第一部分）

我决定写下一些关于 ispc 的历史，这是我在英特尔时写的一个编译器。要说的东西很多，所以会在接下来几周里分成一系列文章发布。虽然我尽力确保所有细节准确并恰当地归功于相关人员，但这都是凭我的记忆所写。如果当时在场的任何人发现任何事实错误，请发邮件告知。

Larrabee 的挽歌
要理解 ispc 的起源，了解一点关于 Larrabee 的知识会有所帮助。Larrabee（LRB）是英特尔尝试构建高端 GPU 的项目。这个项目大致时间跨度是从 2005 年到 2010 年。在多年来图形处理器一直只能使用落后的半导体工艺线和极小的芯片面积之后，英特尔打算用 Larrabee 大干一场：推出基于 PCI-Express 卡的 GPU，采用领先的半导体工艺，真正在高端市场参与竞争，目标是能够与 AMD 和 NVIDIA 抗衡。

英特尔的高管们爱上了 Larrabee，因为它基于 x86 架构。“看，x86 什么都能做！我们不需要构建某种奇怪的 GPU 架构就能在图形领域取得成功。“我敢肯定他们都是这么告诉自己的。这是一个诱人的提议，表面上看也似乎合理。只需在每个核心上增加一个大的向量单元，增加一些纹理单元，让某个程序员写点代码，然后接下来你就知道，你就在销售更多高利润的芯片，同时还能打击 NVIDIA 和他们的 GPU 计算野心。（而且 LRB 的想法在相当长一段时间里对我来说也似乎很合理，尽管我对指令集和 CPU 架构的文化性依恋不像公司里其他人那么深。）

Larrabee 未能成功的原因有很多，也许我以后会写点东西谈谈我对此的看法。（与此同时，Tom Forsyth 就他对此主题的看法写了一篇不错的文章，值得一读。）

其中一个主要问题是，每个核心上都有一个 16 宽的向量单元，但除了专门为 DX 和 OpenGL 编写的着色器编译器之外，没有其他好的方法来编写实际使用该向量单元的代码。如果你没有点亮向量单元，那么你只发挥了 Larrabee 潜在性能的 1/16；在那种情况下，你还不如在数量更少、但主频更高、具有乱序执行、更大缓存等特性的常规 CPU 核心上运行。

我曾多次看到一位 LRB 硬件架构师出去告诉开发人员，LRB 非常棒，因为他们可以像往常一样用 C 语言编程，只需重新编译他们已有的代码，就能获得数 TFLOP 的性能。

我们都会试图向那些相信只需重新编译就行的硬件架构师解释，事情没那么简单，没错，尽管多线程编程已被程序员们很好地理解，但你仍然需要为向量单元做点什么，老实说，在这方面当时一无所有。通常的回应是对方略带茫然地点头同意——好吧，也许没那么简单，但实际能有多难呢？这与许多软件人员开始感到的恐慌形成了鲜明的对比。

总的来说，英特尔的硬件架构师对编程的了解少得惊人（Forsyth 那家伙除外），而且我确信那些持这种想法的人真的相信如此。（公平地说，我对实际做硬件架构也知之甚少，不过我想我不会出去对硬件架构师胡扯如何最好地实现分支预测器。）

英特尔的编译器团队向硬件架构师保证，一切尽在掌握。他们拥有业界最好的循环向量化器——一旦他们为 LRB 写好新的后端，我们就万事大吉了。C、C++，甚至 Fortran 程序员将能够轻松点亮那 16 个向量通道，甚至无需思考。（只是为了校准一下：英特尔拥有业界最好的 Fortran 编译器也是他们引以为傲的一点。）

也有少数人对编写内部函数（intrinsics）感到兴奋——Mike Abrash 和 RAD 的其他优秀程序员正在编写光栅化器，他们几乎只想要这个，而 Tim Sweeney 也对这种可能性垂涎欲滴。我想，他们如此青睐内部函数选项这一事实，让硬件架构师觉得我们这些敲警钟的人只是水平不高的程序员，因此不值得担心。（澄清一下，与 Mike Abrash 和 Tim Sweeney 相比，我是个蹩脚的程序员。）但我谦卑地建议，构建一个世界上只有 5 个人能编程的可编程硬件，可不是一个制胜策略。

最终，并非向量单元编译器的缺失注定了 LRB 的失败：硬件延期了，软件光栅化器也延期了，而且整个项目遭遇了市场转向，即能效比几年前重要得多——消费者需要移动和电池供电的计算设备，而 LRB 架构的能效低于传统的 GPU 架构。

所以 LRB 走到了尽头，但至少我们现在在（部分）CPU 上有了 AVX-512。不过，从 LRB 的经历中，我们当时在场的很多人都清楚地认识到，这个向量单元的问题是一个需要解决的重要问题，即使只是为了 CPU，因为通过 SIMD 可用的处理能力越来越多。

让我们与编译器团队一起解决这个问题！
长期以来，由于专注于为执行密集矩阵数学的常规循环生成优秀代码，英特尔编译器团队的大多数人否认除了他们的自动向量化器之外还需要任何其他东西来处理向量单元的利用问题。我们很快陷入了一个循环：

他们会通知图形部门的人，他们已经根据我们的要求改进了自动向量化器，并且它实现了我们要求的所有功能。
我们尝试使用，发现虽然有所改善，但天哪，很容易写出实际上没有被编译成向量代码的代码——它会不可预测地失败。
我们给他们提供失败的案例，几个月后，他们会通知我们最新版本已经解决了问题。
如此周而复始。

很容易就会偏离向量化的路径。他们起初试图修补，但最终他们举手投降，提出了 #pragma simd，这个指令会禁用自动向量化器中"向量化此循环是否安全"的检查，无论如何都会对后面的循环进行向量化。（一旦提出用 #pragma 来解决难题，你就知道情况不妙了。）

于是有了 #pragma simd，它算是有点用，除非你调用了外部函数；那个问题从未得到解决。他们始终不理解为什么会有人想要编写完全使用所有向量通道运行的大型系统，并且无法想象这是一个重要的用例。（细心的读者可能会意识到，这种执行模型精确地描述了 GPU。）

自动向量化不是一种编程模型
我认为，编译器团队试图使其方法奏效的根本缺陷，最好由 T. Foley 诊断出来，他对此类问题充满了深刻的见解：自动向量化不是一种编程模型。

自动向量化器的问题在于，只要向量化可能失败（而且它确实会失败），那么如果你是一个真正关心编译器为你的程序生成什么代码的程序员，你就必须深入理解这个自动向量化器。然后，当它未能将你希望向量化的代码向量化时，你可以要么用正确的方式"戳"它，要么以正确的方式修改你的程序，让它重新为你工作。这是一种糟糕的编程方式；这完全是炼金术和猜测，你需要对单个编译器实现的细微之处变得非常专业——而这本来是你完全不需要关心的事情。

当编译器新版本发布并更改了自动向量化器的实现时，愿上帝保佑你。

而有了合适的编程模型，程序员学习这个模型（希望它相当清晰），一个或多个编译器实现它，生成的代码是可预测的（没有性能悬崖），大家皆大欢喜。

在这个过程中，英特尔的许多图形人员试图向编译器团队的人解释，GPU 编程模型中有一些有趣的东西，他们最好去理解一下，而且这些想法不仅可以有益地应用于 LRB，也可以应用于通用的 CPU 向量编程。

这些有趣的东西归结为 SPMD 编程模型，GPU 程序员通过着色器和像 CUDA 这样的语言对此很熟悉：你编写的代码看起来 mostly 是串行的，只是描述了对单个数据元素（顶点、像素等）的计算。反过来，该代码在硬件上并行运行，处理许多不同的输入——许多顶点同时被变换，许多像素一起被着色，等等。

在这个模型中，并行性是隐式的。在大多数情况下，程序员只需要考虑对一块数据进行操作，而不需要担心他们的程序如何映射到硬件。（在 CUDA 以及更新版本的 DirectX 和 OpenGL 中，情况并不总是那么简单，但大体上是这样。）并行执行是自动处理的，只要你给 GPU 提供足够多的独立工作去做，你就能获得很高的并行利用率。

正如图形程序员所了解到的，SPMD 是编写高性能并行代码的一种非常好的方式。当然，它不像自动向量化器所处理的代码那样具有串行语义，而串行语义只要不抑制性能就很好，但就并行编程模型而言，SPMD 概念清晰，并且相对容易编译到 SIMD 硬件。（关于这一点后面还会详谈。）大多数编写着色器的程序员完全不需要考虑他们的程序是并行的。

你看，这其实不是向量化问题……
回顾过去，我认为英特尔的编译器人员对这个问题思考错了，而我们图形部门的人未能弥合分歧，让他们像我们一样看待这个问题。（但我们确实努力尝试过。）对他们来说，这是一个外层循环向量化问题：你不是在向量化内层循环，你只是在向量化程序的最外层循环。虽然这在某种意义上是对问题的准确描述，但在我看来，这总是一种奇怪的思考方式。（例如，它忽略了在某些 SPMD 模型中可以表达的多个运行中的程序实例之间通信的概念。）

这种思维方式的缺陷从他们的一位首席架构师在这些讨论中反复提到的一个细节变得清晰起来：“当 CUDA 编译器向量化失败时会发生什么？“他对 CUDA 中如何处理这个问题感到困惑。给人的感觉是，他觉得只要他能理解这一点，那将是修复英特尔自动向量化器并让我们闭嘴的关键。

当然，CUDA 根本不进行向量化，因此 CUDA 从不"向量化失败”；这个问题没有意义。你编写你的程序，虽然它看起来 mostly 是串行的，但它可以也将会在 GPU 上并行运行，因为这就是编程模型，而且它能很好地映射到硬件。就这样，完成了。

我们真的努力解释过很多次，但这些解释从未被接受。

不久之后的一次会议上，同一个人愤怒地告诉我们：“我不会告诉丰田如何设计汽车；我可能会请求功能，但如何设计是他们的工作。“他和其他人厌倦了图形部门的人试图告诉他们如何改进向量编程模型，以及他们当前的模型不足以满足我们想要编写的那类程序。我们也厌倦了一遍又一遍地说同样的话而毫无进展；在那个时候，似乎不可能说服他们为此做点什么。

敬请期待下一部分，内容包括：在瑞典度过的一个夏天，以及一些开始变得有趣的 LLVM 捣鼓经历。

ispc 的故事：volta 诞生（第二部分）

和之前一样，这都是凭记忆所写，但我已尽力确保准确。如果你当时在场并发现我写错的地方，请发邮件给我。

我一直非常喜欢理查德·汉明在贝尔实验室发表的演讲《你与你的研究》。我试着每年重读一次讲稿；里面充满了宝贵的建议。其中一个让我印象深刻的部分是关于赢得诺贝尔奖的诅咒——许多诺贝尔奖得主在获奖后最终都没有再做出任何有趣的工作。

汉明的诊断是：

当你成名后，就很难再研究小问题了。这就是香农所遭遇的。在信息论之后，你还能拿出什么更精彩的作品呢？伟大的科学家常常犯这个错误。他们未能继续播种那些能长出参天橡树的小橡子。他们总想一下子就搞出大成果。但事情不是这样发展的。

我既没有诺贝尔奖的负担，也不是什么伟大的科学家，但我真的很喜欢这个见解。最好是到处摸索、探索事物，不要一开始就制定宏伟计划，但要准备好在那次探索给你指明一个有趣的方向时集中精力。

在瑞典编程
2010 年夏天，我在瑞典度过，与 Tomas Akenine-Möller 和他召集的杰出智囊团一起工作。那五个人加起来对光栅化和实时渲染的了解比世界上几乎任何人都多；当时，他们正在进行各种关于高效高维光栅化以处理运动模糊和散焦模糊的有趣工作。

他们送了我一份小礼物欢迎我，如下图。（还有：土豆和新鲜莳萝。）夏天结束时，我坦白说我没有吃腌鲱鱼，不过很高兴地喝完了阿夸维特酒。我的记忆是，他们中的大多数人都同意腌鲱鱼没那么好吃，而且他们也没指望我真的吃。

在瑞典期间，我开始捣鼓 LLVM，以为这只是件像小橡子一样的事情，很可能不会有什么结果。深入研究 LLVM 是另一件得益于 T. Foley 的事情，他对 LLVM 的设计和能力非常热情。

至少，学习如何使用 LLVM 也让我觉得这将为我的程序员技能带添加一个有用的新工具。那年夏天，Steve Parker 等人关于 OptiX 的论文发表了；他们通过即时编译生成专门的高性能光线追踪器——这是思考该问题的一种非常有趣的方式，通过巧妙运用编译器技术得以实现。正是这类事情让我对代码生成感到兴奋。

LLVM 将中级程序 IR 作为输入，并从那里开始进行优化和生成原生指令。这样的想法很吸引人：如果我编写高级编译器部分和早期编译通道，那么我就可以让 LLVM 完成剩下的工作，直到生成优化的汇编代码。这种可能性使所有这些编译器相关的东西对我来说有趣得多，尽管我对它将走向何方并没有明确的计划。

不幸的是，那个夏天我最终没能如我所愿地与 Tomas 和其他人进行那么多深入的技术工作——至今仍有些许遗憾。部分原因是英特尔会议的开销；每天下午我都会提早回家，打上几个小时的电话，参加在美国那边早上开始的会议，另一部分原因是我自己花时间捣鼓编译器去了。

当时我没有对他们多说我的编译器黑客行为；我仍然不知道它会变成什么样子，而且我最初拥有的东西看起来并不那么有趣。老实说，在最初的几个月里，它是如此缺乏创新性，让我有点尴尬，尤其与周围发生的所有真正聪明的光栅化东西相比。

psl 的短暂生命
当我开始捣鼓 LLVM 时，我需要为我未来的编译器起个名字并找一个初始的用例。我的第一次尝试是 “psl”，代表"便携式着色语言”。可移植性本身从来不是我这个项目的最大目标；回想起来，我不确定当初为什么选择这个名字。

我从 Geoff Berry 和 T. Foley 为一种基于 C 的语言编写的解析器开始；反过来，我认为（但不完全确定）那是基于 Jeff Lee 为 ANSI C 编写的 lex 文件和 yacc 语法。有了这个基础，我开始编写一个处理 C 语言子集的基本编译器，构建抽象语法树（AST），对其进行类型检查等通道处理，所有这些都是编译器 101 的内容。我编写了将 AST 转换为 LLVM IR 的代码（没有为我自己添加额外的中间表示！），然后呼哧呼哧地开始看到看起来不错的（标量）x86 代码。

我以前从未写过编译器，所以所有这些都充满了乐趣；与我之前觉得它对我想自己编写的程序用处不大时相比，我现在更有动力去学习所有那些编译器知识。

我的想法是，这个着色语言可能会走向某个有趣的方向；我可能会从 C 语言演变成一个简洁的、用于着色的小型领域特定语言，并能做一些有趣的事情。也许未来版本的《基于物理的渲染》会有一章关于这个东西——谁知道呢？我尽量不去过分担心它会走向何方；这有帮助，因为我玩得非常开心，享受着 LLVM 最终吐出的优化良好的指令，即使我的编译器在功能上没什么特别之处。

在某个时刻，我好奇 LLVM 是否会生成良好的 SIMD 代码。我真希望我记得我尝试这个实验的确切原因；可能当时觉得用着色语言结合 SIMD 一次着色多个点会很有趣，但老实说我不记得了。

无论如何，我修改了 psl，将标量变量视为 4 宽向量，并将一个小程序编译到 LLVM 的 SSE4 目标平台。我很确定那个程序是：

1

float foo(float a, float b) { return a + b; }

然后，砰，我得到了：

1
2


 addps %xmm1, %xmm0
 retq

这真是令人无比激动——我不能再要求更好的结果了。

从那里开始，添加支持更多算术操作——乘法、除法等——变得很容易，当我编写更长的（直线型）程序时，我发现编译器生成的指令看起来仍然很棒——就像我手写的一样。psl 还不能处理通用的控制流，但事情正迅速变得有趣起来。

volta 登场
随着编写一个以 CPU SIMD 指令为目标的通用 SPMD 语言的想法开始吸引我，着色语言的构想逐渐淡去：也许我可以尝试解决这个问题，因为我们与之交谈的英特尔编译器团队的人肯定不会去做。当他们没有对我们这些图形部门的麻烦制造者说"我们已经做到了”（#pragma simd）时，他们就会说"这行不通"或"这是不可能的”，这些立场之间的逻辑不一致显然不是他们担心的问题。

他们是编译器专家，所以在那个时候，我认为完全有可能我沿着这条路走下去，会发现他们一直是对的，并且这个问题比我理解的更复杂。再次说明，我以前从未真正写过编译器。那样的结果也可以接受，能学到关于计算的新东西，并对他们的立场产生新的尊重。

回到汉明的小橡子，我绝不会从一开始就决定承担"为 CPU SIMD 编写 SPMD 编译器"这个问题，但现在我发现，我已经通过黑客行为把自己带到了一个似乎可以设想它的位置。我已经积累了足够的基础设施，可以设想一连串的小步骤，如果它们都成功的话，就能把我带到某个有趣的地方，而且我对 LLVM 不会让我失望有足够的信心，愿意在代码生成部分继续押注于它。

一旦我有了更具体的目标，最紧迫的问题自然是为这个东西重新命名；“psl” 不再合适了。像通常做法一样，我向比约克寻求灵感。肯定有某个专辑标题或歌曲名字我可以拿来用——有点古怪，有点异国情调，但暗示着非常酷的东西。

放弃了《吃掉菜单》之后，我选定了 “volta”。我喜欢它所蕴含的电力和能量的感觉，而且，更妙的是，我找到了比约克解释她为何选择这个名字作为专辑名的精彩引述。我在英特尔介绍它时，会用这张幻灯片开始：

好了，这很合适。听起来也挺适合一个编译器。

下次，我们将涵盖至关重要的早期管理支持，以及一点关于 SIMD 上的 SPMD 的基本思想。然后，当我分享早期成果时，与英特尔编译器团队又一次激动人心的互动！

下一篇：全力投入 volta

注释

事实证明，这就是我目前探索用于渲染的机器学习所处的状态。我只是在学习如何用好 TensorFlow，并尝试重现别人写的关于去噪的几篇论文。有时我觉得我反而应该提出一个关于 ML 用于渲染的宏伟愿景，充满详细的计划和深刻的见解。幸运的是，谷歌一直非常支持我所采取的方法，我相信最终会取得好结果，即使目前我感觉自己的产出看起来并不特别显著。 ↩
如果我的记忆有误，错误地表述了 Tomas, Jacob, Robert, Jon, 和 Petrik 对瑞典国粹的感受，我在此道歉。 ↩
趣闻：2012 年，在听我提到 ispc 的原名后，Dave Luebke 随口问我那个名字是从哪里来的。当时，我怀疑 “volta” 可能是英伟达未来某款 GPU 的代号。（他们已经推出了 Fermi 和 Tesla，所以选择 Volta 并非不可想象，因为那里似乎有一条研究电力和能量的科学家的共同主线。）果然，在 2013 年，Volta 出现在他们的路线图上。它于 2017 年底上市。 ↩
另一个趣闻：在我离开时（2012 年），幻灯片套件在英特尔内部仍然被称为 “foils”，这个名字自使用 overhead projectors 做演示的时代起就一直沿用。我猜想这个命名法现在仍在用。 ↩

ispc 的故事：全力投入 volta（第三部分）

从瑞典回来后，我在英特尔的日常工作并不涉及编写编译器；我当时是高级渲染组的技术负责人。那时，我向 Elliot Garbus 汇报，他当时是负责图形软件的副总裁。

Elliot 是我遇到过的最好的经理。老实说，起初我并没有这种期望：虽然他职业生涯早期是技术出身，但他已经多年没有亲自动手做任何具体技术工作了，而且他的背景也不在图形领域。我不太确定我们是否有足够的共同点来建立良好的关系，但至少他看起来人很不错。

结果证明，Elliot 有着令人印象深刻的知识好奇心；当我与他谈论我和渲染组正在做的事情时，他总是能提出有见地的问题。随着时间的推移，我还了解到，你可以完全信任他会支持你；在英特尔高度政治化的环境中，这真的很有帮助。这些都是很好的基础。

最重要的是，我逐渐了解到，他非常善于了解为他工作的员工，然后有效地指导和辅导他们。有时别人能以你自己未曾理解的方式理解你，而 Elliot 非常擅长这一点。你会觉得他真正关心如何帮助你个人成长，推动你走向那些有点不舒服但值得尝试的方向。我从未在另一位经理那里有过这种经历。

我原本计划在瑞典之行之后的那个秋天离开英特尔。在经历了 Larrabee 的戏剧性事件后，我对那个地方已经感到筋疲力尽，并且已经和 Elliot 在安排过渡事宜了。就在我们处理细节的过程中，Elliot 对 volta 陆续取得的每一个新成果都持续表现出浓厚的兴趣。我当时仍在埋头苦干。他亲眼目睹了无法有效利用 Larrabee 的向量单元是多么成问题，并鼓励我留下来，看看 volta 能发展到什么地步。他提出，如果我离开，我们将永远无法知道这种方法是否真的有效。

幸运的是，他最终说服我留了下来，继续在英特尔作为一名个人贡献者，只专注于 volta 的工作。

生存下去
如果我打算留下，那么我有信心确信 volta 不会被扼杀，这对我很重要。在英特尔的政治环境中，这种情况很有可能在某个阶段发生。

例如，如果我真的在编译器团队里，很可能在某个时候会有一些人介入并说：“太好了，现在我们明白了。非常感谢！这个我们接手了——我们从这里接手，并在商业编译器中实现这个功能。哦，你不需要再继续做 volta 了，因为那只会是浪费精力。” 而如果他们用这个想法说服了管理层（这很有可能），那么无论他们是否真的履行了承诺，volta 都将会终结。

在一个理性的世界里，那种事情不会发生：为什么他们不希望自己的编译器尽可能做到最好，无论想法来自哪里呢？可能原因在于，一些在该领域确立了自己专家地位的人，更关心的是保持自己精通该主题的形象，而不是其他。也可能是因为他们仍然不相信 volta 所针对的用例——HPC 社区显然对自动向量化非常满意，而这似乎才是最重要的。

无论如何，很有可能在未来，他们中的一些人会乐于看到这个眼中钉消失，所以我必须小心。

Elliot 是让我相信我的工作不会白费的关键。我知道他会保护这个项目，而且他同意一旦编译器准备就绪，我可以将其开源。这对我至关重要；一旦 volta 开源，就不可能通过英特尔的政治手段将其扼杀。在英特尔开源软件，只需要副总裁批准（并通过一些直接明了的流程），所以有了他的同意，我可以放心地开展工作。

关于混蛋及其在机构内的被接纳度
再多说几句来解释我为什么有这些担忧。

首先，绝对明确的是，英特尔有很多优秀的人，特别是在英特尔的编译器团队里。有很多优秀的工程师在做着出色的工作，他们是完全友善、想做正确事情的人。从数量上看，他们占了绝大多数。

问题在于，只需要少数几个混蛋，尤其是在拥有权力或影响力的位置上，就足以把你搞得一团糟。

英特尔这样的人格外多，因此，在英特尔的每个人都得在技术工作和政治斡旋之间取得某种平衡。你不得不这样。政治斡旋不仅仅是标准的"为自己争取"那种事；至少，它是周期性地防御来自他人的攻击，那些人想要你的地盘，会试图让你的项目下马，以便他们可以接手。

那里的一些人对待工作的方式是，技术上贡献寥寥，但在政治上投入很多。结果证明，这完全可以成为一种成功的职业策略——在必要时诋毁他人以维持和提升自己的地位，而自己却从未真正交付多少实质性的东西。这些人就是混蛋。

让他们更容易得逞的一个事实是，英特尔软件职业发展路径全是关于尽快远离编码——写代码是给新毕业生和国外成本较低的工程师干的。荣耀在于成为架构师，自己从不编码，但设定方向。在那个角色上，一个人可以仅仅依靠幻灯片（我是指 foils）就走得很远，而无需产出更多东西。

因为那里有这些混蛋，你总是必须提防他们。即使你不想在自己的职业生涯中采用那种模式，你也必须防御他们，否则你就会被淘汰。

我一直不明白为什么英特尔的上级管理层似乎对他们存在无动于衷。我猜想，一旦那种成功模式扎根，它就会像癌症一样侵蚀组织，并且难以根除。也许他们认为英特尔作为一家公司做得相当不错，所以为什么要去修理没坏的东西呢？也许他们认为这是一种良性的进取心，并且对大家相互争斗、像角斗士在竞技场中搏斗以赢得胜利、一切为了英特尔的荣耀这种想法感到满意。

有时，那些纵容混蛋的管理者会鼓励你在与他们互动时"假定对方意图是好的”。如果你这样做，你很快就会被算计；他们不玩那种游戏，并且知道如何利用你给他们的任何空子。

Elliot 从未告诉我要对他们"假定对方意图是好的”。

当他帮助我弄清楚如何与那些混蛋周旋时，我相当肯定他用了一句轻蔑的脏话来表达他对他们的看法。

下次真的会谈谈 SIMD 上的 SPMD 和早期设计影响；会比这篇结果写成的样子更愉快一些。再下一篇我们才会讲到首次向编译器团队展示成果。

下一篇：C 语言的影响及在 SIMD 上实现 SPMD

注释

和往常一样，总有例外。有一小部分资深人士仍然编程；非常尊敬他们。 ↩

ispc 的故事：C 语言的影响及在 SIMD 上实现 SPMD（第四部分）

注意： 在这些文章中，我不会在技术层面全面详细介绍 ispc/volta 的工作原理、其前身是什么，或者所有关键设计目标是什么。我会在叙述中提及其中一些相关内容，但要了解全面讨论，请参阅我与 Bill Mark 合写的关于 ispc 的论文。如果你花时间阅读本文，那篇论文也值得一读（恕我直言）。（Bill 稍后会在本故事中出现。）

防御阵线建立好后，我就出发了。要将 volta 变成普遍有用的东西，还有很长的路要走。许多基本的语言功能尚未实现——例如，我很确定像结构体这样的东西在那个时候甚至还不能用。

在 volta 的设计和实现过程中，我思考了很多关于 C 语言的事情。我一路第 N 次重读 K&R 以寻找灵感。

让我用 C 语言开始 psl 的并不仅仅是因为有可用的 C 语法：我非常喜欢 C 语言；它是一种非常简洁明快的语言。对我来说，很明显我会继续以 C 语言作为 volta 的基础，尽可能少地偏离它。不仅 Kernighan 和 Ritchie 显然把很多事情都做对了，而且这种语言广为人知，如果 volta 有朝一日完成，熟悉的语法将使其更容易被人们采用。

我从 C 语言中汲取的远不止语法——其设计原则更为重要。C 语言与当时的硬件有紧密的映射关系，一个好的程序员可以查看 C 代码，并相当准确地猜出编译器会为该代码生成哪些指令。没有神秘感，没有编译器魔术，没有看起来无害却可能爆炸成一堆指令的语句（我说的是你，C++）。我希望 volta 能保持这一点。

我想象 Kernighan 和 Ritchie 在当今世界设计 C 语言。如果 C 语言是为今天的 CPU 设计的，它会有什么不同？CPU 架构发生了两大变化：多核处理和 SIMD 向量单元。

对于多核，有很多好的想法可以借鉴。Andrew Lauritzen 了解所有这些想法，并且对此思考了很多，他是 Cilk 多线程方法的忠实粉丝——函数可以异步调用其他函数，这些函数可以在单独的线程中运行，编译器在原始函数返回之前等待它们全部完成。这很好地实现了并行组合。

所以我给 volta 添加了一个 launch 关键字；它使用了 Cilk 的语义。把它放在函数调用之前，该函数就会被送到线程池中：

1

launch foo(a, 6.3);

尽管这在语法上并不比调用 TBB 或类似的东西简洁多少（尤其是在现在有了 C++11 lambda 表达式之后），但把它作为语言的一等公民感觉很好。这基本上是零摩擦的多线程，似乎很适合这个时代。

对于 SIMD，一个明显的选择是使用显式向量数据类型来暴露 CPU 的该能力——这基本上就是很多人手动做的事情，用 vec4f 类等包装内部函数。将其作为语言的一等特性当然很有用，并且对于某些类型的计算，显式向量最终是表达它们的一种更清晰的方式。

正如现在应该已经清楚的那样，我真的很想编写具有复杂控制流但仍然在 SIMD 硬件上运行的程序；对于这种情况，显式向量不是很方便，所以选择了在 SIMD 上实现 SPMD。我认为这也非常符合 C 语言的哲学：直接和可预测，背后没有深奥的编译器魔术。

也许 K&R 会决定让这两种选项都可用，而且两者兼有通常很好；例如，那样的话，人们可以编写一个针对 16 宽 AVX-512 的程序，运行 4 个 SPMD 程序实例，每个实例的每条指令都可以执行一个 4 宽的向量操作。我们将在回顾中回到这个话题。

实现在 SIMD 上的 SPMD
正如我在瑞典所体验到的，向量化直线型代码很容易——如果你不先试图证明向量化是安全的，那就没什么难的。更棘手的部分是为 SPMD 程序实现通用的控制流。我们希望不同的 SPMD 程序实例在程序中走不同的路径，并且仍然计算出正确的结果。

使用内部函数的程序员知道这是如何完成的：当有条件地处理向量中的值时，你需要维护一个额外的掩码变量，记录其中哪些应该被修改。如果你在逻辑上有类似这样的东西：

1
2


if (a < b)
 c = 0;

对向量值的 a、b 和 c 进行操作，那么你存储一个记录 a < b 的向量结果的掩码，然后用它来有条件地将零赋值给 c 向量。如果有一个 else 语句，那么你对掩码取反，然后执行其代码，并注意掩码。Kayvon Fatahalian 有一套很棒的幻灯片讨论了这个以及它在 GPU 上是如何处理的；所有这些都非常相似，只是硬件提供了多一点帮助。

更一般地说，循环、break 和 continue 语句，甚至通过指针的间接函数调用——所有这些都可以通过使用相同的思路以向量形式执行：

维护一个执行掩码，记录哪些程序实例（SIMD 通道）是活动的。
根据通过程序的保守控制流路径执行向量指令。换句话说，如果任何通道需要，就执行一条指令。
确保非活动程序实例不会产生可见的副作用——意外的内存写入等。

这些中的每一项要正确实现都可能有点繁琐，但它们在概念上是直接的原则。

维护循环执行掩码的规则只比 if 语句的规则稍微复杂一点。循环测试的值给出了循环体的执行掩码，你运行循环直到所有活动程序实例的该掩码都为假。循环中的 break 只是禁用执行 break 语句时掩码为活动的任何元素的活动掩码；它们的活动掩码在循环结束后恢复。continue 会禁用某个实例的掩码直到当前迭代结束，此时掩码恢复。等等。

在 volta 中正确实现这个掩码维护功能花了一些时间。一旦这一切都真正稳固下来，真是令人激动，尤其是 LLVM 持续可靠，只要我给它好的向量化 IR，它就能给我好的 x86 汇编。

这里有一个小的 volta/ispc 程序示例，它使用一种低效的算法计算一个浮点数的整数次幂。（注意这个程序也是有效的 C 代码。）

1
2
3
4
5
6


float powi(float a, int b) {
 float r = 1;
 while (b--)
 r *= a;
 return r;
}

这是如今编译器输出的汇编代码。（注意：AT&T 语法，目标操作数是最后一个参数。）这里我使用了 AVX2，因为它比 SSE4 更清晰，尽管 SSE4 是 volta 最初唯一支持的指令集。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


LBB0_3:
 vpaddd %ymm5, %ymm1, %ymm8
 vblendvps %ymm7, %ymm8, %ymm1, %ymm1
 vmulps %ymm0, %ymm3, %ymm7
 vblendvps %ymm6, %ymm7, %ymm3, %ymm3
 vpcmpeqd %ymm4, %ymm1, %ymm8
 vmovaps %ymm6, %ymm7
 vpandn %ymm6, %ymm8, %ymm6
 vpand %ymm2, %ymm6, %ymm8
 vmovmskps %ymm8, %eax
 testl %eax, %eax
 jne LBB0_3

前两条指令递减 b，使用活动的向量掩码仅对活动的通道执行赋值。接下来的两条将 r 乘以 a，同样使用掩码。然后将 b 与零进行相等比较，结果用于更新执行掩码。（由于 powi() 可能在调用时并非所有通道都启用，所以更新掩码需要一条额外的指令，因此我们必须在 powi() 入口处对掩码进行 AND 操作。在这种情况下，如果我们跳过这一步并为禁用的通道计算错误的结果也没问题，但通常我们需要一个准确的掩码，以防有像内存写入这样的操作需要为非活动通道抑制。）最后，用一个快速的 movmsk 检查是否还有任何通道是活动的，然后再跳转到循环开始。

就是这样。我认为除了在执行掩码维护上不必要的精确之外，这是最优的。我很乐意偶尔接受一些零星的额外指令，而不是必须手动编写内部函数，特别是对于非平凡的程序。

编译器优化与转换
看过这个例子后，就更容易理解 T. Foley 另一个超级有洞察力的观点：为 SIMD 硬件编译 SPMD 程序是一种编译器转换，这与编译器优化完全是两回事。

这个见解回到了自动向量化的问题：它是一个复杂的优化，充满了启发式方法，你无法确定它最终会走向何方。编译器试图推理循环向量化的安全性——是否存在任何循环携带的依赖？用计算机程序对任意程序进行推理只能做到这一步（记得那个麻烦的停机问题吧），所以自动向量器注定是脆弱的，并且对用户来说是不可预测的。

在 SIMD 上实现 SPMD？那是一种转换。我们刚刚看到了如何做到这一点。它是机械的。如果你已经将其自动化，没有理由它不会一直有效。

这样做的好处是它符合 C 语言的哲学：任何理解这个概念的程序员都可以准确预测编译器将生成什么代码，而且这几乎就是他们自己会手写的代码；对于有性能意识的程序员来说，第一个属性与第二个属性同样重要。

最终，volta 是一种有点"笨"的编译器；它的实现中并没有什么真正深奥巧妙的东西。除了大量的工程工作之外，关键首先在于以正确的方式处理问题。

下次，我们终于要向编译器团队分享初步成果了。

下一篇：初步基准测试结果

注释

当然，CPU 微架构发生了很多变化——乱序执行、分支预测、缓存，所有那些好东西。但这些都没有真正影响编程模型应该是什么样子。 ↩
我已经好几年没有用锐利的目光阅读 x86 汇编了，所以我期待收到邮件告诉我我漏掉了什么，并且那个说法是错的。:-) ↩
Tim 也应该因发明"SPMD on SIMD"这个短语而受到赞誉。 ↩
至少，那些从被"足够智能的编译器"坑过一两次中吸取了教训的程序员是这样。 ↩

ispc 的故事：初步基准测试结果（第五部分）

和之前一样，这是凭记忆所写。我尽力确保细节准确，但如果有任何错误，请联系我。

编译器团队当时使用一小套基准测试来评估并行编程模型——比如布莱克-斯科尔斯期权定价、曼德博集求值、小型模板计算等。它们大部分都只有几十行代码。

最复杂的是 aobench，大约有 300 行代码。如果我没记错的话，图形部门的人把 aobench 推给他们，作为至少能模糊代表图形工作负载典型不规则性的事物。任何更复杂或更贴近实际的东西都根本不被考虑：对于当时手头的许多并行编程模型来说，处理起来都太困难了。

aobench，通过现代 ispc 渲染。在配备 AVX2 的双核笔记本电脑上，比串行代码快 15.6 倍。

英特尔拥有各种各样的并行编程模型；有些只针对多核，有些只针对 SIMD。英特尔 C 编译器中有用于多核的 Cilk，有自动向量化和 #pragma simd 的东西，有 OpenCL 编译器，有来自 RapidMind 的元编程技术（后来与英特尔的 Ct 合并，最终成为英特尔 Array Building Blocks），还有 Thread Building Blocks 以及英特尔 Concurrent Collections。可能还有其他我忘记的东西。

总的来说，只针对多核的模型在线程数上表现出线性扩展，而针对 SIMD 的模型在 SIMD 宽度上对没有控制流的计算表现出线性扩展，但对于有控制流的计算（如计算曼德博集和 aobench）则完全不起作用。不同的向量通道想要走不同的执行路径，这对它们来说太难处理了。

总之，一旦 volta 变得相当完善，并且我对它生成的代码质量感到满意后，我就用 volta 编写了其中一些基准测试并测量了性能。我相当惊讶：对于其中许多测试，volta 击败了 #pragma simd（最接近的竞争者），而在其余的测试中也相当接近。除了那个模板计算，我想是这样。

而且不仅仅是它在像 aobench 这样能真正处理控制流的测试中获胜，即使对于一些简单的基准测试，它也更快。虽然只快了几个百分点，但它赢了。我反复运行测试，只是为了确认自己没有搞错什么。

英特尔有数百名员工致力于编译器工作，并自豪于能生成比任何其他编译器都更好的 x86 代码。可以说，volta 能取得这样的成果（尽管是针对一组简单的基准测试），是相当令人震惊的。

我不记得我是如何首次向编译器团队传达这些结果的了，但这对他们来说同样令人惊讶——volta 结合了来自图形领域人士的奇怪编程模型，以及他们只是略有耳闻的 LLVM，这两者结合在一起效果如此之好，几乎是不可想象的。

不久后就安排了一个会议，与编译器团队的十来人讨论所有这些。

除了集体的惊讶之外，反应是分化的。大多数人对这个结果很感兴趣——LLVM 在当时还不是像今天这样众所周知的强大工具，一个程序员利用它就能击败 icc 编译器……这当中肯定有值得学习的趣事。我们对结果进行了很好、很健康的讨论，并深入研究了生成代码的一些差异。我可能又解释了一遍什么是"在 SIMD 上实现 SPMD"。

对结果的另一种解读
他们中有一两个人得出了另一个结论：只有一种方式可以解释——我肯定作弊了。我猜他们想象我一定是特化了编译器，设置了特殊 case 来检测这些基准测试程序，然后当识别出这些程序时，就直接吐出完美且预先准备好的代码，根本没有任何编译过程。这当然是解释击败 icc 的最可能的方式。

根据典型的博弈论来推测那些混蛋的想法，他们的思路是这样的：我也是个混蛋，我在这里的真正目标并不是真正解决问题，而是想利用 SIMD 要么篡夺他们在编译器组里并行编程模型方面的角色，要么推进某些其他邪恶的计划。

在那种情况下，我自然会严守秘密，对编译器源代码保密，并且只勉强让他们试用二进制文件。也许我甚至会试图推迟几个月再提供，声称我想先做更多改进。如果我作弊了，我会尽量拖延他们发现真相的时间，希望我的邪恶计划能先成功。

或者，如果我确实有个好主意，我应该做的是对细节保密，防止他们拿走并声称是他们自己的，以维持他们的地位。

而我呢，我仍然只是想说服专业人士来编写这个编译器，这样我就不用自己做了。我做的正是我们之前多次告诉过他们的事情。所以我在会议后通过电子邮件发了一个源代码的 tar 包。

请原谅我，但我很确定我在邮件里附了道歉：这是我第一次写编译器，所以如果部分实现得不是很好，请见谅。这是从那些混蛋身上学到的教训：有时候稍微补一刀也挺有意思的。

结果证明我并没有作弊，不过他们指出 volta 的超越函数精度不如其他编译器。我修改了 volta 以使用英特尔的短向量数学库内部函数（SVML），其他编译器用的也是这个。在期权定价测试上，性能差距缩小了，但 volta 仍然领先。在其他不使用超越函数的测试上，结果没有变化。

对源代码保密——真的吗？
对源代码保密的想法可能看起来很奇怪。毕竟，我们都在同一家公司工作，对吧？

事实证明，有些团队会小心翼翼地守护他们的源代码，只向英特尔内部的其他团队提供二进制版本，并且只在明确规定的交付点提供。这是防御混蛋的一种手段。

情况是这样的：如果你正在做的东西是别人想要攻击的，有时他们会拿走你进行中的系统版本，把它拆解剖析，找出一堆它目前还运行不好的例子，然后拼凑出一个论据，说你的东西状况糟糕、无法工作，因此应该被取消。

有时这种策略真的奏效；管理层对这种危言耸听的接受程度令人震惊。也许是因为他们离技术太远，无法根据其优劣来评估这些论点，或者也许又是他们欣赏这种角斗士般的争斗作为决策过程。

最好的情况是你的团队必须花费大量时间说服管理层，让他们相信你们实际上在正轨上，一切正常。更简单的办法就是一开始就不分享你的代码。

真是"美好"的时光啊。

下次我们将讨论并行编程模型的比拼，以及 volta 最初内部用户的使用情况。

下一篇：首批用户与现代 CPU 的到来

ispc 的故事：首批用户与现代 CPU 的到来（第六部分）

volta 早期令人印象深刻的结果带来的其中一件事，是受邀参加编译器团队内部正在进行的一系列并行编程模型比拼。

过程是这样的：每隔几个月，会组建一个小组，成员来自英特尔各个并行编程项目（TBB、#pragma simd、Cilk、OpenCL 等等），每个项目派一两名代表。这个过程会持续几个月，首先是大家共同商定评估方法，然后协商纳入哪些工作负载。（我向您保证，绝对没有参与者会推动那些特别适合自己模型的工作负载，或者试图边缘化那些不适合的工作负载。）接着是测量性能，调整优化器，最后，我们会准备一份演示文稿，提交给编译器部门的副总裁。

能参与其中，至少在传统的英特尔职业生涯看来，是一项荣誉。我的工作重要到足以向副总裁级别汇报，这种事情是可以写进个人的"自夸表"里的——就是每年为绩效评估准备的自评报告。有些人全年都在打磨这份文件，从上一次评估周期结束就立刻开始。报告长度没有限制，长达二十页的也并不罕见。

最终，演示不仅会展示性能结果，还会强调每种编程模型的优势。人人都有奖杯，而这些比拼似乎从未影响过英特尔的战略。

我想我被邀请参加这个"派对"是高兴的，但我并没有在这些活动上投入太多精力。我对小心翼翼地守护 volta 在这些基准测试上的性能领先优势不感兴趣，尤其是在其他模型的实现者努力缩小差距的时候；更有趣的是开始将它用于更复杂的、其他模型无法处理的程序，并开始与英特尔内部的早期采用者合作。

早期用户体验
英特尔的许多图形部门人员对 volta 感到兴奋并予以支持。就像我说过的，这或多或少是他们许多人想要的那种工具。

他们中有一些人已经使用内部函数实现了有趣的图形程序。这形成了一个绝佳的组合：我们既有编写良好的内部函数实现可以作为 volta 结果的对比基准，又有聪明的程序员，他们知道自己希望从编译器得到什么，并且不惧怕阅读和批评汇编代码。到 2010 年 12 月左右，编译器已经足够健壮，开始有其他人使用它。

最早的用户之一是 Doug McNabb，他曾经用内部函数编写了一个粒子光栅化器。他将其移植到 volta 然后……性能糟透了，汇编代码一团乱。这个结果起初让我有点害怕——面对一个新的工作负载完全失败了。也许这整个事情终究不会像我希望的那样成功。

结果发现，他在他的 volta 代码中恰好全程使用了无符号整数，但这并非出于任何特定需求。而事实上，SSE4 指令集中并没有在浮点数向量和无符号整数向量之间进行转换的指令，因此，每次需要转换时（这种情况很频繁），都会变成一大段标量代码，逐个转换每个向量元素。

我在编译器中添加了一个关于在 SSE4 下使用无符号整数的警告，而 Doug 迅速修复了 volta 代码，改用常规的整型。成功了！干净的汇编代码，性能与他手写的内部函数代码相差无几。呼，松了一口气。

另一位早期用户是 Andrew Lauritzen，他有一个集群延迟着色工作负载，用来评估将该计算映射到不同并行硬件（从 Larrabee 到 GPU）的各种方法。他有一个内部函数实现，并且很乐意编写一个 volta 实现，这个实现现在成了 ispc 的示例之一。

ispc 中的延迟着色：在单核上使用 SSE4 比标量代码快 4.15 倍，并且在多核上呈线性缩放。

Andrew 的延迟着色示例是当时用 volta 编写的较长的程序之一，所以我又一次紧张起来。令人欣慰的是，它运行良好，几乎可以说是开箱即用。我手头没有当时的性能数据，但如今在单核上，使用 SSE4（我们当时的测试目标）运行比串行代码快 4.15 倍，并且随着核心数量的增加几乎呈线性扩展。

对于 Doug、Andrew 和其他早期采用者来说，从串行 C 实现转到 volta 确实相当容易，这起到了很大帮助。首先你戴上 SPMD 的"思考帽"。然后你决定将 SPMD 程序实例映射到什么——像素、三角形，或者任何适合循环遍历的对象，然后基本上就这些了。你的大部分 C 代码可以保持不变或只需最少量的修改。

当然，这正是基于 C 语言在 SIMD 上实现 SPMD 的核心理念，但让我惊讶的是，它在实践中如此清晰。例如，比较 ispc 示例中一个小型光线追踪器的串行 C++ 实现和 ispc 实现；大部分代码几乎完全相同。

真的，用你喜欢的图形化差异比较工具看一下；没有多少行代码是不同的，但 ispc 展现出的性能在 CPU 核心数量和 SIMD 宽度上都能线性扩展。

早期采用者们深入使用过程中发现了不少 bug，我真的很感谢他们总体上没有因此感到困扰，并且乐于投入时间和见解来让这个东西变得更好。他们的反馈和热情真的很有帮助；能够逐渐确信这个东西或许也能解决他们关心的问题，这太棒了。

赞颂现代 CPU
关于 Andrew 的延迟着色工作负载实现的 4.15 倍加速：这个改进实际上略高于 SSE4 可能提供的理想 4 倍加速。有时 volta 确实会发生这种情况；这有点诡异，让人怀疑"我是不是测错了？"。延迟着色工作负载涉及一些 gather 操作和一些分叉的控制流；它本身也不是完全规整的。

这种结果尤其令人惊讶，因为在 AVX-512 之前，英特尔的向量指令集架构（ISA）完全不是为 SPMD 执行设计的。在 AVX 之前，它们尤其非正交且古怪（参见 SSE4 中无符号整数向量和浮点数向量之间的转换）。给人的感觉是，它们的设计初衷并非作为编译器目标，而是架构师们发现手写一些重要内核代码所必需的操作的大杂烩。

当我最初在 volta 中实现 SPMD 控制流时，我并不确定它在实践中效果到底会多好。我或许能正确地在 CPU SIMD 硬件上运行 SPMD 程序，但如果性能很差，那也没什么意思。分叉控制流是一个已知的风险：就像在 GPU 上一样，分叉执行会带来性能损失：如果一些程序实例走 if 语句的一个分支，而另一些走另一个分支，那么你将不可避免地执行两边代码，每一部分都只有部分通道是活跃的。

一个更令人担忧的问题是，有很多操作不被支持为向量指令，必须通过分解成相当于在 SIMD 通道上循环的代码，用标量代码处理每个通道。在 SSE4 时代，这类情况非常多，经过 AVX、AVX2 到 AVX-512，逐渐减少。

举个例子，这里有一个简短的 volta/ispc 函数，执行一次 scatter 操作：index 的值在每个 SPMD 程序实例中是唯一的；因此，每个实例通常写入完全不同的（并且可能是不连续的）内存位置：

1
2
3


void scatter(uniform float ptr[], int index, float val) {
 ptr[index] = val;
}

对于现代 AVX-512，情况很理想，有一条原生的 scatter 指令 vscatterdps 可以完全处理这个问题。而在 AVX-512 之前的所有指令集上，都必须生成基本上是对向量通道进行循环的代码，检查每个通道的执行掩码是否启用，然后仅在启用时才将该通道的值写入内存。

最终对于 SSE4 总共需要 23 条指令；对于 AVX 则需要更多指令，因为向量通道数翻倍了。这是为 SSE4 生成代码的开头部分，处理第一个向量通道：

1
2
3
4
5
6
7


 movmskps %xmm2, %eax
 testb $1, %al
 je LBB0_2
 movd %xmm0, %ecx
 movslq %ecx, %rcx
 movss %xmm1, (%rdi,%rcx)
LBB0_2:

testb 和 je 在当前通道不活跃时跳转到下一个通道，而那三条 mov 指令则在通道活跃时整理数据并写入内存。然后，或多或少相同的事情，再重复三次。除了所有这些指令，还有一系列不一定非常可预测的分支短指令序列；这对性能也不是什么好消息。

那么，那个延迟着色工作负载以及其他偶尔有 gather 或 scatter 之类操作但仍然高效运行的程序，是怎么回事呢？我能想到的最好答案是：乱序执行掩盖了大量的瑕疵。

英特尔 CPU 非常擅长运行糟糕的代码。这么写有点滑稽，但我的意思是这是一种高度的赞美；我认为这是他们真正的竞争优势之一。构建一个能高效运行完美规整代码的处理器，比构建一个能体面运行任何扔给它的垃圾代码（虚函数调用、缓存不友好代码、分支众多的代码等）的处理器要容易。我认为英特尔的伟大才能之一就是能够很好地运行所有这些玩意儿——比竞争对手好得多。

另一个更具挑战性的工作负载例子：ispc 发行版中包含一个小型体渲染器。（同样，ispc 实现看起来非常像 C++ 实现。）它生成这样的图像：

当我第一次编写它时，我不知道它在 volta 中运行是否会比在标量代码中更快；它本身并不非常 SIMD 友好。计算的核心部分让光线穿过一个规则网格的体密度值，并对 8 个邻居进行三线性插值以计算密度，并在每个点计算光照。因此，沿着每条光线的每个点都需要 8 次 gather 操作，因为每个向量通道可能读取不同的内存位置来获取其密度值。

它持续向前步进穿过体积，直到不透明度足够高，以至于光线更远点的光照不会产生影响。因此，还存在不规则的控制流：在一组跨越 SIMD 通道的光线中，必须持续进行，直到所有光线都决定终止。

在运行 SSE4 版本（我最初测试的目标）的 2 核笔记本电脑上，ispc 实现比串行代码快 5.2 倍。请注意，这仅是最佳情况下可能期望加速比的 65%——多线程带来 2 倍加速，4 宽 SSE 带来 4 倍加速，总共 8 倍。在相同的 2 核系统上使用 AVX2，ispc 版本比串行代码快 7.7 倍。整体更好，但仅为理想情况的 48%。推测 AVX2 中的原生 gather 指令起到了一些作用，尽管分叉控制流的效率损失更高了，现在是 8 宽运行。

无论如何，我认为这个性能出奇地好：我原本半预期这个工作负载在映射到 SIMD 硬件上时根本看不到任何好处；对于如此不规则的东西能有这种加速，我已经非常满意了。

下次，我们将介绍构建 AVX 后端的经验以及与 LLVM 团队的互动。

下一篇：构建 AVX 后端及回馈 LLVM

注释

一些谷歌员工对谷歌的绩效流程开销感到非常焦虑；不用说，我见过你们难以想象的事情。 ↩
那个 uniform 限定符表示该值在所有程序实例中是相同的；这里意味着基指针是相同的。 ↩

ispc 的故事：构建 AVX 后端及回馈 LLVM（第七部分）

时间到了 2011 年底，我对 AVX 即将在 Sandy Bridge CPU 上亮相感到非常兴奋：在经历了多年 SSE 的 4 宽向量（针对 32 位数据类型）之后，AVX 将其翻倍，使得执行 8 宽 32 位向量操作成为可能。这大概是自 1999 年 SSE 问世以来，英特尔 SIMD 指令集架构中最令人兴奋的事情了。AVX 的到来对 volta 来说尤其令人兴奋——在最佳情况下，得益于向量通道数翻倍，许多东西的运行速度会大致快两倍；而在最坏情况下，这整个"在 SIMD 上实现 SPMD"的想法可能最终被证明并不那么吸引人。

速度快两倍是巨大的提升：上世纪 90 年代是你最后一次在单代 CPU 中看到接近"快两倍"性能提升的时候。如今，单核 CPU 性能每代可能提升 10-20%，这得益于更好的半导体工艺、略快的时钟频率以及微架构改进，但也就这样了。

有趣的是，英特尔即将发布 AVX，但在某些情况下，AVX 要让程序运行得更快会有延迟，有时甚至长达数年。对于自动向量化器能处理的代码，只需重新编译即可。但对于所有用 SSE 内部函数编写的代码，嗯，必须有人去用 AVX 内部函数重写它，它才会变快。对于世界上所有不使用 SIMD 的标量代码，AVX 不会带来任何好处。如果几年后你又得全部重写一遍，那么当初费尽心思写所有这些内部函数的动机是什么呢？

用内部函数编码有很多问题——不仅仅是那些永恒难题，比如什么前面加单下划线，什么加双下划线，更在于它完全将你绑定在特定的指令集架构及其能力上。这种情况与 GPU 完全不同，GPU 厂商能够每代进行重大的架构更改，通过提供更多核心和更多向量通道来提升速度，而程序员无需修改他们的代码。

在很大程度上，英特尔内部的人似乎并不太在意事情是这样；我从未真正理解这一点。嗯，有些人在意，但我不明白为什么领导层没有为此积极抓狂——你即将推出一款计算能力比一年前产品翻倍的 CPU，但几乎没人能享受到这个好处？

我唯一的猜测是，这是多年来 C（和 Fortran）能完美映射到英特尔 CPU 架构所遗留的观念；在多核和 SIMD 变得重要之前，他们无需担心编程模型本身，所以我猜他们已经习惯了这不关他们的事。

尽管英特尔的编译器团队内部关于并行编程模型的讨论很多，但它并没有那种"公司的未来取决于此"的感觉，例如，不像英伟达对待 CUDA 那样。谁知道呢，也许公司的未来确实不取决于此；我猜英特尔现在还在经营。不过，在增加 SIMD 宽度的同时，却没有一个关于开发者如何真正有效利用它的计划，这仍然显得很奇怪。

无论如何，如果他们给我这些向量通道，我会欣然接受。一旦 LLVM 中开始出现对 AVX 的早期支持，我就开始为 volta 添加 AVX 支持。

为 volta 添加新后端
为 volta 添加新后端基本上包括启用相应的 LLVM 代码生成器，然后手动编写一堆 LLVM IR 来弥合编译器希望执行的基本操作与给定指令集架构的具体细节之间的差距。例如，volta 标准库提供了一个对各种类型进行操作的 min() 函数。

以下是针对 float 的实现（用 volta 编写）：

1
2
3


static inline float min(float a, float b) {
 return __min_varying_float(a, b);
}

相应地，每个后端都需要提供 __min_varying_float() 的实现，该实现需手动用 LLVM IR 编写。对于 AVX，有一条对应的指令，LLVM 通过一个内部函数暴露它，我们可以直接调用它。

以下是 AVX 的定义：

1
2
3
4


define <8 x float> @__min_varying_float(<8 x float>, <8 x float>) {
 %call = call <8 x float> @llvm.x86.avx.min.ps.256(<8 x float> %0, <8 x float> %1)
 ret <8 x float> %call
}

LLVM 会将 volta 中对 min() 的调用转换为一条 vminps 指令。

如果 AVX 没有单条指令能完成此操作，那么 AVX 目标的 IR 就需要通过其他操作以最合理的方式来完成计算。（像 SSE4 的 scatter 和 gather 这类操作就是以这种方式实现的。）

大力测试 LLVM 中的 AVX 支持
如前所述，没有 LLVM，volta 绝无可能；如果开箱即用的 SSE4 代码生成质量没有那么好，我很可能早就结束了早期的实验，转而进行新项目了。我欠 LLVM 一个大人情，所以想做点有益的事情作为回报。

在 LLVM 的 AVX 后端甚至还没完成之前，我就开始尝试使用它了；我猜开发人员当时可能还没准备好让任何人去测试它。不过，我真的很想看看 AVX 对 volta 的效果如何，而且我也觉得我可以在测试他们的实现方面帮点忙。

结果证明，volta 在测试 LLVM 的向量代码生成方面相当有效。它不仅生成大量向量化的 LLVM IR，还直接发出大量 x86 向量内部函数（如 __min_varying_float()）；这两者的特征都与大多数其他基于 LLVM 的编译器通常生成的 IR 有很大不同。这使得在 LLVM 的那个早期 AVX 后端中很容易找到很多 bug。

为了让您对典型输出有个概念，这里半随机地选取了为延迟着色示例生成的一些代码，这里使用的是 AVX 和现代的 ispc。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


 vmovups 1856(%rsp), %ymm3
 vdivps %ymm2, %ymm3, %ymm13
 vmulps %ymm13, %ymm1, %ymm1
 vdivps 1792(%rsp), %ymm1, %ymm4
 vmulps 608(%rsp), %ymm13, %ymm1
 vdivps 1376(%rsp), %ymm1, %ymm11
 vmulps %ymm4, %ymm4, %ymm1
 vmulps %ymm11, %ymm11, %ymm2
 vaddps %ymm2, %ymm1, %ymm1
 vmulps %ymm13, %ymm13, %ymm2
 vaddps %ymm1, %ymm2, %ymm1
 vrsqrtps %ymm1, %ymm2

这是该示例的所有汇编代码：deferred.S。

当我开始尝试使用初期的 AVX 后端时，我遇到的第一个 LLVM bug 通常是崩溃和断言失败；LLVM 中各种对于新目标尚未经过测试的部分，或者那些对其输入有假设但新目标不再成立的部分。我会使用 LLVM 的 bugpoint（一个很棒的工具，它能进行自动二分搜索以找到最小的测试用例）来精简出一个小的测试用例，然后发送出去。

当代码能编译之后，下一步就是正确性。我在开发过程中使用了一个包含几百个 volta 程序的测试套件；每个程序都是一个简短的函数，执行一个小计算，然后验证结果是否与期望值匹配。这些测试不仅在我开发 volta 时对于验证其自身的正确性很有用，而且也能很好地发现 LLVM 向量代码生成的正确性 bug。每当这些测试在新目标上失败时，我就会深入排查；有时是我自己的 bug，例如在我为后端编写的 IR 中，有时是 LLVM 的代码生成 bug。一旦所有这些测试都通过，我就可以自信地开始编译更大的程序了。

随着 LLVM 对于给定后端的向量代码正确性变得稳定，我花了很多时间查看生成的汇编代码（volta 的用户也是如此）；这导致了我观察到许多 LLVM 向量代码质量可以改进的情况。

在 volta/ispc 的开发过程中，我似乎总共提交了 144 个 LLVM bug。LLVM 开发人员通常修复得非常迅速。这让整个过程充满乐趣——感觉我们在一起取得良好进展，随着他们修复了早期的 bug，我可以继续寻找 progressively 更冷门的 bug。最终，AVX 及更高版本的 LLVM 后端变得非常稳定；我愿意认为 volta 发现的问题对这个过程有所帮助。

在 LLVM 方面，非常感谢 Nadav Rotem，他在 LLVM 的向量选择方面做了很多关键工作；Bruno Cardoso Lopes，他在 AVX 代码生成方面做了大量工作并修复了大部分这些 bug；以及 Craig Topper，他为 AVX2 做了很多贡献。当然，还要万分感谢 Chris Lattner 最初启动了整个 LLVM 项目，以及 LLVM 团队的其他成员。

调查结果显示…
所有的汗水都是值得的。当 AVX 开始正常工作，我可以开始测量性能时，真的非常令人兴奋。通常，从 AVX 中获得 1.5 倍到 2 倍的性能提升是很典型的。而且只需要重新编译；现有的 volta 代码无需修改就能看到这些性能提升。再次松了一口气，没有出现意外的波折导致事情不如预期。

以下是用今天的 ispc 测量的一些结果，显示了在单核上相对于标量代码的加速比。

工作负载	SSE4 加速比	AVX1 加速比	AVX1:SSE4 比率
Black-Scholes	4.13x	6.12x	1.48x
光线追踪器	2.60x	5.42x	2.08x
延迟着色	4.15x	5.00x	1.20x
Aobench	3.33x	4.86x	1.46x

几个工作负载的单核加速比，显示了 AVX 带来的性能优势（使用今天的 ispc 测量）。

我本来敢发誓 Black-Scholes 在 AVX 落地时基本上快了两倍。这点将来需要深入研究一下，但上面是现在的数字。

AVX2 也是一个巨大的进步，因为它也提供了 8 宽 32 位整数操作：

工作负载	SSE4 加速比	AVX2 加速比	AVX2:SSE4 比率
Black-Scholes	4.13x	6.97x	1.68x
光线追踪器	2.60x	6.56x	2.52x
延迟着色	4.15x	6.38x	1.54x
Aobench	3.33x	6.78x	2.03x

不用说，看到这些加速比真实发生，真是太神奇了。将 SIMD 向量宽度翻倍，在晶体管和功耗方面是相对廉价的。我不知道实际数字，但就这些指标而言，将向量宽度翻倍比将 CPU 上的核心数量翻倍要便宜得多。而且事实证明，如果你有一个合理的编程模型、编译器以及合适的工作负载，你就能看到在亚线性硅成本下性能接近翻倍。胜利！

下次，将详细介绍一些关于如何让程序运行得更快的具体细节。

下一篇：关于优化和性能的更多内容

ispc 的故事：关于优化和性能的更多内容（第八部分）

之前将 volta 描述为一个"笨"编译器有点不太公平；我们今天将重新探讨这个话题。

不仅许多语言特性经过精心设计以很好地映射到 CPU 硬件，而且一些针对 LLVM IR 的自定义优化通道对于保持性能与内部函数代码竞争也至关重要。其中许多优化都受到了英特尔早期用户的影响，以及他们对 volta 汇编输出的仔细审查。

统一 (Uniform)
uniform 限定符是对性能最重要的语言特性之一。

uniform 是一个类型限定符，它描述一个在所有正在执行的 SPMD 程序实例中相同的值。它对应于一个标量值，并能很好地映射到 CPU（我听说 CPU 既支持标量计算也支持 SIMD）。这个概念对于程序员来说很容易掌握，并且直接映射到 CPU 内部函数程序员组织其代码的方式。

将变量声明为 uniform 可以带来两个好处：

任何基于 uniform 值的控制流就像常规程序中的控制流一样：所有 SPMD 程序实例遵循相同的路径，我们不需要担心更新执行掩码。
对 uniform 值的内存访问易于处理且高效：例如，一个 uniform 读取对应于一个简单的标量加载。

我第一次接触 uniform 的总体思想是在 RenderMan 着色语言（RSL）中，它实际上是一种在要着色的点网格上操作的 SPMD 语言。它也有一个 uniform 关键字，表示对所有点都相同的值。据我所知，RSL 实现从未以 SIMD CPU 硬件为目标，但标量 CPU 实现维护了一个记录哪些点处于活动状态的掩码，并且可以应用 uniform 来在控制流方面获得类似的好处。兜了一圈，当皮克斯几年前发布了一份关于使用 ispc 编写着色器的好处的说明时，我觉得很有趣。

事实证明，RSL 最初是为 1980 年代的定制 SIMD 硬件设计的，而且那个时代针对多处理器的其他 SPMD 语言中也有 uniform 的前身；再次请参阅 ispc 论文以了解该领域先前工作的更多信息。

最小化掩码指令
处理掩码向量计算的所有细节可能会导致 x86 汇编代码相当臃肿。结果证明，设计 volta 的一些语言特性是值得的，以便能够促成编译器可以确定所有程序实例都处于活动状态的情况，并在代码生成中利用这一点。

其中一个例子是 volta 提供的一个专门的循环结构 foreach。它描述了一个遍历一个或多个维度的循环，其中 SPMD 程序实例被映射到给定的值范围。

我们将在下面使用这个简短的 volta 函数作为示例；想必它的功能是显而易见的：

1
2
3
4
5


void increment(uniform float ptr[], uniform int count) {
 foreach (i = 0 ... count) {
 ptr[i] += 1;
 }
}

现在考虑一个在 130 个值上进行 foreach 循环，目标是 8 宽 SIMD：将会有 16 次执行掩码全开的循环迭代，处理前 128 个值。然后，在最后会有一次迭代，其掩码是混合的，用于处理剩余的两个元素。ispc/volta 为循环体生成两个版本的代码，第一个专门针对全开掩码进行了优化。

现代的 ispc 为无掩码迭代生成以下 AVX2 汇编代码，外加几条额外的指令来检查是否需要进行下一次循环迭代，然后跳转到适当的位置：

1
2


 vaddps (%rdi,%rdx), %ymm0, %ymm1
 vmovups %ymm1, (%rdi,%rdx)

这正是你想要的，除非你是那种会为可能不必要的未对齐向量存储而烦恼的人。假设 count 很大，绝大多数迭代将只运行那段代码。

在一般情况下，还需要做更多的工作。以下是最后一次迭代的代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


 vmovd %eax, %xmm0
 vpbroadcastd %xmm0, %ymm0
 vpaddd LCPI0_1(%rip), %ymm0, %ymm0
 vmovd %esi, %xmm1
 vpbroadcastd %xmm1, %ymm1
 vpcmpgtd %ymm0, %ymm1, %ymm0
 shll $2, %eax
 cltq
 vmaskmovps (%rdi,%rax), %ymm0, %ymm1
 vbroadcastss LCPI0_0(%rip), %ymm2
 vaddps %ymm2, %ymm1, %ymm1
 vmaskmovps %ymm1, %ymm0, (%rdi,%rax)

前几条指令确定执行掩码，禁用对应于数组中超过 count 的项的向量通道。然后，在从数组加载最后的值时，必须使用该掩码和一条掩码加载指令 vmaskmovps，以免意外读取数组末尾之后的内存。然后是加法运算。最后，在将结果写回时使用掩码存储，以免破坏数组之后的内存。

如果没有 foreach 以及它所启用的"全开"优化，我们每次循环都需要经历很多这样的操作。（而内部函数程序员会理所当然地翻个白眼然后走开。）

如果你知道要处理的项数总是 SIMD 宽度的倍数，你可以在循环前添加类似这样的代码：

1

count &= ~7;

这在实践中是无操作（no-op），但这足以让编译器推断出如果不需要，它就不必发出循环体的第二个版本。（这里的"编译器"，我指的是 LLVM；ispc 会继续为两种情况发出 IR，但在 LLVM 的常规优化通道完成工作后，LLVM 的死代码消除通道会处理掉不需要的部分。）

除了 foreach 之外，还有其他地方我们可以做类似的事情。当应用程序第一次从 C/C++ 调用 volta 代码时，根据定义，所有程序实例都在运行，因此可以静态地确定执行掩码是全开的，直到 SPMD 控制流介入。在那之前，也可以应用相同类型的优化。

此外，当 SPMD 控制流开始发生时，并非全无希望：在运行时检查所有程序实例是否处于活动状态可能是值得的。volta/ispc 提供了独立的控制流关键字，允许程序员指示预期是相干的控制流：cif、cfor 等等。

例如，当使用 cif 时，volta/ispc 生成的代码会在为 ‘if’ 条件更新执行掩码后立即测试它。如果它是全开的，那么我们可以跳转到一个专门的代码路径，该路径以"掩码全开"的假设开始。如果它是全关的，那么我们可以直接跳转到 ‘if’ 语句体之后。否则，我们必须像常规 if 那样，使用常规掩码执行 if 的代码。显然，cif 在代码重复方面是有成本的，但在所有程序实例实际上都处于活动状态的情况下，它可以带来有意义的性能好处。

我觉得将其作为一个显式的语言特性很重要，而不是不引入新的关键字并试图为优化器找出合理的启发式方法来决定何时添加该检查以及何时不添加。诚然，这对程序员来说增加了一点额外的脑力开销，而且我确信有些人在编写 ispc 代码时没有使用这些特性，但本可以从这些特性中受益。不过，这再次表明我倾向于编译器在生成的代码方面是直接和可预测的；这是另一个专注于以性能为导向的程序员作为最重要用户类型的案例。

高效的 SPMD 加载和存储
在 SIMD 硬件上运行的 SPMD 程序的加载和存储是"有趣"的。通常，向量中的每个程序实例可能正在读取或写入内存中完全不同的位置。此外，其中一些实例可能是非活动的，在这种情况下绝对不能发出读取或写入。（我们之前在了解实现 scatter 时已经看到了这个问题的一点端倪。）

通常，我们需要为 SPMD 读取发出一条 gather 指令，为写入发出一条 scatter 指令；这些指令允许在访问的内存位置方面具有完全的灵活性。即使这些可以作为原生指令使用（就像在 AVX-512 中一样），如果我们访问的内存位置是连续的，使用向量加载和存储的性能会好得多——最好只在真正需要时才使用 gather 和 scatter。

不幸的是，我们需要在编译时做出这个决定。对于 GPU（据我理解它们如今的工作方式），所有这些很大程度上是运行时的区别：编译器只是发出相当于 gather 或 scatter 的指令，然后运行时的实际性能取决于访问的位置是否以各种方式相干。（避免存储体冲突等等。）这样好得多，因为访问的位置通常是数据相关的，因此它们的相干性在编译时永远无法像在运行时那样清楚。

但 CPU 不是这样工作的，所以我们必须在编译器中尽力而为。

volta 前端完全不会在这方面耍小聪明；除了通过 uniform 进行的标量内存访问之外，它一开始只是为所有 SPMD 读写生成试探性的 gather 和 scatter。volta 在 LLVM IR 中声明了一大堆伪 gather 和 scatter 函数，例如：

1
2


declare <WIDTH x float> @__pseudo_gather64_float(<WIDTH x i64>,
 <WIDTH x MASK>) nounwind readonly

（WITDH 和 MASK 通过宏扩展步骤设置为具体值。）

然后，对于任何 SPMD 内存读取浮点数（例如，在上面那个 increment() 示例中加载一个 SIMD 向量容量的值），在 64 位目标上，volta 会发出一个对 __pseudo_gather64_float 的调用，为每个 SIMD 通道提供一个唯一的指针以及执行掩码。

这些伪函数在早期的 LLVM 优化通道中保持未定义状态。随后，自定义的 volta 优化通道开始尝试改进它们。有很多可以做得更好的地方：

如果所有指针都具有相同的值，volta 会替换为标量加载和向量广播。
如果可以确定 SPMD 实例正在读取连续的内存位置（如在 increment() 中），则使用向量加载。
如果确实需要 gather，或者编译器无法确定，那么就使用 gather。（然后特定目标的 IR 将要么发出原生指令，要么用一系列指令等效实现。）

我希望所有这些复杂性都不是必要的，但如果是不必要地发出了 gather 或 scatter，性能会显著下降，所以花大力气解决这个问题是值得的。最终，这些优化通道得到了大量关注，并且在检测适当模式方面变得相当稳健，我认为这是所能期望的最好结果了。

后来，我花了一些时间实现了一些稍微更复杂的方法来避免 gather，将那些可以更好地表示为向量加载和混洗的读取进行优化。考虑这个函数：

1
2
3
4
5


void reduce(uniform float ptr[], uniform float result[], uniform int count) {
 foreach (i = 0 ... count) {
 result[i] = ptr[i/2];
 }
}

在 8 宽目标上，最好发出一个 4 宽加载并进行向量混洗——比 gather 快得多。对于像这样的函数：

1
2
3
4
5
6
7


void deinterleave(uniform float ptr[], uniform float a[],
 uniform float b[], uniform int count) {
 foreach (i = 0 ... count) {
 a[i] = ptr[2*i];
 b[i] = ptr[2*i + 1];
 }
}

有经验的内部函数程序员会使用两次向量加载然后进行一些混洗。用现代的 ispc 尝试这个，会发出一个 gather；我发誓这些过去是由那个优化处理的。这是另一个以后需要深入研究的小问题。

总之，最后所有这些加起来在 ispc 中构成了大约 6k 行代码的自定义 LLVM 优化通道；所以也许这个编译器毕竟不是完全"笨"的。然而，所有这些中并没有太多深奥的编译器魔术，我认为这使得编译器的输出仍然相当可预测。

明天：激动人心的时刻，让 volta 开源的时刻。

下一篇：开源发布与 volta 的终结

注释

volta 的 foreach 灵感来源于 Mark Lacey, T. Foley, Jefferson Montgomery, 和 Geoff Berry 正在构建的一种以 GPU 为目标的语言中的相关结构。 ↩
一个合理的批评是，我们正开始走向程序员需要做一些繁琐的事情来让优化器按他们意愿行事的状态。我认为有一个更广泛的有趣问题，关于程序员如何清晰直接地向编译器提供程序将要处理的数据的特征信息，以帮助优化。不过，这不是我最终在 volta 中解决的问题。 ↩

ispc 的故事：开源发布与 volta 的终结（第九部分）

照例声明： 这全是凭记忆所写，而且已经过去好几年了。如果你当时在场，发现我记错了什么，请发邮件给我，我很乐意更正。

2011年春天，公司进行了一次重组，大部分图形软件部门的人并入了硬件部门。对我来说，加入他们那边没有意义，所以我留在了编译器组，向英特尔院士、编译器组首席技术官 Geoff Lowney 汇报。我很遗憾不能再为 Elliot 工作，并且在组织上也离开了我的图形部门朋友们。我也有点担心：感觉有点像搬到了"敌占区"。

幸运的是，Geoff 非常棒：甚至在我加入他的团队之前，他对 volta 的态度就是开放和充满知识好奇心的——“它效果这么好，真的很有趣；我们能从中学到什么？” 这一点加上他在编译器方面的深厚造诣，真的很棒；我从他那里学到了很多。在我剩余的英特尔时光里，他都是这个项目的坚定支持者；我对他一路上的所有帮助表示万分感谢。

我继续开发 volta，大约在春末的时候，我开始觉得它已经准备好面向更广阔的世界了。内部已经有足够多的人使用过它并且体验良好，这让我有信心在更广泛的用户群中也能进展顺利。而且我很兴奋能够向英特尔外部的程序员传递这个信息：你的 CPU 拥有的计算能力可能远超你的想象；关键在于要有合适的编程模型。

我之前的经理 Elliot 已经同意让我将 volta 开源，而且我知道我可以完全信任他的承诺。但问题是，必须由你当前的副总裁批准，才能开源在其组织内开发的任何东西。我的新副总裁负责编译器团队。

他对开源这件事并不那么热心。

有些担忧是这会令客户感到困惑，同时拥有一个开源编译器和一个商业编译器；还有人担心如果我某天离开英特尔，谁来维护它——诸如此类的问题。可能还有更深层次的原因，但没人明说。

我们来回讨论了几次，但最终决定是：不，编译器不会被开源。（但我可以继续研究它，并继续遵循"影响"生产编译器这条崇高道路，尽管到目前为止这并未产生任何可见的效果。）这个决定显然让我非常沮丧，因为我一直以来都是在预期它最终会开源的前提下继续开发 volta 的。

至少，接下来该怎么做是显而易见的：如果 volta 将被永远锁在英特尔内部，那我就没有理由再继续开发它了，而且在那时，我在那里也没有其他感兴趣的工作可做了。

于是，我提交了辞呈。

态度立刻发生了转变，开源批准下来了。我赶紧尽快处理细节，并将代码推送到 GitHub，以免情况有变，我的授权被撤销。

RIP volta, ispc 长存
英特尔（理所当然地）对产品命名有非常严格的规定。其中包括，产品名称必须以"Intel"开头，并且必须精确描述产品的功能。没有多少发挥创造力的空间，一旦编译器开源，“volta” 作为其实际名称就立刻夭折了。

这非常符合英特尔的典型作风：他们害怕因商标侵权而被起诉，这种担忧压倒了为事物取个好名字的考量。（或者可以这样理解，审批名称的人极度渴望自保，以至于制定了确保永远不会发生商标诉讼的规则，这样他们就不会因为放行任何更大胆的名称而惹上麻烦。）总之，有机会可以用这个视角去看看英特尔的产品名称——“Intel® SSD 730 Series” 等等。

所以，必须是"Intel"并且精确描述其功能。好吧，那么它就是"Intel SPMD Program Compiler"，简称 ispc。我仍然对"volta"被那个怪异的名称取代感到有点难过——“program compiler”，我的意思是，真的吗？

具有讽刺意味的是，这个新名字让编译器听起来比它实际的情况更"官方"，更像是一个得到英特尔广泛支持的东西，而事实并非如此。

初始发布
在商标部门批准了名称之后，还有一些行政琐事，然后要获得批准将代码发布到 GitHub 上，这在当时是相当新奇和另类的，尤其是从英特尔的视角来看。

我花了很多时间打磨代码和文档。我希望源代码是干净且注释良好的，我希望文档是详尽的。我认为尽可能留下良好的第一印象，对于吸引人们的注意力和让更多人使用它来说是时间花得值得的。

现在让我后悔的是，我那时还从一个全新的 git 代码库开始。当时，我不想让我在确定编译器计划之前的所有摸索和探索公之于众，而且有一半的提交信息是"小修复"或"添加了待办事项"有点尴尬。现在我真希望能仔细翻阅所有这些，弄清楚早期历史的更多细节。

无论如何，代码于 2011 年 6 月 21 日在 GitHub 上线了。那差不多是我开始捣鼓 LLVM 一年之后。

那天晚上我发了一些邮件，并在推特上发布了公告：

我过去大约一年一直在忙活的事情…… Intel SPMD Program Compiler (ispc) 现在可以在 ispc.github.com 上获取了。

还有

原生的、高性能的 {SPMD, SIMT, map/kernel, 着色器风格} CPU 编程。ispc.github.com。唤醒你沉睡的 SIMD 单元！

（请注意，那还是在 140 字符推文的"远古时代"，所以需要两条推文才能说完。）

这就是所有的"市场营销"了。人们开始尝试使用它，并看到了好的结果；一切继续像宣传的那样工作。呼，松了一口气。

下次： 作为开源项目继续开发 ispc，向学术界介绍 ispc 的经历，以及我离开英特尔。

下一篇：传播理念与离开英特尔

注释

谷歌图片搜索能响应"Bjork crying"并提供这张她小时候伤心或者可能困倦的照片，是不是很棒？ ↩

ispc 的故事：传播理念与离开英特尔（第十部分）

首次推送到 GitHub 之后，出现了一些 bug 修复（幸好没有太尴尬的）和拉取请求；一切似乎进展顺利。对 AVX2 的初步支持于 2011 年 12 月进入 ispc 代码库；看起来它在 2012 年 1 月被启用，但对 AVX2 的 gather 和 FMA 指令的支持直到那年夏天才完成。（我想可能是在等待 LLVM 对这些功能的支持，但不完全确定。）

2012 年夏天，Jean-Luc Duprat 开始致力于 ispc 对 Knight’s Corner（KNC）的支持，这是一个基于 Larrabee、面向 HPC 的架构，也是至强融核系列的第一个产品。Jean-Luc 曾是图形部门的人员，非常了解 SPMD，后来成为 KNC 的架构师，并希望 ispc 能在该平台上运行。由于缺乏 KNC 的 LLVM 后端，他实现了一种巧妙的方法，基于使用 LLVM 的 C++ 后端来生成 C++ 内部函数代码。只要有正确的头文件，这些代码就可以被编译成汇编。这是一种取巧的办法，但非常高明。

C++ 与方案撰写
Bill Mark 开始深入研究为 C++ 标准提出 SPMD 计算扩展需要涉及哪些细节；他是一位出色的系统设计师，非常擅长深入思考细节。在接下来的许多个月里，我们就语言设计及其与 C++ 的关系进行了多次长谈；最终，他提出了一个相当全面的 C++ 扩展设计，并称之为"Sierra"。关于 ispc 中指针的正确设计就是这些讨论的成果；事实证明这有点微妙。

一位实习生用 Clang 实现了这些想法的一个原型，并取得了良好的初步结果；Clang 清晰的设计使得实现相对简单直接。看到像 lambda 表达式和模板这样的特性直接在 SIMD 上的 SPMD 代码中工作，真的很棒。Bill 设计中的许多想法后来出现在这篇论文中。

Bill 和我在 2012 年合写了一篇关于 ispc 的论文。我认为它很好地捕捉了系统的设计和实现考量，并且深入讨论了先前与 ispc 有很多共同点的 SPMD 语言。我们在当年的一个新并行计算会议 InPar 上发表了它。

InPar 与英伟达的 GTC 大会同期举行，这意味着会议重点 heavily 偏向 GPU。说到"重点 heavily 偏向 GPU"，我的意思是我们的论文是唯一一篇关于 CPU 的。然而，在听众的大力支持下，我们赢得了最佳论文奖。我们的奖品是一块顶级的英伟达 GPU。

与学术界交流
Geoff Lowney 提供的巨大帮助之一，是安排我向学术研究人员就 ispc 做几次外部演讲。其中一次促成了我对伊利诺伊大学香槟分校为期两天的访问，并在那里做了一次讲座。

第一天上午，我与英特尔香槟-厄巴纳办公室的一群人度过，非常棒——他们聪明、思想开放且有趣。然后我有幸和 David Kuck 共进午餐，这也非常棒。事实证明，他对并行编程略知一二。

不过有个小插曲：显然午餐的鸡肉沙拉里的鸡肉出了问题；结果导致了食物中毒，我在酒店房间里度过了当天下午和晚上的剩余时间，状态很不好，并且非常担心第二天在大学里的演讲会怎么样。要在观众面前站立一个多小时，同时还要条理清晰地演讲，看起来相当悬。

即使在不生病的时候，我也总是担心向编译器研究人员谈论 ispc；编译器不是我的领域，我担心自己对先前工作的了解不完整。我想象自己向一位教授解释这个想法，然后对方说：“哦，那是 Hazenburger 变换，最早在 1975 年就被描述了。我的本科编译器课程上周刚把它作为作业实现了。你做的事情还有什么新东西吗？”

呃，没有——就这些。（到现在我已经很放心了，毕竟根本没有什么 Hazenburger 变换。）

我对 UIUC 的演讲格外紧张，因为 Vikram Adve 是那里的教员，并且会出席。他不仅是著名的编译器研究员，还是 Chris Lattner 的博士导师；LLVM 就是在 UIUC 起步的。所以，在我设想的最坏情况下，当众出丑的可能性更大了，现在还要加上担心自己是否能从食物中毒中完全恢复。就在演讲前，我侦察了最近的洗手间位置，以便知道紧急情况下该往哪里跑。

令我欣慰的是，演讲进行得很顺利。Vikram 人真的很好，我们之后愉快地聊了聊；他似乎觉得这些想法很有趣。演讲被录了下来，但链接似乎失效了。这样可能也好；我可以避免看自己视频的尴尬。幻灯片仍然在线；它们展示了当时项目的状况和传达的主要信息。

几周后，在另一所大学的并行计算实验室进行的演讲就不那么顺利了。一个不好的预兆是，本该介绍我的那位教员直到原定开始时间 20 分钟后才出现。在尴尬地站了 10 分钟等待有人来开场之后，我最终只好自己做了介绍并开始演讲。

在演讲后的问答环节中，一位研究生坚持认为，我在结果中报告的在一台 40 核机器上实现的 180 倍加速纯粹归功于多线程，我怎么确定 SIMD 起了任何作用？而且，据他说，现在没有一个有趣的工作负载不是大规模并行且能在 GPU 上运行良好的，因此让东西在 CPU 上跑得快并没有什么意义。

当邀请我做演讲的那位教员告诉我，他没有安排演讲后与实验室研究人员的任何会议（这原是邀请的一部分）时，我反而有点松了一口气。

离开英特尔
这一切的结局有点讽刺。

很长一段时间里，我都极力避免组建一个团队来开发 ispc；一路上有很多其他人参与进来，投入其中，并做出了关键贡献——T. Foley、Bill Mark、Jean-Luc 以及许多其他人。他们都在不同的组织，自愿贡献他们能够且愿意投入的时间。

不试图在此基础上进一步正规化，是一种防御策略。一个有组织的 ispc 工作小组会成为一个更好的攻击目标：如果我获得了人员编制并雇人来组建一个专注于 ispc 的团队，我们可能会高效工作一段时间。然而，随着时间的推移，那些讨厌鬼很可能会施展他们娴熟的伎俩，说服管理层这些人可以更好地用于其他更重要的事情上。如果成功，那么噗的一声，所有人都会被调去加入其他小组，项目也就分崩离析——这正是他们的实际目标。

只有我一个人的话，就没有什么明显的目标了。

2012 年秋天，我还是去找了 Geoff Lowney，请求仅仅增加一个人的人员编制来帮助我进行 ispc 开发。目标不算太大，而且那时正是开始认真支持 AVX-512 的好时机；在这方面有很多工作要做。他爽快地答应去促成此事。几天后，当他告诉我没问题时，我感到的是……恐惧。

尤其是在 ispc 开源之后，我一直能够比较无忧无虑：编译器已经存在于世，运行良好，人们喜欢它。我可以基本上按部就班地继续开发它。如果英特尔内部情况变得怪异——办公室政治、糟糕的重组，无论什么——我知道我可以一走了之，而不会留下太多未竟之事。我从未计划在英特尔度过我的整个职业生涯，所以我打算只要在这里比离开更有趣就待着，并在合适的时机离开。

但是，让一个人加入这个项目？那我就要对他负责，必须尽我所能保护他免受政治影响。更糟的是，我将不再能随时离开英特尔——那样对那个人不公平，尤其因为如果我离开，他很可能会被重组到其他项目中去。我意识到，增加人手实际上等于承诺自己至少再待一两年。

考虑到之前所有的起起落落，我还没有准备好做出那样的承诺。进一步思考后，似乎这可能是时候离开了；ispc 状态良好，没有什么重大的缺失。继续按部就班地工作并没有太大的吸引力。

于是，我辞职了，那次是认真的。当我解释原因时——正是他批准了我最初请求的人员编制，让我意识到是时候离开了——Geoff 有点惊讶，但他表现得非常冷静，令人佩服。我用英特尔邮箱地址进行的最后一次提交是在 2012 年 9 月 14 日。

接下来， 将介绍一些用 ispc 编写的大型系统、设计回顾，以及一点基于 ARM 的兴奋点。

下一篇：回顾与反思

注释

与此相关，Ingo Wald 写了一个 SPMD on SIMD 语言原型，IVL，它直接将抽象语法树转换为 C++ 内部函数代码。 ↩

ispc 的故事：回顾与反思（第十一部分）

随着开源发布，我曾希望 ispc 能播下使其自身被遗忘的种子。我希望有一天它能被一个更好的、在 SIMD 上实现 SPMD 的编译器所超越，理想情况下，这个编译器能成为像 Clang、GCC 或 MSVC 这样被广泛使用的编译器的一部分。我非常喜欢 ispc，直到今天仍然享受用它来编写代码——我仍然认为它是一个很棒的工具。真正的成功应该是有人采纳了这个想法并做得更好，使得这种方法无处不在。

至少 ispc 存活了下来，并且似乎有满意的用户；我对此感到非常兴奋。我也很高兴英特尔有一些人在继续维护 ispc。英特尔的同事们在对 AVX-512 的良好支持和修复用户发现的 bug 方面做得非常出色。

如今的 ispc 能生成非常漂亮的 AVX-512 代码；这里是 aobench 的一小段代码，展示了那些可爱的 zmm 寄存器和一些 AVX-512 掩码管理：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


 vsubps %zmm6, %zmm16, %zmm0
 vsqrtps %zmm7, %zmm6
 vsubps %zmm6, %zmm0, %zmm0
 vmovaps 2368(%rsp), %zmm6
 vcmpnleps %zmm0, %zmm6, %k1
 vcmpnleps %zmm16, %zmm7, %k1 { %k1 }
 vcmpnleps %zmm16, %zmm0, %k0 { %k1 }
 kmovw %k0, %ecx
 testw %cx, %cx
 je LBB1_32

我或许应该找点时间，在支持 AVX-512 的 CPU 上享受一下编写和运行 ispc 程序的乐趣。

应用情况
至少有几个相当大的系统是用 ispc 编写的；它似乎经受住了考验。

我曾用 ispc 写过一个 Reyes 渲染器，可惜最终没能纳入 ispc 发行版的示例中——我始终没有彻底完成它。那有近 1 万行 ispc 代码。我觉得 ispc 很好地证明了其价值：对于渲染器需要做的几乎所有事情，我都能生成良好的 SIMD 代码：细分时的贝塞尔曲线求值、着色、纹理过滤、光栅化、遮挡剔除等等。任何人都不可能用内部函数手写所有这些代码。

翻找我在英特尔时的旧推文，我找到了它生成的一张图像：

这个场景有 140 万个双三次曲面片；地平面应用了纹理和置换贴图。在一个 4 核 AVX1.1 系统上，以 720p 分辨率、每像素 16 个采样渲染该场景耗时 634 毫秒。在我看来这相当快了。

Embree，英特尔的高性能光线追踪库，广泛使用了 ispc。他们使用 ispc 让我非常激动——那个团队里的一些人是极其出色的内部函数程序员；他们的标准很高。

梦工厂更是用 ispc 编写了他们新的生产渲染器 MoonRay。他们为此写了一篇论文，其中包含关于向量化影响的广泛测量。看到向量化在如此复杂的系统中也能运行良好，真是太好了；事实证明——想想看——这种 SIMD 技术不仅仅适用于局部内核。

批评与反思
总的来说，我对这门语言最终呈现的样子相当满意。有具体的程序我想用 volta 来编写，这对一路上的设计决策提供了坚实的依据。一个小例子：我自然想用它写一个光线追踪器，但也许起初我只想在 volta 中做光线遍历。因此，让从 C/C++ 调用 volta 以及在不同语言间共享基于指针的数据结构变得容易，就成了设计的核心部分。

设计一个东西来解决你自己的问题可能很危险：最坏的情况是，它对其他任何人都没用。但这总比设计一个对你没用、但你想象别人会想要的东西要好。我当时相当确定，我正在考虑的那些用例不仅符合图形领域其他人想做的事情，而且也可能适用于其他领域。

通过这种方式构建，我认为 volta 在很多方面都做得不错，但随着经验的积累和视角的拓宽，很明显在设计和实现上仍存在一些粗糙之处和需要改进的地方。

侧重于 32 位数据类型： 我个人感兴趣的大多数计算主要基于 32 位浮点数。在我编写优化通道和查看编译器汇编输出时，这些得到了最多的关注，这在某种程度上损害了 64 位浮点数的代码质量，并且肯定也损害了 8 位和 16 位整数数据类型的代码质量。
每个源文件固定一个 SIMD 向量宽度： 在 ispc 中，SIMD 向量宽度是在编译时按每个源文件固定的。然而，在计算的不同部分使用不同的 SIMD 宽度通常很有用，例如在处理不同大小的数据类型时。能够以更细的粒度来改变这一点会更好。
unmasked 关键字： ispc 提供了一个 unmasked 关键字，可以在定义函数或语句前使用；它让程序员向编译器指示，在此时应假设掩码为"全开"。对于那些希望在安全的情况下（即无需掩码即可进行计算时）削除每一个不必要指令的程序员来说，这是一个有用的工具，但它很危险，并且并不真正符合 SPMD 编程模型；它或多或少是一种为了解决硬件限制而泄露到语言中的变通方法。
- 补遗： 在重新查阅文档后，我想起 unmasked 使得在 ispc 中表达嵌套并行成为可能，我想这毕竟不是坏事，但可能有更好的方法来实现。
显式向量与 SPMD： 如果能支持映射到 SIMD 通道的显式向量，并能在 SPMD 和这些显式向量之间分割 SIMD 通道，那将会很好。这不仅可以通过语言提供显式向量计算，还能表达兼具向量并行性和数据并行性的计算。
嵌入 C++： 如前所述，如果能将 SPMD 功能在 C++ 中可用，那将很好；这将能实现与应用程序代码更轻松的互操作，并且能够使用模板、lambda 表达式，甚至可能是虚函数的全部功能，这将非常棒。

不受欢迎的拉取请求
接近尾声时，我应该为给英特尔的一些同事带来的尴尬处境而道歉。

离开英特尔后，我来到谷歌，最终从事在 ARM CPU 上运行的工作。我觉得为 ARM 的向量指令集 NEON 编写一个后端会很有趣。我在 2013 年 SIGGRAPH 会议期间，在酒店的闲暇时间里完成了这项工作。只花了几天时间，遵循了前面描述的相同路径。

我发现并提交了 LLVM NEON 后端的一些 bug。在修复之后，面向 NEON 的 ispc 可以工作了，但加速效果相当平淡。在 4 宽英特尔向量单元上，ispc 能可靠地为 SPMD 程序带来 3-4 倍的加速，而在当时我使用的 ARM CPU 上，2 倍加速更常见。虽然也有提升，但远不如在英特尔 CPU 上那样令人惊喜。不过，我认为让它对其他开发者可用仍然是有用的；之前已经有一些开发者请求过这个功能。

尽管我仍然拥有对 GitHub 代码库的提交权限，我还是将这些更改打包成了一个拉取请求。我认为 ispc 在那时已经归英特尔维护，应该由他们决定是否接受这些更改。

我忍不住在 2013 年 7 月 20 日格林威治标准时间 15:02 发了两条推文：

完成了 ispc NEON 后端：github.com/mmp/ispc/tree/… 测试通过，示例工作正常等等。（附上在 a15 上运行的 aobench 结果。）

现在等着看当前的维护者会如何处理这个拉取请求。:-)

我绝对低估了这种情况的敏感性。后来我被告知，内部对此进行了激烈的讨论。我认为没有人愿意成为那个接受拉取请求的人；对于一个英特尔员工来说，允许在一个由英特尔分发和冠名的编译器中添加 ARM 支持，没有任何好处，却可能带来一大堆负面影响。

我特别感到遗憾的是，被我置于这种棘手境地的那些人，正是那些一直支持 ispc 并维持项目运行的人。其中一位给我发了邮件，说他们不会接受这个拉取请求。

在格林威治标准时间 22:15，即我的第一条推文 7 小时后，我发了推文：

令人印象深刻的快速拉取请求拒绝。

我决定直接分叉代码库；这似乎是一个合理的选择。

推送了带有针对 int8 和 int16 计算特化的 NEON 分支的 ispc：github.com/mmp/ispc/tree/…。假设这个分支会长期存在。

然而，之前曾致力于为 ispc 添加 Knight’s Ferry 支持的 Jean-Luc Duprat 认为，将其纳入代码库是正确的——对用户如此，甚至对英特尔也是如此。他当时已不在英特尔，但仍然拥有向 GitHub 代码库提交的权限，于是他继续操作并接受了这个拉取请求。就这样：NEON 目标进入了官方代码库。撤销它可能会更加尴尬，所以它就留在了那里。Jean-Luc 不久后失去了他的提交权限。我很确定他觉得这是值得的。

ARM 支持仍然在那里，但在英特尔官方的二进制发行版中并未启用。这似乎是一种不错的折中方式。

我们还没完全结束。明天还有一篇简短的帖子，内容会比较哲学化。

下一篇：后记

ispc 的故事：后记（第十二部分）

卓越若无对手相伴，亦会凋零：当我们看到它何其伟大，力量何其磅礴之时，正是它通过坚忍展现其威力之际。我向您保证，善良之人亦应如此：他们不应畏惧面对艰难困苦，亦不应抱怨命运；无论发生何事，善良之人都应坦然接受，并努力将其转化为善果；重要的不是你承受了什么，而是你如何承受。

——塞内加，《论天命》

在英特尔的时光里，有很多不愉快的时刻。尽管我很高兴如今已不在那里，但那段时期却成为了技术创造力和构建至今仍引以为傲的事物的时期。

尽管经历了那些荒唐事，我不能说今天我完全后悔那段时光。也许部分原因是时间的流逝，冲淡了关于压力的记忆，忘记了政治斗争涌动时的无力感。部分原因是知道最终，一切实际上都还不错。

谷歌以其"Googliness"的理念为傲，即认为那里的每个人都是友善、快乐的好人，大家互相帮助，朝着同一个方向努力。基本上确实如此：五年里，我只遇到过一回需要应付那种咄咄逼人的办公室政治，而那一次也很快被管理层制止了。绝对没有同事 actively 破坏你的事情。据我所见，这类伎俩会迅速被谷歌的文化抗体所排斥。

谷歌是一个令人愉快的地方。我不会希望它是别的样子。但有时我会纠结于一个问题：这是否伴随着某些代价。

我是否会在一个更具"Googliness"的环境中写出 volta？

更切题地说：我是否会在一个没有几个我一心想要证明他们是错的、且颇具影响力的混蛋的环境中写出它？

需要明确的是，我在谷歌也做成了一些我认为不错的事情，并且没有那种对抗性的动机——这是一个绝佳的工作环境。我并不认为混蛋是进步的必要因素，但我忍不住去想，最终他们是否以其特有的方式为 ispc 做出了"贡献"。

也许塞内加确实道出了一些真谛。

感谢您阅读至此。明天我们将开始我的 Larrabee 回忆录。开个玩笑，只是玩笑。我们到此为止了。我绝不会去写那个，而且我也该放个博客假期了。

『学习笔记』CMU 15-445 (2024 fall) Project #1 - Buffer Pool Manager

Thu, 11 Sep 2025 05:45:00 +0000

CMU 15-445 (2024 fall) Project #1 - Buffer Pool Manager

封面来源：@psychoron

Project #1 - Buffer Pool Manager | CMU 15-445/645 :: Intro to Database Systems (Fall 2024)

实现的 BusTub 是面向磁盘的 DBMS，数据存储在 non-volatile disk 中。

BusTub 的 page 是固定大小 4 KB，

缓存池管理器 Buffer Pool Manager 存储 store 页到固定大小的 buffer 中，称为 frame。

把逻辑页 logical page 存储到物理固定帧 physical fixed frame 中。

作为 cache 也作为提供 DBMS 支持大于内存大小的数据库的管理。

实现需要是线程安全的，使用 latches 来保证。

和 OS 的 lock 的区别大概是保护内部数据的关键部分，且不需要支持回滚 rollback change。

Task #1 - LRU-K Replacement Policy

size_t 是 unsigned 默认值不要赋 -1。

别的就正常实现，线程安全，先都加大锁，后面再考虑优化。

Task #2 - Disk Scheduler

了解 std::promise 和 std::future，简单理解是线程之间更加方便传递数据的方式。

关于 std::promise 和 std::future 的使用方式：

线程一，创建 promise 和 future，把 promise 传递给线程二（ref / move）；

线程一，获取值（等待，堵塞）；线程二，future 返回值，线程一继续。

另一个相关的是 std::async，对 std::future 和 std::thread （和 std::packaged_task）的封装。

std::packaged_task 也是类似。

值得注意的是，std::future.get() 的时候，会自动调用 wait，且只能调用一次 get()。

std::async 有不同的启动模式

std::launch::async 异步
std::launch::deferred 在 get(), wait() 的再去延迟执行
std::launch::async | std::launch::deferred 默认，都可以，取决于编译器 / 操作系统（？）

如果 std::future 关联的 std::promise 在未被使用的时候，被释放了，会报错。

多个线程等待同一个执行结果时，可以使用 std::shared_future。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


// std::promise + std::future
void work(..., std::promise<int> work_promise) { // void, set_value()
 work_promise.set_value(xxx);
}

std::promise<int> work_promise;
std::future<int> work_future = work_promise.get_future();
std::thread work_thread(work, ..., std::move(work_promise));
// std::promise<int> &.., std::ref()

// std::async + std::future
std::future<int> future_ = std::async(func, [args]); // func -> int

// std::packaged_task + std::future
std::packaged_task<int(int,int)> task_(func); // func(int, int) -> int
std::future<int> future_ = task_.get_future();
std::thread thread_(std::move(task_), int, int);

auto ret = future_.get();
thread_.join();

// std::shared_future
std::shared_future<int> future_ = promise_.get_future();
// 在不同线程多次使用 future_

cppreference std::promise

C++之future和promise - PKICA - 博客园

C++ 并发三剑客future, promise和async | 恋恋风辰的个人博客

虽然讲了很多，不过只要用一点点就行了。

Task #3 - Buffer Pool Manager

主要调试的点：

（其实跟着 test case 就能出来）

Frame 和 Page 的数据同步问题
同一个 Frame，读写的同步问题
逐出状态是跟着 frame_id 走的，构建时需要重置下
在 frame 的访问次数小于 k 时的比较方式和网页描述疑似不一致，是按照 FIFO 的方式？
就算是 assert 有使用到需要用锁的参数，也需要包含在锁的范围内，如 LRUKReplacer::SetEvictable。或者只在必要时才调用来缓解（不过应该不算彻底解决，但同时加上也是更合理的写法）。具体也不算搞清楚原因，just work…
试着让 bpm 和 page_guard 的职责分开。
frame 的 rw_latch 需不需要锁。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# discord - p1-20224-fall - Rob c — 2025/4/9 09:05
literally staring at the same deadlock

I think that comment was added later on, and the fall 2024 code looked like this: https://github.com/cmu-db/bustub/blob/01a64ffdbad34b4bf0693096382c44e3107ba690/src/buffer/buffer_pool_manager.cpp

and the comment about taking the page lock was added in this PR https://github.com/cmu-db/bustub/commit/3e933255eff5600b8d083cca73ad583ec9f6e6a4

In the PR for that commit, #800, there's a devastating line:
Note that previously, the buffer pool manager only had unsafe flush methods.

Which imo seems like pretty good confirmation that we're not supposed to lock.

感觉是错哪改哪，后续还应该再去整理一遍的样子。

提交结果

Leaderboard 顺带贴一下吧，还没有做额外修改，也还没做 bonus 部分。

『学习笔记』CMU 15-445 (2024 fall) Homework #1 - SQL

Sat, 06 Sep 2025 06:28:22 +0000

Homework #1 - SQL

封面来源：@psychoron

Homework #1 - SQL | CMU 15-445/645 :: Intro to Database Systems (Fall 2024)

用 duckdb 生成的结果，如果有 ' 单引号，会被双引号框起来，导致和 sqlite3 的结果不一致。

可手动去除或都用 sqlite3 跑。

同时可以使用 .mode 等命令，使得 duckdb 的输出格式和 sqlite 一致。

逃了，写 Q5 写得头晕，Q1 - 4 还是完成了，感觉已经起到基础锻炼效果了，基本都在翻 note / 问 ai / 做完看上一个的参考答案 = =

后面两个理清然后实现 sqlite 的版本。

中间遇到 diff 因为 LF 和 CRLF 的区别而显示不一致（（

具体的做法感觉也不用多说，就贴下代码吧。（Homework，官方有放 sol，所以也应该是允许的）

其他的作业因为是纸质，就不单独贴文章了。

q1_sample.sqlite.sql

1

SELECT DISTINCT(name) FROM medal_info ORDER BY name;

q2_successful_coaches.sqlite.sql

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


SELECT co.name, COUNT(*)
FROM coaches co
JOIN (
 SELECT m.winner_code, m.discipline, a.country_code
 FROM medals m
 JOIN athletes a ON m.winner_code = a.code
 UNION ALL
 SELECT DISTINCT m.winner_code, m.discipline, t.country_code
 FROM medals m
 JOIN teams t ON m.winner_code = t.code
) winners ON co.discipline = winners.discipline AND co.country_code = winners.country_code
GROUP BY co.code
ORDER BY COUNT(*) DESC, co.name ASC
;

q3_Judo_athlete_medals.sqlite.sql

1
2
3
4
5
6
7
8


SELECT DISTINCT a.name, count(m.winner_code)
FROM athletes a
LEFT JOIN teams t ON a.code = t.athletes_code
LEFT JOIN medals m ON m.winner_code = a.code OR m.winner_code = t.code
WHERE a.disciplines LIKE '%Judo%'
GROUP BY a.name
ORDER BY count(m.winner_code) DESC, a.name
;

q4_Athletics_venue_athletes.sqlite.sql

 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
26
27
28
29
30
31
32
33
34
35
36


WITH p AS (
 SELECT *
 FROM athletes
 WHERE code in (
 SELECT DISTINCT participant_code
 FROM (
 SELECT participant_code
 FROM results r
 LEFT JOIN venues v ON r.venue = v.venue
 WHERE v.disciplines LIKE '%Athletics%' AND participant_type = 'Person'
 UNION
 SELECT athletes_code AS participant_code
 FROM teams t
 WHERE code IN (
 SELECT participant_code
 FROM results r
 LEFT JOIN venues v ON r.venue = v.venue
 WHERE v.disciplines LIKE '%Athletics%' AND participant_type = 'Team'
 )
 )
 )
)

SELECT p.name, p.country_code, p.nationality_code
FROM p
LEFT JOIN (
 SELECT code, c.Latitude cLatitude, c.Longitude cLongitude
 FROM countries c
) c1 ON p.country_code = c1.code
LEFT JOIN (
 SELECT code, c.Latitude nLatitude, c.Longitude nLongitude
 FROM countries c
) c2 ON p.nationality_code = c2.code
WHERE cLatitude IS NOT NULL AND cLongitude IS NOT NULL AND nLatitude IS NOT NULL AND nLongitude IS NOT NULL
ORDER BY (cLatitude - nLatitude) * (cLatitude - nLatitude) + (cLongitude - nLongitude) * (cLongitude - nLongitude) DESC, p.name
;

q5_top5_rank_country_per_day.sqlite.sql

 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
26
27
28
29
30



WITH t AS (
 SELECT code, country_code
 FROM teams
 GROUP BY code, country_code
), cr AS (
 SELECT code,
 RANK() OVER (ORDER BY c."GDP ($ per capita)" DESC) gdprk,
 RANK() OVER (ORDER BY c.Population DESC) poprk
 FROM countries c
)

SELECT date, ccode, app, gdprk, poprk
FROM (
 SELECT *, ROW_NUMBER() OVER (PARTITION BY date ORDER BY app DESC, ccode) as rn
 FROM (
 SELECT *,
 CASE WHEN t.country_code IS NOT NULL THEN t.country_code ELSE a.country_code END AS ccode,
 COUNT(rank) as app
 FROM (
 results r LEFT JOIN t ON r.participant_code = t.code
 LEFT JOIN athletes a ON r.participant_code = a.code
 )
 WHERE rank <= 5
 GROUP BY date, ccode
 )
) ranked, cr
WHERE rn = 1 AND cr.code = ranked.ccode
ORDER BY date
;

q6_big_progress_country_female_teams.sqlite.sql

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39


with t as (
 select code, country_code from teams group by code, country_code
),
paris_medals as (
 select t2.country_code as country_code, count(t2.country_code) as medal_number
 from
 (select
 t1.medal_code,
 case when t1.country_code is not null then t1.country_code else athletes.country_code end as country_code
 from
 (select * from medals left join t on medals.winner_code = t.code) as t1
 left join athletes on athletes.code = t1.winner_code
 ) as t2,
 medal_info mi
 where t2.medal_code = mi.code and mi.name = 'Gold Medal'
 group by t2.country_code
 order by medal_number desc
),
cs as (
 select
 paris_medals.country_code as country,
 paris_medals.medal_number - tokyo_medals.gold_medal as progress
 from tokyo_medals, paris_medals
 where paris_medals.country_code = tokyo_medals.country_code
 order by progress desc
 limit 5
)

select country_code, progress as increased_gold_medal_number, tcode
from (
 select *, teams.code as tcode
 from athletes
 JOIN teams ON teams.athletes_code = athletes.code
 JOIN cs ON teams.country_code = cs.country
 group by teams.code
 having sum(1 - gender) = 0
 )
order by progress desc, country, tcode
;

『学习笔记』CMU 15-445 (2024 fall) Project #0 - C++ Primer

Wed, 03 Sep 2025 05:33:04 +0000

CMU 15-445 (2024 fall) Project #0 - C++ Primer

封面来源：@doggo_1d34

Project #0 - C++ Primer | CMU 15-445/645 :: Intro to Database Systems (Fall 2024)

引一个 C++ 多线程的 slide ，过了一遍，感觉不错。

再引一些之前一直没学的 GDB，远古经典基础使用 gdb Tutorial 、近期进阶使用 GDB Tutorial: Essential GDB Tips to Learn Debugging 、大神表演 CppCon 2015: Greg Law " Give me 15 minutes & I’ll change your view of GDB" - YouTube 。

cmu-db/15445-bootcamp 来作为现代 C++ 特性的学习也很不错。

提供的视频很好 video 。

简单说下 HLL (HyperLogLog) 的算法原理：

伯努利原理，丢硬币的场景，00..01 的情况；

总共丢 n 次，丢 k 次第一次出现 1 的情况，最大一次是 ${k_{max}}$，那按照概率 $n = 2^{k_{max}}$；

回到我们要做的问题，是估计总共集合大小，hash 成 01串，一个 hash 算一个 k，然后统计 k_max 估计；然后，为了降低误差，采用分桶 bucket ，随机分配给多个统计 $k_{max_i}$；

然后求调和平均（缓解极端值），最后乘分桶数，再乘修正参数，是估计值。

分桶这一部分，把一段 01 作为选择桶的参数，然后剩余的 01 算 k。

（还有许多别的修正）

可以想到这个算法在数量少的时候，误差大，所以在大数据场景比较合适。

Task #1

概念上，Left most one 是高位来的，需要统计到 1 这一位，most significant bit，即高位。

位运算左移 / 右移位数大于被操作数的位数时，是 ub (undefined behavior)，依赖编译器的处理，一般是取余、移动，但仍需要避免。

当使用 bitset 时，则是全 0，移动补 0 的处理。

测试时，注意删掉 DISABLED_ 前缀，如 DISABLED_BasicTest1 变成 BasicTest1。

在测 Task #2 时，也可以把 Task #1 中耗时的测试重新加上 DISABLED_。

Task #2

开始一直卡在不清楚各个部分的意义先列下我看到的帮助我理解的资料 / 聊天记录 / 注释，

再简单讲讲 Presto’s HLL 中的 dense layout implementation 的算法原理：

主要参考 HyperLogLog in Presto: Faster cardinality estimation - Engineering at Meta （介绍了算法的发展历程）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# discord - p0-2024-fall - vittilad — 2024/9/4 18:34

1. Count the zeros from the right (this is the Rj in the cardinality computation). Also find the dense bucket index.

2. Reconstruct the curently stored Rj for the bucket. (See step 4 how to do). Compare to determine if you need to overwrite the stored bucket value.

3. Store the 4 least significant bits of Rj binary representation in the dense array (and the 3 bits remaining in the overflow but only if they are not all zero, overflow bucket is a map from dense bucket index to thos 3 bits)

4. When computing cardinality, you need to reconstruct the Rj from the dense/overflow storage. The 3 lower bits come from dense bucket and if there is an entry for the bucket index in overflow bucket you need to that into account.

# discord - p0-2024-fall - shengdao - 2024/12/15 11:00
According to my understanding, in the presto implementation of HLL, the high p bits are taken as the common bucket number, recorded as bucket_index. Take the LSB as the value. If the LSB exceeds the bucket width (DENSE_BUCKET_SIZE), it needs to be placed in the overflow bucket. The high 3 bits (OVERFLOW_BUCKET_SIZE) are placed in the overflow bucket and stored in the form of (bucket_index,xxx). The remaining low 4 bits (DENSE_BUCKET_SIZE) are placed in the corresponding common bucket. When calculating the cardinality, traverse densebucket. If there is a corresponding value in the overflow bucket, take the maximum value of the two and calculate according to the formula to obtain the cardinality.

If my understanding is correct, when calculating the cardinality, CONSTANTmm/sum, the minimum sum can be about 2^(-15), and it will not calculate such a large cardinality, just like where I made a mistake. I would like to ask, what are the mistakes and omissions I made?

# discord - p0-2024-fall - EvanHuang — 2024/12/21 01:13
you are supposed to combine bits from dense and overflow into the original number

注释中，dense_bucket_ Structure holding dense buckets (or also known as registers)。

~~应该好好读注释的，我卡了好久 QnQ~~

（不保证正确，欢迎修正）

n_leading_bits 仍然和 Task #1 一致，是用于桶编号的位数。

桶的内容存储有区别，应该是考虑到大多数的值 LSBs 的 0，是比较小的，即 DENSE_BUCKET_SIZE 就够了。

然后对于超出 DENSE_BUCKET_SIZE 的部分，使用哈希映射分配 OVERFLOW_BUCKET_SIZE，显然就足够最大 64 位 0 了。

所以是为了节省一点空间。（？）

提交结果

『学习笔记』CS149 (2024)

Sat, 30 Aug 2025 06:00:56 +0000

CMU 15-418/15-618 X Stanford CS149: Parallel Computer Architecture and Programming

封面来源：@toutenkou10105

15-418 Watch lecture video of 2016 spring and do assignments of 2018.

CS149 Watch lecture video of 2023 spring and do assignments of 2024.

[!TIP]

做 PA3 的时候，发现还是对照着做好一些，转向看 CS149 的 slides。事实证明，有对应的，先看对应的；有新的，看新的。

Why Parallelism? Why Efficiency?

通信开销不能忽视，导致不能达到理想的加速比。

负载不平衡，负载少的等待负载多的。

Themes：

设计、编写并行算法，并行思维，
了解底层硬件特性
efficiency 高效 ≠ 快，不同的应用场景看法不一样。

Insttuction Level Parallelism (ILP) 指令级并行

单核处理，需要按照程序计数器 PC 串行运行，而实际上，不是所有指令都有严格前后依赖关系，可以同时运行。

通常的程序，ILP不会超过4,同时，虽然晶体管数量能以摩尔定律增长（之前），时钟频率瓶颈，当晶体管中都有不小的电容，此时要提高频率就需要增大电压，高电压，高发热，高能耗，就提不上去了。

Power wall

$\text{Dynamic power} \propto \text{capacitive} \cross \text{voltage}^2 \cross \text{frequency} $

单指令流到达性能提升瓶颈，发热、能耗，ILP通常不能超过 4 倍；

调度、通信开销、负载均衡，使得不能达到最高的加速比

A Model Multi-Core Processor

Part 1: parallel execution

处理器，抽象组件：取指令、译码，执行指令，执行上下文。

superscaler execution 超标量执行，在指令流中，两条指令是独立的，处理器发现并并行处理。

并不是真正意义上的并行，可能采用 pipeline 流水线技术。

快速单指令流的技术：内存预取、分支预测、乱序执行 Out-of-Order Execution, OoOE。

乱序执行，Instruction Window 指令窗口，译码后先放入指令窗口，指令准备所需数据就绪就执行；有序提交，Re-order Buffer 重排序缓冲区缓存乱序执行的结果，确保正确顺序更新。

这些技术虽然能加速，但也占据了处理器的很大空间，需要不少成本。

多核处理器如果遇到单指令流程序，不能加速。

标量程序与向量处理器，并不能加速，需要对应，SSE、AVX 指令，是 SIMD 指令。

多核和SIMD是正交的，可以结合。

多核、多线程、多核执行与SIMD执行，有区别，SIMD 需要共享指令流。

现代的非朴素的编译器，只有在判断条件符合的时候，才会尝试给执行里面的内容。

术语 Terminology

Instruction stream coherence 指令流一致性

一些列不同的逻辑序列能共享相同的指令流，有指令流一致性，在 SIMD 架构下运行的很好。
Divergent execution 发散执行

缺乏一致性。
cache coherence 缓存一致性

SIMD on CPUs，显式的。

SIMD on GPUs，隐式的，更高层级的抽象。

描述机器，X cores, Y SIMD ALUs per core (SIMD width)

$\text{FLOPS} = \text{Frenquency(Hz)} \cross \text{Cores} \cross \text{SIMD width} \cross \text{MAD}$

A核B宽SIMD 与 B核A宽SIMD：指令流在 8 条一组下的一致性，可能不如 4 条一组。

总结

若干并行运算的方式：

Multi-core，多核，多处理核

thread-level 线程级并行（不同指令流在不同核上）

软件决定什么时候创建线程 e.g. pthreads
SIMD，多ALUs，被同一条指令流控制（within a core）

为 data-parallel 数据集并行设计，控制的开销被 ALUs 均摊

向量化被编译器（显式SIMD）、runtime 运行时完成。

需要被说明，或者需要被高级编译器的循环分析
Superscalar，超标量，利用一条指令流的 ILP 指令级并行(within a core)

硬件自动、动态的并行化。

超标量架构的CPU核心本身在一个时钟周期内就能执行多条指令。

（增加资源来提高峰值计算）

Part 2: accessing memory

术语，Terminology

Memory latency，内存延迟

内存请求的总时间，存/取。

latency 延迟是衡量某时间所需时间长短的指标。

e.g. 更快的车、更高的限速标准。
Memory bandwidth，内存带宽

bandwidth 带宽是单位时间内发生多少事情的指标。

e.g. 增加车道。

（两者的相关性取决于重叠处理程度）

stalls，在有依赖先前的指令的时候，处理器需要停顿。

比如，内存读流水线并行，可以提高带宽，但因为对比很长的读取周期，延迟可能没有太多变化。

cache，把降低内存加载的延迟，length of stalls（reduce latency）

prefetch，减少 stalls（hides latency）

用 multi-threading 多线程来隐藏 stalls 停顿，切换线程；各自的寄存器组，对应各自的执行上下文，即可以在同一处理器下运行多条指令流。

缓解等待耗时长的操作（e.g. 内存访问），处理器的空闲时间变少了，处理器性能发挥得更加充分。

和 OS 的切换概念是相同的，机制是不同的，如果让 OS 来管理这个切换，开销大。

问题：上下文存储空间是有限的，Trade off。

更多但更小的上下文（更强的延迟隐藏能力）

更少但更大的上下文（更大的 L1 cache）

没有增加计算资源，提高了高效利用资源的能力。

这种模式有多个不同的版本：

Interleaved multi-threading (a.k.a. tmporal multi-threading) 交叉多线程 / 时间多线程

前面提到的技术
Simultaneous multi-threading (SMT) 同时多线程 / 同步多线程

每个时钟周期，核心从多个线程中选择指令去在 ALU 上运行

superscalar 的设计的扩展

e.g. Intel Hyper-threading (2 threads per core)

多线程的代价，假定 cache 没用，不是降低延迟，是通过做别的事情来隐藏延迟。

这也是 GPU 每个核心有很强的计算能力、很多线程，但是只有不大的缓存。

CPU 的每个核心有两个线程。

CPU 的设计是为了降低延迟；GPU 的设计是精细设计、减小 cache 体积，使得能集成大量的 ALU 来计算。

一个 Warp 的完整上下文，实际上是：

1 个程序计数器 (PC) 和 32 组通用目的寄存器 (General-Purpose Registers, GPRs)，每个线程独享一组。

48 个交叉 warp 是 48 个执行上下文。

ALU 运行在两倍于芯片其他部分的时钟频率，所以，相当于是 32。

这个是 hot clocking (shader clock)，但因为能耗太高，下一代架构就砍掉了（x

思维实验

是不是一个好的并行程序。

pros: 可 SIMD，可利用多核，不可以隐藏延迟（？）

cons: 所需的内存带宽太大了，每个计算所产生的内存访问需要大大超出了现在的计算机设计。

实际上，由于内存带宽限制，在 CPU 与 GPU 上跑得差不多。

一个周期的 MADs $Core \cross SIMD \ function\ units = 15 \cross 32 = 480 $

一些术语：

Multi-core processor
SIMD execution
Coherent control flow
Hardware multi-threading
- Interleaved multi-threading
- Simultaneous multi-threading
Memory latency
Memory bandwidth
Bandwideth bound application
Arithmetic intensity

（高效利用资源）

Parallel Programming Abstractions

Abstraction vs. implementation

task abstraction

Hyper-threading，超标量 + 多线程。

ISPC gang abstraction by SIMD on one core, programming instances

不同的映射方式 map，抽象的理解方式和实际的执行方式的不同。

实际不同实例是一起执行的，所以第一种才是连续的内存访问。

ISPC 只涉及到 SIMD 的实现，不涉及到多核处理。

在单个执行线程内，利用单个执行上下文，通过 SIMD 指令完成操作。

不能在 ISPC 函数中调用 ISPC 函数。

ISPC 归约求和，reduce_add()，

spawn gang, tasks。

向上、向下表达的层是什么？

Three models of communication (abstractions) 通信模型抽象

Shared address space

共享地址空间通信模型，抽象化共享内存地址空间。

线程之间通过读/写共享变量来通信。

同步原语 e.g. locks，也是通过共享变量实现的。

如果想要放很多的核心，很容易产生瓶颈，所以出现设置分区，Non-uniform memory access (NUMA)，比如 cache。

Message passing

消息传递模型，线程操作自己的私有地址空间，通过显式的收/发信息来通信。

Data-parallel

对数组中的元素执行同样的操作，如 SPMD 编程（ISPC），集合中的元素是独立的。

stream programming 流式编程

优点：如上图，从 read - operate 1 - write - read - operate 2 - write 变成 read - operate 1 & 2 - write，减少了内存带宽的压力。

（给定相关信息，编译器能够优化）

缺点：需要引入新的操作符。

数据流操作：分散scatter和聚集gather。

cache 命中问题？所以，这样的指令是 costly 的。

一段代码意味着什么，程序语义是什么，怎么实现的。

Parallel Programming Basics

创建并行程序：分解Decomposition, 分配Assignment, 编排Orchestration, 映射Mapping。

分解 Decomposition

分解不一定是静态的，创建至少足够的任务去让执行单元繁忙。

关键，独立identifying dependencies。

阿姆达尔定律 Amdahl’s law：

需要顺序执行的部分，s，$\text{speedup} \le \frac{1}{s + \frac{1-s}{p}}$。

程序员需要声明哪些部分是独立的。

分配 Assignment

在 ISPC 的例子中，使用 foreach比手写 programIndex与 programCount要更有可移植性，因为更高层级的抽象可以让编译器根据硬件去选择优化。

系统上创建线程的开销，不可忽视，特别是创建的线程数很多的时候。

一般创建线程数就是执行上下文的总数，然后作为 worker pool，用 next_task 等。

编排 Orchestration

略，后续课程具体讲。

包括结构化通信、同步、组织数据结构、安排任务。

减小通信/同步开销，保持局部性等。

映射 Mapping

映射"threads"(“workers”)到硬件执行单元。

系统 OS，e.g. pthread to HW execution context
编译器 compiler，e.g. ISPC program instances to vector instruction lanes
硬件 hardware，e.g. CUDA thread block to GPU cores

用 Gauss-Seidel 解决偏微分方程 PDE。

从左上至右下，每个元素取十字相邻的五个元素（包括自己）的均值。（是直接利用最新版本的数据更新的）

如果强行要求并行版本的结果与串行执行版本一致，我们找到的独立/并行的元素是对角线，多轮迭代同时进行，仍然效果没有那么好。

改变算法执行顺序，更加适合并行化（尽管会带来少许结果的不同）。

打破原本的依赖关系。

交替执行红黑块。

wait <=> barrier，barrier(myBarrier, NUM_PROCESSORS)都需要到，才会继续运行，尽可能减少 barriers。

因为不少应用的的解法来自统计计算，所以可以去为了提高并行度，而降低些准确性。

需要通信的情况。

编排 Orchestration 使用花括号、系统函数。

Part 1: Work Distribution and Scheduling

核心目标（其中有冲突）：

均衡负载
减少通信（stalls）
减少额外工作（overhead）

建议一、总是先实现最简单的解决方法，再测试性能，判断是否需要做得更好。

Balancing the workload

static assignment

静态分配，简单、不会有额外运行时的开销。

当工作的花销和任务的数量是可预测的时候，可以去提前想出好的分配方案。

就算每一份工作不是平衡的，只要是可预测的，也可以提前调度。

“semi-static” assignment

较近的未来是可预测的，如自适应网络。

分配方案在重新调整的时候是静态的。

（重建分配是静态的）

dynamic assignment

在运行时确定，lock。

控制同步的开销，增大任务粒度（一次通信做更多的事情）

均衡任务大小（均衡负载和最小化分配开销之前）

优化任务调度（把大任务也切成小任务来调度、可能增加同步开销，关注量而非数量调度、先分配大任务）

分布式队列降低同步开销（从别的任务队列中「偷」任务）

有依赖的任务队列？

Schedule fork-join parallelism

大任务分解成若干个小任务并行执行，然后将这些小任务的结果合并，分治。

1
2
3
4
5
6
7


// Clik Plus（C++ 扩展，MIT，公开标准）
// 函数并行的抽象
clik_spawn foo(args);
clik_spawn bar();
clik_spawn fizz();
buzz();
clik_sync;

抽象层面想好了，具体实现的话，如果为每一个 cilk_spawn 创建一个线程， cilk_sync 使用堵塞，显然会有很重的线程创建开销。

具体地，我们可以使用线程池的方式实现。

Child Stealing vs Continuation Stealing

续体优先（Run continuation first, child stealing）：

BFS
这种策略是让父线程继续执行 cilk_spawn 之后的代码（在此例中为 bar();），而将 foo() 排入可执行任务队列，以供当前线程或其他线程稍后执行。
优点：父线程继续执行可能减少上下文切换的开销，并利用现有的局部性。
缺点：如果 foo() 很重要或者非常耗时，推迟其执行可能会影响程序的整体性能。

子任务优先（Run child first, continuation stealing）：

DFS
这种策略是立即执行 foo()，而将续体（bar();）加入任务队列，以供其他线程"窃取"（stealing）执行。
优点：这可以快速启动可能的重要或复杂的并行任务，尽快获得其计算结果。
缺点：可能导致父线程的局部数据和状态被挂起，增加了线程间切换的可能性。

steal 从工作队列的队头还是队尾 steal？

设计 deque 双端队列。
当前 thread 从 botttom push/pop，其他 thread 从 top 进行 steal，避免锁同步。

只要空闲，还有任务可以偷，就偷。

堵塞之后的任务不一定还在主线程上运行。

Part II: Locality, Communication, and Contention

shared address space model

抽象的具体实现。

共享地址空间硬件结构

Message passing

send(), recv()。

Arithmetic intensity 计算强度

$\text{Arithmetic intensity} = \frac{\text{amount of computation (e.g., instructions)}}{\text{amount of communication (e.g., bytes)}}$，越高越好。

如果分子是计算的执行时间，这个比率给出了代码平均所需的带宽。

$\frac{1}{\text{“Arithmetic intensity”}} = \text{communication-to-computation rate}$

通信的两个原因：

inherent communication，算法成立的固有的通信

分配得更加合理，可以减少固有通信。
人为造成的（系统的具体实现导致的）

如和 cache 的表现相关、系统的数据转移的最小粒度、实际上只要写入，但是 cache 还是会读入 cache line。

Techniques for reducing the costs of communication

提升空间局部性

改变网格遍历顺序

「块状 blocked」遍历顺序 cache
「融合 fusing」循环

提升计算强度 arithmetic intensity

load / store per arithmetic

（存在功能模块化、代码可读性等的取舍）

Contention 竞争

使用树状结构来减少竞争。

总结

减少通信开销

发更少、更大的消息（均摊开销），具体地，合并小消息成大消息
降低通信延迟

重构代码来利用局部性，硬件上提升通信架构
降低竞争

复制被竞争的资源（本地副本、细粒度锁），错开访问
提升通信/计算重叠

异步通信，硬件上流水线、多线程、预抓取、乱序执行，并发性大于执行单元数量

总是从最简单的并行实现开始，再去测量你所达到的性能。

性能分析策略

确认你的性能是被计算、内存带宽、内存延迟、同步限制了？

“high watermarks”：实际上你最好能做到多少，距离最好的情况差多少？

Roofline model

屋顶线模型 - X-axis 计算强度、Y-axis 最大可获得的指令吞吐量

建立 high watermarks

增加不涉及内存的命令

如果执行时间线性增长，代码瓶颈是指令速率。
去除大部分计算，读取相同的数据

执行时间如果没有降低多少，则可能是内存瓶颈。
把所有的数组访问变成 A[0]

变快很多的话，考虑提高数据访问局部性。
去除所有原子操作 / 锁

如果快了很多（保持相同的工作量），瓶颈在同步开销。

使用 profilers / performance monitoring 工具

如 instructions completed, clock ticks, L2/L3 cache hits/misses, bytes read from memory controller, etc.

1
2
3
4
5
6
7
8


// Intel's Performance Counter Monitor Tool, C++ API
PCM *m = PCM::getInstance();
SystemCounterState begin = getSystemCounterState();
// code to analyze goes here
SystemCounterState end = getSystemCounterState();
printf(“Instructions per clock: %f\n”, getIPC(begin, end));
printf(“L3 cache hit ratio: %f\n”, getL3CacheHitRatio(begin, end));
printf(“Bytes read: %d\n”, getBytesReadFromMC(begin, end));

理解任务规模问题

绝对表现（时间、每秒操作数），加速比、高效（每面积、钱、瓦）

陷阱：固定任务规模的加速比

不同规模，相同算法的表现不同。

（如前面的 2D 分配方式，在 N 小 P 大的时候，反而可能不如原本最差的版本）

超线性的加速比（对 cache 合适的配置）

所以，不同任务规模、不同并行规模在不同任务上有很大的不同。

load balance, overhead, arithmetic intensity, locality of data access
只用固定的任务大小来测试一台机器的方法是很有问题的。

过小的任务，并行开销大于并行好处；

未能充分利用大机器的优势。

General program optimization tips

Measure, measure, measure… 测量评估
Establish high watermarks 找到瓶颈
意识到规模问题，任务是不是很好的匹配机器了？

GPU Architecture and CUDA Programming

Graphics 101 + GPU history (for fun)

为了更好的渲染图形。

图形学的关键要素：顶点，基础图形（如线、三角形），片段，像素。

输入一系列三维顶点；
计算在二维屏幕的位置；
生成基础图形集合；
分割成片段，变成新的二维顶点集合；
计算颜色。

OpenGL API，调整材质的光泽等等。

graphics shading language

（粗糙的hack使用）

GPU-based 的科学计算

由于 CPU 的速度发展相对缓慢，开始把图形处理器用于科学计算。

GPGPU 通用图形处理器 2002-2003

（编译器）

Brook stream 编程语言 2004

编译成 OpenGL 命令。

GPU ccompute mode

不需要看作图形操作流水线的设备，而是作为大型数据并行的处理器。

在 2007 年之前，只能进行特殊的 ISA 操作。

NVIDIA Tesla with CUDA 架构 2007

硬件上实现了数据并行

由最初开发 Brook 编译器的 PhD 移植到了 GPU 上。

“C-like” 语言，相对底层。

OpenCL 是 CUDA 的开放标准版本。

CUDA 只能在 NVIDIA GPU 上，OpenCL 可以在 CPU / GPU。

CUDA program

特别的 Thread 含义在 CUDA 编程语言的体系中，就如同 Program Instance 在 ISPC 的体系中的特殊语义，不等同 pThread 在 CPU 上。

层次化的并发线程集合模型。

二、三维，有出于一维确定各个维度，除法的开销大的考虑。

线程的调度在硬件集成。

warp，线程束（CPU 类比 32-SIMD，GPU 32 独立执行上下文共享一条指令）

如果要求的线程数，超过了总可能的块内的线程数，无法编译，因为 __syncthreads()会形成死锁，等待。

创建直方图，不同块要访问同一个内存地址。

哪个是有效的代码。

Data-Parallel Thinking

对序列数据的操作。

Map 映射

逐一对 $seq_a$ 每一位应用 $func()$ 输出到等长的 $seq_b$。

Parallelizing map

以任意顺序应用，相互之间没有依赖。

Fold 归约（fold left，从左到右）

将二元操作依次应用。

Parallel fold

无关运算合并先后的。

Scan 扫描

scan inclusive

做前缀（二元操作），包含自己。

scan exclusive

做前缀（二元操作），不包含自己。

Parallel Scan

无关运算合并先后的。

伪代码：

多个小块内部处理，再根据块 base 重建。

Parallel Segmented Scan

操作序列的序列。

[seq1, seq2, seq3]

同时传入长短不定的序列，都需要操作，比如 scan_exclusive。

如果不统一调度处理，很容易出现负载不均衡的情况。

增加开始标志 “start-flag”。

示意图：

伪代码：

应用场景：

稀疏矩阵乘法

Gather / scatter 聚集 / 分发

gather(index, input, output)

output[i] = input[index[i]]
scatter(index, input, output)

output[index[i]] = input[i]

在某些条件下，可以把 Scatter 转化为 Gather

假设索引中的元素是唯一的，并且索引中的所有元素都被引用（scatter = sort + gather）。

如果上面的条件不满足的时候（scatter = sort + map + gather）。

这种多个的组合在 find_repeats 中也能见到。

更多序列操作

Group by key
Filter
Sort

应用场景：

N 体问题
并行直方图

CUDA 中的一个高效并行算法库：Thrust

Distributed Data-Parallel Computing Using Spark

集群 Cluster 上的数据并行。

Scalable，可规模化
Fault-tolerant，容错
Efficient，高效

$\text{System MTTF (Mean Time to Failure)} = \frac{1}{\sum_{i=1}^{n}{\frac{1}{\text{MTTF}_i}}}$

Storage System 存储系统

如果节点 node 出现故障，如何持久地存储数据？

Distributed File System 分布式文件系统

提供全局文件命名空间 Global file namespace，如 Google GFS, Hadoop HDFS。

典型使用模式

超大文件
数据很少就地更新
读取 read 和附加 append 是最常见的，如 log 日志。

Distributed File System (GFS)

块服务器 chunk server
- HDFS 中的 DataNodes
- 文件被切分成连续块（常常 64 - 256 MB）
- 每个块都有副本（常常 2 - 3 份）
- 尽量把不同副本放入不同机架
主节点 master node
- HDFS 中的 NameNode
- 存储元数据；常常被复制副本
客户端的文件访问库
- 让主节点找到块（数据）服务器
- 和块服务器直连获取数据

Hadoop Distributed File System (HDFS)

Message Passing Interface (MPI)，实现 Message Passing 模型的接口。

MapReduce

map + reduce (fold) => MapReduce

作业调度的合理性

利用数据局部性，“move coputation to the data”

mapper 作业在包含输入块的节点上运行

reducer 作业在已经有某字段最多数据的节点上运行
解决节点故障

调度器检测作业故障并在新机器上重新运行作业。

因为输入是持久存储的。（分布式文件系统）

调度器在多个机器上复制任务。（降低处理故障产生的开销）
解决慢机器

调度器复制作业到多台机器上。

MapReduce 好处

提供了数据并行的模型，简化了集群编程。

将作业自动划分为 map 和 reduce 任务
局部感知调度
负载均衡
故障恢复、慢机器适应

问题

只支持简单的 map, reduce 编程结构
迭代算法每一次都要从硬盘中读数据

用户需要更复杂、多阶段的应用。

Apache Spark

in-memory, fault-tolerant distributed computing

重用中间数据集的集群规模计算的编程模型。

不把中间数据写回持久分布式文件系统（不高效）

in-memory calculation，容错怎么保证？

复制所有计算

成本高，降低峰值吞吐
检查点 Checkpoint 和回滚 rollback

定期存储到持久分布式文件系统

故障后从上一个检查点开始
维护日志 log 更新

MapReduce

在每步 map, reduce 后，都会建立 checkpoint
函数式结构允许只重启一个 map, reduce 任务，不需要整个程序重启

Resilient Distributed Dataset (RDD) 弹性分布式数据集

Spark 的重要编程抽象

只读记录有序集合（不可变）
RDDs 只能在对持久存储 / 现存 RDDs 进行确定的转换 transformation 时被创建
RDDs 的 Action 操作把数据返回给应用

一次性全读进来，并且在内存中存着，经过几个操作会比在硬盘中占的空间还大。

所以，考虑 loop fusion 和 “streaming”，流式处理，一次处理完一行数据。

能不能进行 fusing，需要看 Narrow dependencies / Wide dependencies （如 groupByKey），即是否不需要和别的节点通信。

使用 PartitionBy 可以控制划分的方法，在一些操作的使用上达到 Narrow dependencies 的效果。

通过血缘谱系 Lineage 来实现弹性 Resilience，运行时系统可以通过 Lineage 重建 RDD 的内容。

Lineage 是 Transformation 的 log，粗粒度，存储高效。

_.persist(RELIABLE) 允许让在长 Lineage 中，设置 checkpoint。

规模化不是终点，COST = “Configuration that Outperforms a Single Thread”。

不仅追求规模化，更要有比单线程更好的效果，即也追求高性能。

Efficiently Evaluating DNNs (Software Solutions)

没太多新东西，特别是先做 PA 回头来看的话。

提到的一些优化方式，神经网络结构优化、算子优化（分块、融合）、压缩模型（低精度、稀疏化、剪枝）。

GPU 为什么是 DNN 的好平台？高计算强度、算力高、高性能库多。

GPU 为什么可能是次优的 DNN 平台？通用部分可能没那么需要。

Hardware Specialization

功耗限制型计算

专用硬件，追求更好的能耗比。

ASIC (Application-Specific Integrated Circuit)

FPGAs (Field Programmable Gate Arrays), Verilog

DSP (Digital Signal Processor)

介绍了一些专用硬件。

降低功耗：专用的处理单元、减少数据移动。

适当考虑重算，多考虑整数运算。

DRAM 的工作逻辑

[ Precharge (PRE, 用于传输的 bit line) + row activate (RAS, 待读取行) ] + column access (CAS)

data pins 利用率低，一个 DRAM 多个 bank 共享一个 data pins 流水线。

DIMM (Dual Inline Memory Module)

Dual-channel memory system 双通道内存

Simpler setup: use single controller to drive same command to multiple channels

DDR (double data rate)

HBM (High-bandwidth memory)，高带宽，高能效，小体积。

内存瓶颈的解决方式：

应用工程师：编程局部性

硬件架构：DRAM 调度、距离更近、计算移到内存中、数据压缩。

Programming Specialized Hardware

TPU - Systolic array 脉动阵列，很有节奏感了。

TMA (Tensor Memory Accelerator)

ThunderKittens, A Simple Embedded DSL for AI kernels

设计原则

16x16 Tile layouts
异步
GPU 协调模式，生产者 - 消费者

MetaPipeline = Streaming Dataflow

PCU: Pattern Compute Unit

PMU: Pattern Memory Unit

AGCU: Address Generator and Coalescing Unit

Programming Specialized Hardware II + Cache Coherence

cache line

Write-Through（写通）：

当应用程序执行写操作时，数据会同时写入缓存和主存储器。

数据一致性，但要写两次。

Write-Back（回写）：

写操作仅更新缓存，并标记为“脏数据”。只有当缓存中的脏数据块即将被另一个缓存块替换时，才会被一次性写入主存储器。

数据不一致，数据丢失风险。

write-allocate，会先将数据块从主内存读取到缓存中再写入；

write-no-allocate，则直接将写入操作执行到主内存，不将数据加载到缓存。

缓存未命中 cache miss 的 3 C：cold, capacity, conflict。

缓存一致性 cache coherence，缓存 cache 和内存 main memory 之间的不同。

单写者-多读者不变量 Single-Writer, Multiple-Reader (SWMR) Invariant

shared cache，简单，但是在 cache 上竞争 contention

write-through 方法，简单，但是其他 local cache 都失效了

write-back 方法，当写入 cache 后缓存只是合法副本的缓存，变成独自 exclusive 的所有权，当别的处理器要读取这个数据时，它要送过去。

“modified” 状态，不需要通知别人，因为它肯定是不合法的。

由 cache controller 来控制。

MSI write-back invalidation protocol

三种状态：

Modified (M): line valid in exactly one cache (a.k.a. “dirty” or “exclusive” state)

Shared (S): line valid in one or more caches, memory is up to date

Invalid (I): same as meaning of invalid in uniprocessor cache

PrRd (read)

PrWr (write)

BusRd: obtain copy of line with no intent to modify

BusRdX: obtain copy of line with intent to modify

BusWB: write dirty line out to memory

Obtain exclusive ownership before writing

BusRdX causes others to invalidate

If M in another cache, will cause writeback

BusRdX even if hit in S - promote to M (upgrade)

只能在 M 状态写入，需要告诉 cache controller，现在独占读入权，要写入，其他不能读。

MESI invalidation protocol

对于常见的读后写，需要两个转换，I ==BusRd=> S ==BusRdX=> M，在不共享的时候也存在。

增加 E (exclusive clean) ，独占权 exclusivity 和所有权 ownership 分离。（合法的副本）

广播 broadcast，不可规模化；

目录 directory，可规模化。

只是发送一致性信息。

$\text{Average Memory Access Time (AMAT) }= \sum_0^n{\text{frequency of access} \cross \text{latency of access}}$

多处理器的 MAT 会增加。

工具：VTune

预期外的通信：伪共享 false sharing

cache 是以 cache line 为单位的。

所以，代码一，实际不同线程之间会反复「竞争」一个线程；

代码二，对 cache line 进行补全，不会「竞争」。

缓存一致性的问题出现的原因是，单位共享地址的抽象与单个存储单位的实现不一致。

基于侦听 snooping-based 的缓存一致性方法，每当有可能影响 cache coherence 的操作，就会广播。

HW，减少 coherence 的开销；SW，警惕人工引入的由一致性协议 coherence protocol 引起的通信。

规模化 scalable 的 cache conherence，使用基于目录 cache coherence 的方法。

Cache Coherence

Memory Consistency

缓存一致性和内存连贯性。

cache coherence 是多副本的一致性；memory consistency 是多个内存操作执行顺序的连贯性（一致性）。

synchronization library / kernel / lock-free ds

Memory coherence defines requirements for the observed behavior of reads and writes to the same memory location.

Memory consistency defines the behavior of reads and writes to different locations (as observed by other processors).

Sequential Consistency

顺序保障，但是为了提高性能，选择重排。

write buffer，放松了 W-R 先写后读。

TSO (Total Store Order)

PSO (Partial Store Ordering)，加锁类似。

these are all valid optimizations if a program consists of a single instruction stream

Weak ordering (WO)

Release Consistency (RC)

同步 synchronization 来挽救。

Fence (memory barrier), read-modify-write/compare-and-swap, transactional memory, …

Intel x86/x64 ~ total store ordering

提供特定的指令去说明，指令不需要保证顺序。

mm_lfence (“load fence”: wait for all loads to complete)

mm_sfence (“store fence”: wait for all stores to complete)

mm_mfence (“mem fence”: wait for all me operations to complete)

ARM processors: very relaxed consistency model

data race free (DRF)

Lock Implementations, Fine-Grained Synchronization and Lock-Free Programming

死锁 Deadlock，正确性，有未完成的任务需要完成，但是没有操作可以进行。

活锁 Livelock，正确性，一直在做无意义的操作， abort and retry。

饥饿 Starvation，公平性，一个任务处理，其他任务没有操作。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# Test-and-set based lock (Atomic)
ts R0, mem[addr]

load mem[addr] into R0
if mem[addr] is 0, set mem[addr] to 1

# x86 cmpxchg
# Compare and exchange (atomic when used with lock prefix)
lock cmpxchg dst, src

if (dst == EAX)
 ZF = 1
 dst = src
else
 ZF = 0
 EAX = dst

线程越多，lock 的 contention 越激烈，时间越长。

Test-and-test-and-set，在 lock free 之前，while 等待；公平性没有保证。

less traffic <=> more scalable

ticket lock，等待 lock free，取票，等 unlock 叫号。

compare and swap

fetch-and-op

Lock-free queue (bound / unbound)

Lock-free stack

CAS (compare_and_swap)

double compare and swap

“读取-尝试-重试”的循环是无锁编程的标志性模式。

while + CAS

无锁是用如原子操作的底层方式来保证线程安全。

Relaxed Consistency + Domain-Specific Programming Systems

relaxed memory consistency

见 Cache Coherence。

DSL (Domain-Specific programming languages)

Halide, for image processing.

不是为新手准备的，提供了一系列的用于优化的原语。

系统搭建的关键，为作业选择合适的再现方式。

Choosing the “right” representations for the job

自然、可靠、性能；调度（呈现成骨架、草图、pipeline 的感觉）

Lizst, PDE’s on meshes.

编译器决定用什么数据结构。

可迁移，CPU, GPU 采用不同的算法。

把握最重要的元素、简单的系统、原语组合。

Transactional Memory

事务内存，另一种同步抽象，声明式 declarative，如 atomic{}。

命令式 Imperative

atomic { } ≠ lock() + unlock()

数据版本控制策略 data versioning policy

Eager versioning (undo-log based)
Lazy versioning (write-buffer based)

Pessimistic Conflict Detection (悲观冲突检测)

“Eager” (主动的)

Optimistic Conflict Detection (乐观冲突检测)

“Lazy” (懒惰的) 或 “Commit” (提交时)

STM (Software Transactional Memory)

Transactions II + Ask Me Anything with Kayvon and Kunle

Hardware transactional memory (HTM)

Data versioning is implemented in caches

Conflict detection through cache coherence protocol

『学习笔记』CS149 (2024): Assignment 5

Wed, 27 Aug 2025 05:58:15 +0000

CS149 (2024): Assignment 5

封面来源：@auhuheben17

相关文章：CS149 Programming Assignment 5 - Big Graph Processing | MizukiCry’s Blog

原始实验材料仓库：stanford-cs149/biggraphs-ec

我的实现仓库：Livinfly/15-418u15-618uCS149u

任务推荐资料：

OpenMP：

OpenMP 3.0 规范

OpenMP 手册

omp parallel_for 自定义 ~~这个长度合适，适合阅读~~

宽度优先搜索 Breadth-first search (BFS)：

Breadth First Search Tutorials & Notes | Algorithms | HackerEarth

Breadth First Search Algorithm | Shortest Path | Graph Theory - YouTube

OpenMP 入门指南 - 知乎

环境

又是无法跑在 MacOS-arm64 上，就算安了 gcc-11，也会提示 ref_bfs.o 无法链接。

1
2
3
4
5
6


# 系统版本
uname -a
lsb_release -a
nvidia-smi
cat /proc/cpuinfo
cat /proc/cpuinfo | grep processor | wc -l

OS: Windows10 - wsl2 (6.6.87.2-microsoft-standard-WSL2) - Ubuntu 22.04.5 LTS
CPU: AMD Ryzen 5 3600 6-Core Processor (6 cores, 12 processors)
GPU: NVIDIA GeForce GTX 1660 super (6 GB, bandwidth 336 GB/s, 192-bit bus), Driver Version: 576.02, CUDA Version: 12.9
Python 3.10.1

Part 1: Parallel “Top Down” Breadth-First Search

学习 omp parallel for 自定义和按照给的提示，只能初步实现下，最外层循环并行，内层共享参数 #pragma omp critical。

后面，学习优化无法并行的更新 new_frontier。

具体地，为每个线程创建一个 buffer，先写到 buffer 中，后续再更新到 new_frontier。

由于需要复写的地址不一样，不会有冲突。

因为没有好好看 OpenMP 的文档，写法有问题。

#pragma omp parallel 会创建线程，在代码块内部就相当于已经有了这些线程，

此时应该用 #pragma omp for 而非 #pragma omp parallel for，

否则嵌套并行，创建很多线程，出现线程数越多，运行越慢的情况。

 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
26
27
28
29
30


// bfs.cpp

void top_down_step(Graph g, vertex_set* frontier, vertex_set* new_frontier,
 int* distances) {
 const int dist_new = distances[frontier->vertices[0]] + 1;
#pragma omp parallel
 {
 Vertex* buffer = new Vertex[g->num_nodes];
 int buffer_size = 0;

#pragma omp for schedule(dynamic, 64)
 for (int u = 0; u < frontier->count; u++) {
 const int node = frontier->vertices[u];
 for (const Vertex *v = outgoing_begin(g, node),
 *v_e = outgoing_end(g, node);
 v < v_e; v++) {
 if (distances[*v] == NOT_VISITED_MARKER &&
 __sync_bool_compare_and_swap(
 &distances[*v], NOT_VISITED_MARKER, dist_new)) {
 buffer[buffer_size++] = *v;
 }
 }
 }
 int idx = __sync_fetch_and_add(&new_frontier->count, buffer_size);
 memcpy(new_frontier->vertices + idx, buffer,
 buffer_size * sizeof(Vertex));

 delete[] buffer;
 }
}

Part 2: “Bottom Up” BFS

尝试去维护未访问的集合，用 unordered_set 但是无法支持 openMP 的并行，转成 vector 后，重复拷贝太花时间了，反而性能下降。

后面又尝试像是 frontier 的滚动，也不行，消耗太大，耗时见测试 unvisit 部分。

最后还是维持朴素做法了。（代码中注释掉相关部分了，见代码仓库）

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68


// bfs.cpp

void bottom_up_step(Graph g, vertex_set* frontier, vertex_set* new_frontier,
 int* distances) {
 const int dist_new = distances[frontier->vertices[0]] + 1;
#pragma omp parallel
 {
 Vertex* buffer = new Vertex[g->num_nodes];
 int buffer_size = 0;

#pragma omp for schedule(dynamic, 64)
 for (int v = 0; v < g->num_nodes; v++) {
 if (distances[v] != NOT_VISITED_MARKER) continue;
 for (const Vertex *u = incoming_begin(g, v),
 *u_e = incoming_end(g, v);
 u < u_e; u++) {
 if (distances[*u] == dist_new - 1 &&
 __sync_bool_compare_and_swap(
 &distances[v], NOT_VISITED_MARKER, dist_new)) {
 buffer[buffer_size++] = v;
 break;
 }
 }
 }

 int idx = __sync_fetch_and_add(&new_frontier->count, buffer_size);
 memcpy(new_frontier->vertices + idx, buffer,
 buffer_size * sizeof(Vertex));

 delete[] buffer;
 }
}

void bfs_bottom_up(Graph graph, solution* sol) {
 vertex_set list1;
 vertex_set list2;
 vertex_set_init(&list1, graph->num_nodes);
 vertex_set_init(&list2, graph->num_nodes);

 vertex_set* frontier = &list1;
 vertex_set* new_frontier = &list2;

 for (int i = 0; i < graph->num_nodes; i++)
 sol->distances[i] = NOT_VISITED_MARKER;

 frontier->vertices[frontier->count++] = ROOT_NODE_ID;
 sol->distances[ROOT_NODE_ID] = 0;

 while (frontier->count != 0) {
#ifdef VERBOSE
 double start_time = CycleTimer::currentSeconds();
#endif

 vertex_set_clear(new_frontier);
 bottom_up_step(graph, frontier, new_frontier, sol->distances);

#ifdef VERBOSE
 double end_time = CycleTimer::currentSeconds();
 printf("frontier=%-10d %.4f sec\n", frontier->count,
 end_time - start_time);
#endif

 // swap pointers
 vertex_set* tmp = frontier;
 frontier = new_frontier;
 new_frontier = tmp;
 }
}

Part 3: Hybrid BFS

在 frontier 点少的时候使用 top down。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39


void bfs_hybrid(Graph graph, solution* sol) {
 vertex_set list1;
 vertex_set list2;
 vertex_set_init(&list1, graph->num_nodes);
 vertex_set_init(&list2, graph->num_nodes);

 vertex_set* frontier = &list1;
 vertex_set* new_frontier = &list2;

 for (int i = 0; i < graph->num_nodes; i++)
 sol->distances[i] = NOT_VISITED_MARKER;

 frontier->vertices[frontier->count++] = ROOT_NODE_ID;
 sol->distances[ROOT_NODE_ID] = 0;

 while (frontier->count != 0) {
#ifdef VERBOSE
 double start_time = CycleTimer::currentSeconds();
#endif

 vertex_set_clear(new_frontier);
 if (frontier->count < graph->num_nodes * 0.1) {
 top_down_step(graph, frontier, new_frontier, sol->distances);
 } else {
 bottom_up_step(graph, frontier, new_frontier, sol->distances);
 }

#ifdef VERBOSE
 double end_time = CycleTimer::currentSeconds();
 printf("frontier=%-10d %.4f sec\n", frontier->count,
 end_time - start_time);
#endif

 // swap pointers
 vertex_set* tmp = frontier;
 frontier = new_frontier;
 new_frontier = tmp;
 }
}

测试

因为共用一个测试，所以是先用串行版本实现所有 Part，然后再初步调优。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


# ./bfs ../all_graphs/rmat_200m.graph
# 串行 6.41

# v1
----------------------------------------------------------
Your Code: Timing Summary
Threads Top Down Bottom Up Hybrid
 1: 6.30 (1.00x) 8.55 (1.00x) 2.74 (1.00x)
 2: 3.28 (1.92x) 4.74 (1.81x) 1.44 (1.91x)
 4: 2.12 (2.96x) 3.30 (2.59x) 0.92 (2.97x)
 8: 1.34 (4.71x) 2.14 (4.00x) 0.59 (4.64x)
 12: 1.12 (5.61x) 1.80 (4.75x) 0.49 (5.58x)
----------------------------------------------------------
Reference: Timing Summary
Threads Top Down Bottom Up Hybrid
 1: 6.58 (1.00x) 5.71 (1.00x) 3.11 (1.00x)
 2: 3.47 (1.90x) 3.10 (1.84x) 1.76 (1.77x)
 4: 2.32 (2.84x) 2.07 (2.75x) 1.14 (2.73x)
 8: 1.59 (4.14x) 1.35 (4.23x) 0.82 (3.79x)
 12: 1.30 (5.08x) 1.18 (4.84x) 0.73 (4.25x)
----------------------------------------------------------
Correctness:

Speedup vs. Reference:
Threads Top Down Bottom Up Hybrid
 1: 1.05 0.67 1.13
 2: 1.06 0.66 1.22
 4: 1.09 0.63 1.23
 8: 1.19 0.63 1.39
 12: 1.15 0.65 1.49

# unvisit
----------------------------------------------------------
Your Code: Timing Summary
Threads Top Down Bottom Up Hybrid
 1: 6.13 (1.00x) 9.63 (1.00x) 2.98 (1.00x)
 2: 3.30 (1.86x) 6.63 (1.45x) 1.66 (1.80x)
 4: 1.94 (3.16x) 4.35 (2.21x) 1.05 (2.83x)
 8: 1.30 (4.71x) 3.05 (3.15x) 0.78 (3.82x)
 12: 1.11 (5.52x) 2.70 (3.57x) 0.69 (4.32x)
----------------------------------------------------------
Reference: Timing Summary
Threads Top Down Bottom Up Hybrid
 1: 6.54 (1.00x) 5.80 (1.00x) 3.07 (1.00x)
 2: 3.47 (1.89x) 3.37 (1.72x) 1.74 (1.77x)
 4: 2.34 (2.80x) 1.89 (3.07x) 1.13 (2.70x)
 8: 1.53 (4.27x) 1.36 (4.26x) 0.81 (3.78x)
 12: 1.30 (5.04x) 1.19 (4.89x) 0.72 (4.27x)
----------------------------------------------------------
Correctness:

Speedup vs. Reference:
Threads Top Down Bottom Up Hybrid
 1: 1.07 0.60 1.03
 2: 1.05 0.51 1.04
 4: 1.21 0.44 1.08
 8: 1.18 0.45 1.04
 12: 1.17 0.44 1.04

打分：

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91


# ./bfs_grader ../all_graphs

Max system threads = 12
Running with 12 threads

Graph: grid1000x1000.graph

Top down bfs
ref_time: 0.0222338s
stu_time: 0.0287536s

Bottom up bfs
ref_time: 0.897488s
stu_time: 1.31878s

Hybrid bfs
ref_time: 0.329699s
stu_time: 0.0294195s

Graph: soc-livejournal1_68m.graph

Top down bfs
ref_time: 0.126574s
stu_time: 0.114126s

Bottom up bfs
ref_time: 0.087241s
stu_time: 0.178334s

Hybrid bfs
ref_time: 0.0658287s
stu_time: 0.0361178s

Graph: com-orkut_117m.graph

Top down bfs
ref_time: 0.131646s
stu_time: 0.11027s

Bottom up bfs
ref_time: 0.0830849s
stu_time: 0.12143s

Hybrid bfs
ref_time: 0.0500944s
stu_time: 0.0197173s

Graph: random_500m.graph

Top down bfs
ref_time: 3.45043s
stu_time: 3.17138s

Bottom up bfs
ref_time: 7.58714s
stu_time: 10.1624s

Hybrid bfs
ref_time: 1.57072s
stu_time: 1.35378s

Graph: rmat_200m.graph

Top down bfs
ref_time: 1.29146s
stu_time: 1.17429s

Bottom up bfs
ref_time: 1.15881s
stu_time: 1.75001s

Hybrid bfs
ref_time: 0.718519s
stu_time: 0.504066s


--------------------------------------------------------------------------
SCORES : | Top-Down | Bott-Up | Hybrid |
--------------------------------------------------------------------------
grid1000x1000.graph | 2.00 / 2 | 2.88 / 3 | 3.00 / 3 |
--------------------------------------------------------------------------
soc-livejournal1_68m.graph | 2.00 / 2 | 1.74 / 3 | 3.00 / 3 |
--------------------------------------------------------------------------
com-orkut_117m.graph | 2.00 / 2 | 2.91 / 3 | 3.00 / 3 |
--------------------------------------------------------------------------
random_500m.graph | 7.00 / 7 | 8.00 / 8 | 8.00 / 8 |
--------------------------------------------------------------------------
rmat_200m.graph | 7.00 / 7 | 7.39 / 8 | 8.00 / 8 |
--------------------------------------------------------------------------
TOTAL | 67.92 / 70 |
--------------------------------------------------------------------------

结语

总之是熟悉了一点点 OpenMP。

『学习笔记』CS149 (2023): Assignment 4

Tue, 26 Aug 2025 06:43:05 +0000

CS149 (2023): Assignment 4

由于 2024 Assignment 4 需要服务器，转做 2023 的了。

封面来源：@hiyualice240

相关文章：CS149 Programming Assignment 4 - Chat149 - A Flash Attention Transformer DNN | MizukiCry's Blog

原始实验材料仓库：stanford-cs149/cs149gpt

我的实现仓库：Livinfly/15-418u15-618uCS149u

任务推荐资料：

环境问题：

ImportError: cs149gpt/module_ref.so: undefined symbol · Issue #2 · stanford-cs149/cs149gpt

我想要请教下此项目环境配置问题是如何解决的呢？ · Issue #1 · BienBoy/cs149gpt

Transformer 的产生动机：

Slide 52 of Lecture 10

What is the intuition behind the attention mechanism?

Transformer Neural Networks: A Step-by-Step Breakdown

How Transformers Work

环境

一开始想在 Mac 上做，但环境存在的不太行，转回 wsl2 了。

OS: Windows11 - wsl2 (6.6.87.2-microsoft-standard-WSL2) - Ubuntu 22.04.5 LTS
CPU: AMD Ryzen 7 6800H (8 cores, 16 logical processors, AVX2 256-bit)
Python 3.10.12

这个任务，using CPU only，不需要 GPU。

官方是服务器，没有给环境，需要自己配一下。

参考 ImportError: cs149gpt/module_ref.so: undefined symbol · Issue #2 · stanford-cs149/cs149gpt

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


conda create -n gpt149
conda activate gpt149
conda install pytorch==2.1.2 torchvision==0.16.2 torchaudio==2.1.2 cpuonly python=3.10 numpy=1.26 ninja tiktoken -c pytorch -c conda-forge
# 上面指定 numpy==1.26 但是如果不降到 numpy 1.x 应该只是警告，如下：
'''
A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.2.6 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.

If you are a user of the module, the easiest solution will be to
downgrade to 'numpy<2' or try to upgrade the affected module.
We expect that some modules will need time to support NumPy 2
'''

# requirements.txt
torch==2.1.2
ninja
# 如果要跑文字生成
tiktoken

Warm-Up: Accessing Tensors

参照 2D Accessor，实现 4D Accessor，4D-tensor 转 1D vector 访问。

这里我直接模仿的写法没什么问题，加乘嵌套的写法 tensor[((x * sizeX + y) * sizeY + z) * sizeZ + b]，看 MizukiCry 的结果是会影响到编译器的优化。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// module.cpp
inline float fourDimRead(std::vector<float> &tensor, int &x, int &y, int &z,
 int &b, const int &sizeX, const int &sizeY,
 const int &sizeZ) {
 return tensor[x * (sizeX * sizeY * sizeZ) + y * (sizeY * sizeZ) +
 z * (sizeZ) + b];
}

inline void fourDimWrite(std::vector<float> &tensor, int &x, int &y, int &z,
 int &b, const int &sizeX, const int &sizeY,
 const int &sizeZ, float &val) {
 tensor[x * (sizeX * sizeY * sizeZ) + y * (sizeY * sizeZ) + z * (sizeZ) +
 b] = val;
 return;
}

测试结果：

1
2
3
4


# python3 gpt149.py 4Daccess

Expected: 0.0008
Result: 0.0008

Part 1: A Simple (But Not So Efficient) Implementation of Attention

简单实现 Attention 模块。

原注释中还给出了写入 0 的例子，难度很友好了。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


// module.cpp myNaiveAttention()

// -------- YOUR CODE HERE -------- //
for (int b = 0; b < B; b++) {
 for (int h = 0; h < H; h++) {
 for (int i = 0; i < N; i++) {
 for (int k = 0; k < N; k++) {
 float QK_val = 0.0;
 for (int j = 0; j < d; j++) {
 float Q_val = fourDimRead(Q, b, h, i, j, H, N, d);
 float K_val = fourDimRead(K, b, h, k, j, H, N, d);
 QK_val += Q_val * K_val;
 }
 twoDimWrite(QK_t, i, k, N, QK_val);
 }
 }

 for (int i = 0; i < N; i++) {
 float sum = 0.0;
 for (int j = 0; j < N; j++) {
 float val = twoDimRead(QK_t, i, j, N);
 sum += exp(val);
 }
 for (int j = 0; j < N; j++) {
 float val = twoDimRead(QK_t, i, j, N);
 val = exp(val) / sum;
 twoDimWrite(QK_t, i, j, N, val);
 }
 }

 for (int i = 0; i < N; i++) {
 for (int k = 0; k < d; k++) {
 float O_val = 0.0;
 for (int j = 0; j < N; j++) {
 float QK_val = twoDimRead(QK_t, i, j, N);
 float V_val = fourDimRead(V, b, h, j, k, H, N, d);
 O_val += QK_val * V_val;
 }
 fourDimWrite(O, b, h, i, k, H, N, d, O_val);
 }
 }
 }
}

测试结果：

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81


# python3 gpt149.py part1

Running Part 1 Test: Naive Unfused Attention

-----RUNNING REFERENCE IMPLEMENTATION-----

STAGE:2025-08-26 08:14:12 3895:3895 ActivityProfilerController.cpp:312] Completed Stage: Warm Up
STAGE:2025-08-26 08:14:12 3895:3895 ActivityProfilerController.cpp:318] Completed Stage: Collection
STAGE:2025-08-26 08:14:12 3895:3895 ActivityProfilerController.cpp:322] Completed Stage: Post Processing
manual attention == pytorch attention True
Manual Execution Time: 0.2422347068786621

------------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 Name Self CPU % Self CPU CPU total % CPU total CPU time avg CPU Mem Self CPU Mem # of Calls
------------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 aten::empty 0.04% 102.000us 0.04% 102.000us 34.000us 5.00 Mb 5.00 Mb
 3
 REFERENCE - NAIVE ATTENTION 98.58% 238.962ms 99.90% 242.154ms 242.154ms 4.50 Mb -1.00 Mb
 1
 aten::zeros 0.09% 207.000us 0.72% 1.740ms 870.000us 4.50 Mb 0 b
 2
 aten::clone 0.12% 290.000us 0.49% 1.187ms 593.500us 1.00 Mb 0 b
 2
 model_inference 0.10% 247.000us 100.00% 242.401ms 242.401ms 512.00 Kb -4.00 Mb
 1
 aten::flatten 0.10% 231.000us 0.35% 840.000us 168.000us 512.00 Kb 0 b
 5
 aten::empty_like 0.02% 53.000us 0.03% 70.000us 70.000us 512.00 Kb 0 b
 1
 aten::empty_strided 0.02% 54.000us 0.02% 54.000us 54.000us 512.00 Kb 512.00 Kb
 1
 aten::zero_ 0.07% 166.000us 0.60% 1.448ms 724.000us 0 b 0 b
 2
 aten::fill_ 0.53% 1.282ms 0.53% 1.282ms 641.000us 0 b 0 b
 2
------------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
Self CPU time total: 242.401ms

REFERENCE - NAIVE ATTENTION statistics
cpu time: 242.154ms
mem usage: 4718592 bytes
-----RUNNING STUDENT IMPLEMENTATION-----

STAGE:2025-08-26 08:14:18 3895:3895 ActivityProfilerController.cpp:312] Completed Stage: Warm Up
STAGE:2025-08-26 08:14:19 3895:3895 ActivityProfilerController.cpp:318] Completed Stage: Collection
STAGE:2025-08-26 08:14:19 3895:3895 ActivityProfilerController.cpp:322] Completed Stage: Post Processing
manual attention == pytorch attention True
Manual Execution Time: 0.23636484146118164

----------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 Name Self CPU % Self CPU CPU total % CPU total CPU time avg CPU Mem Self CPU Mem # of Calls
----------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 aten::empty 0.01% 31.000us 0.01% 31.000us 10.333us 5.00 Mb 5.00 Mb
 3
 STUDENT - NAIVE ATTENTION 99.39% 234.968ms 99.96% 236.320ms 236.320ms 4.50 Mb -1.00 Mb
 1
 aten::zeros 0.02% 36.000us 0.25% 581.000us 290.500us 4.50 Mb 0 b
 2
 aten::clone 0.02% 42.000us 0.30% 707.000us 353.500us 1.00 Mb 0 b
 2
 model_inference 0.04% 93.000us 100.00% 236.413ms 236.413ms 512.00 Kb -4.00 Mb
 1
 aten::flatten 0.02% 37.000us 0.15% 359.000us 71.800us 512.00 Kb 0 b
 5
 aten::empty_like 0.00% 6.000us 0.00% 11.000us 11.000us 512.00 Kb 0 b
 1
 aten::empty_strided 0.01% 16.000us 0.01% 16.000us 16.000us 512.00 Kb 512.00 Kb
 1
 aten::zero_ 0.01% 18.000us 0.22% 519.000us 259.500us 0 b 0 b
 2
 aten::fill_ 0.21% 501.000us 0.21% 501.000us 250.500us 0 b 0 b
 2
----------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
Self CPU time total: 236.413ms

STUDENT - NAIVE ATTENTION statistics
cpu time: 236.32ms
mem usage: 4718592 bytes

# python3 gpt149.py part1 -N <val>
# 随便再测了几个，没有问题

Part 2: Blocked Matrix Multiply and Unfused Softmax

参照 lecture ，分块优化 cache 的命中率。

先查询本机的 cacheline，为 64

1
2
3
4
5


# Linux
cat /sys/devices/system/cpu/cpu1/cache/index0/coherency_line_size

# MacOS（虽然本次实现不能用它来做）
sysctl hw.cachelinesize

N 固定 1024 时，在本机上的最佳的 tile size 是多少？
Part 1, 2 的 DRAM 访问差别（缓存命中情况）

使用 Perf

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69


// module.cpp myUnfusedAttentionBlocked()

// -------- YOUR CODE HERE -------- //
constexpr int BLOCK_SIZE = 16; // cacheline / sizeof(float)

for (int b = 0; b < B; b++) {
 for (int h = 0; h < H; h++) {
 for (int i_b = 0; i_b < N; i_b += BLOCK_SIZE) {
 for (int j_b = 0; j_b < d; j_b += BLOCK_SIZE) {
 for (int k_b = 0; k_b < N; k_b += BLOCK_SIZE) {
 int i_e = std::min(i_b + BLOCK_SIZE, N);
 int j_e = std::min(j_b + BLOCK_SIZE, d);
 int k_e = std::min(k_b + BLOCK_SIZE, N);

 for (int i = i_b; i < i_e; i++) {
 for (int k = k_b; k < k_e; k++) {
 float QK_val = twoDimRead(QK_t, i, k, N);
 for (int j = j_b; j < j_e; j++) {
 float Q_val =
 fourDimRead(Q, b, h, i, j, H, N, d);
 float K_val =
 fourDimRead(K, b, h, k, j, H, N, d);
 QK_val += Q_val * K_val;
 }
 twoDimWrite(QK_t, i, k, N, QK_val);
 }
 }
 }
 }
 }

 for (int i = 0; i < N; i++) {
 float sum = 0.0;
 for (int j = 0; j < N; j++) {
 float val = twoDimRead(QK_t, i, j, N);
 sum += exp(val);
 }
 for (int j = 0; j < N; j++) {
 float val = twoDimRead(QK_t, i, j, N);
 val = exp(val) / sum;
 twoDimWrite(QK_t, i, j, N, val);
 }
 }

 for (int i_b = 0; i_b < N; i_b += BLOCK_SIZE) {
 for (int j_b = 0; j_b < N; j_b += BLOCK_SIZE) {
 for (int k_b = 0; k_b < d; k_b += BLOCK_SIZE) {
 int i_e = std::min(i_b + BLOCK_SIZE, N);
 int j_e = std::min(j_b + BLOCK_SIZE, N);
 int k_e = std::min(k_b + BLOCK_SIZE, d);

 for (int i = i_b; i < i_e; i++) {
 for (int k = k_b; k < k_e; k++) {
 float O_val =
 fourDimRead(O, b, h, i, k, H, N, d);
 for (int j = j_b; j < j_e; j++) {
 float QK_val = twoDimRead(QK_t, i, j, N);
 float V_val =
 fourDimRead(V, b, h, j, k, H, N, d);
 O_val += QK_val * V_val;
 }
 fourDimWrite(O, b, h, i, k, H, N, d, O_val);
 }
 }
 }
 }
 }
 }
}

测试结果：

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67


# python3 gpt149.py part2

Running Part 2 Test: Unfused Attention with Blocked Matmul

-----RUNNING REFERENCE IMPLEMENTATION-----

STAGE:2025-08-26 08:18:17 4350:4350 ActivityProfilerController.cpp:312] Completed Stage: Warm Up
STAGE:2025-08-26 08:18:17 4350:4350 ActivityProfilerController.cpp:318] Completed Stage: Collection
STAGE:2025-08-26 08:18:17 4350:4350 ActivityProfilerController.cpp:322] Completed Stage: Post Processing
manual attention == pytorch attention True
Manual Execution Time: 0.17670416831970215

------------------------------------------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 Name Self CPU % Self CPU CPU total % CPU total CPU time avg CPU Mem Self CPU Mem # of Calls
------------------------------------------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 aten::empty 0.06% 104.000us 0.06% 104.000us 34.667us 5.00 Mb 5.00 Mb 3
 REFERENCE - BLOCKED MATMUL + UNFUSED SOFTMAX 98.49% 174.098ms 99.94% 176.664ms 176.664ms 4.50 Mb -1.00 Mb 1
 aten::zeros 0.05% 85.000us 0.85% 1.501ms 750.500us 4.50 Mb 0 b 2
 aten::clone 0.07% 124.000us 0.50% 886.000us 443.000us 1.00 Mb 0 b 2
 model_inference 0.06% 107.000us 100.00% 176.771ms 176.771ms 512.00 Kb -4.00 Mb 1
 aten::flatten 0.09% 153.000us 0.33% 585.000us 117.000us 512.00 Kb 0 b 5
 aten::empty_like 0.02% 31.000us 0.03% 49.000us 49.000us 512.00 Kb 0 b 1
 aten::empty_strided 0.03% 50.000us 0.03% 50.000us 50.000us 512.00 Kb 512.00 Kb 1
 aten::zero_ 0.05% 96.000us 0.75% 1.330ms 665.000us 0 b 0 b 2
 aten::fill_ 0.70% 1.234ms 0.70% 1.234ms 617.000us 0 b 0 b 2
------------------------------------------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
Self CPU time total: 176.771ms

REFERENCE - BLOCKED MATMUL + UNFUSED SOFTMAX statistics
cpu time: 176.664ms
mem usage: 4718592 bytes
-----RUNNING STUDENT IMPLEMENTATION-----

STAGE:2025-08-26 08:18:23 4350:4350 ActivityProfilerController.cpp:312] Completed Stage: Warm Up
STAGE:2025-08-26 08:18:23 4350:4350 ActivityProfilerController.cpp:318] Completed Stage: Collection
STAGE:2025-08-26 08:18:23 4350:4350 ActivityProfilerController.cpp:322] Completed Stage: Post Processing
manual attention == pytorch attention True
Manual Execution Time: 0.16107916831970215

---------------------------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 Name Self CPU % Self CPU CPU total % CPU total CPU time avg CPU Mem Self CPU Mem # of Calls
---------------------------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 aten::empty 0.03% 54.000us 0.03% 54.000us 18.000us 5.00 Mb 5.00 Mb 3
 STUDENT - BLOCKED MATMUL + UNFUSED SOFTMAX 99.04% 159.579ms 99.94% 161.034ms 161.034ms 4.50 Mb -1.00 Mb 1
 aten::zeros 0.01% 23.000us 0.61% 982.000us 491.000us 4.50 Mb
 0 b 2
 aten::clone 0.02% 36.000us 0.26% 423.000us 211.500us 1.00 Mb
 0 b 2
 model_inference 0.06% 91.000us 100.00% 161.125ms 161.125ms 512.00 Kb -4.00 Mb 1
 aten::flatten 0.02% 31.000us 0.12% 195.000us 39.000us 512.00 Kb
 0 b 5
 aten::empty_like 0.00% 4.000us 0.00% 6.000us 6.000us 512.00 Kb
 0 b 1
 aten::empty_strided 0.01% 15.000us 0.01% 15.000us 15.000us 512.00 Kb 512.00 Kb 1
 aten::zero_ 0.01% 14.000us 0.56% 907.000us 453.500us 0 b
 0 b 2
 aten::fill_ 0.55% 893.000us 0.55% 893.000us 446.500us 0 b
 0 b 2
---------------------------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
Self CPU time total: 161.125ms

STUDENT - BLOCKED MATMUL + UNFUSED SOFTMAX statistics
cpu time: 161.034ms
mem usage: 4718592 bytes

# python3 gpt149.py part2 -N <val>
# 随便再测了几个，没有问题

Part 3: Fused Attention

由于 Q, K 矩阵乘、Softmax、注意力得分，遍历参数类似，但要重复三轮，并且整块占用，对 cache 表现和内存占用都不友好。

观察到 QK矩阵的每一行之间的计算是独立的，我们考虑把矩阵乘和 Softmax 操作融合 fused 起来。

使用 OpenMP，来简单地实现并行，如 #pragma omp parallel for collapse(2)，omp_get_thread_num() 来使用必要的子数组。

为什么 Part 3 的内存占用和 Part 1 & 2 相比骤降？
把 OpenMP 注释掉，比较 cpu 耗时，为什么融合让多线程利用更加轻松且充分了？

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


// module.cpp myFusedAttention()

// -------- YOUR CODE HERE -------- //
// We give you a template of the first three loops for your convenience
// loop over batch
#pragma omp parallel for collapse(3)
for (int b = 0; b < B; b++) {
 // loop over heads
 for (int h = 0; h < H; h++) {
 for (int i = 0; i < N; i++) {
 // YRow is moved inside so each OpenMP thread gets a local copy.
 at::Tensor ORowTensor = temp.index({torch::indexing::Slice(
 omp_get_thread_num(), torch::indexing::None)});
 std::vector<float> ORow = formatTensor(ORowTensor);
 // YOUR CODE HERE
 float sum = 0.0;
 for (int k = 0; k < N; k++) {
 float QK_val = 0.0;
 for (int j = 0; j < d; j++) {
 float Q_val = fourDimRead(Q, b, h, i, j, H, N, d);
 float K_val = fourDimRead(K, b, h, k, j, H, N, d);
 QK_val += Q_val * K_val;
 }
 ORow[k] = exp(QK_val);
 sum += ORow[k];
 }
 for (int k = 0; k < N; k++) {
 ORow[k] /= sum;
 }
 for (int k = 0; k < d; k++) {
 float O_val = 0.0;
 for (int j = 0; j < N; j++) {
 float V_val = fourDimRead(V, b, h, j, k, H, N, d);
 O_val += ORow[j] * V_val;
 }
 fourDimWrite(O, b, h, i, k, H, N, d, O_val);
 }
 }
 }
}

测试结果：

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80


# python3 gpt149.py part3

Running Part 3 Test: Fused Attention

-----RUNNING REFERENCE IMPLEMENTATION-----

STAGE:2025-08-26 08:21:16 4705:4705 ActivityProfilerController.cpp:312] Completed Stage: Warm Up
STAGE:2025-08-26 08:21:16 4705:4705 ActivityProfilerController.cpp:318] Completed Stage: Collection
STAGE:2025-08-26 08:21:16 4705:4705 ActivityProfilerController.cpp:322] Completed Stage: Post Processing
manual attention == pytorch attention True
Manual Execution Time: 0.05468630790710449

------------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 Name Self CPU % Self CPU CPU total % CPU total CPU time avg CPU Mem Self CPU Mem # of Calls
------------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 aten::empty 0.16% 85.000us 0.16% 85.000us 28.333us 1.03 Mb 1.03 Mb
 3
 aten::clone 0.12% 68.000us 1.69% 929.000us 464.500us 1.00 Mb 0 b
 2
 REFERENCE - FUSED ATTENTION 88.67% 48.607ms 99.63% 54.616ms 54.616ms 544.00 Kb -1.00 Mb
 1
 aten::zeros 0.16% 88.000us 1.04% 569.000us 284.500us 544.00 Kb 0 b
 2
 model_inference 0.37% 202.000us 100.00% 54.818ms 54.818ms 512.00 Kb -32.00 Kb
 1
 aten::flatten 1.88% 1.028ms 4.27% 2.340ms 4.535us 512.00 Kb 0 b
 516
 aten::empty_like 0.12% 66.000us 0.17% 93.000us 93.000us 512.00 Kb 0 b
 1
 aten::empty_strided 0.06% 34.000us 0.06% 34.000us 34.000us 512.00 Kb 512.00 Kb
 1
 aten::zero_ 0.29% 161.000us 0.77% 423.000us 211.500us 0 b 0 b
 2
 aten::fill_ 0.48% 262.000us 0.48% 262.000us 262.000us 0 b 0 b
 1
------------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
Self CPU time total: 54.818ms

REFERENCE - FUSED ATTENTION statistics
cpu time: 54.616ms
mem usage: 557056 bytes
-----RUNNING STUDENT IMPLEMENTATION-----

STAGE:2025-08-26 08:21:22 4705:4705 ActivityProfilerController.cpp:312] Completed Stage: Warm Up
STAGE:2025-08-26 08:21:22 4705:4705 ActivityProfilerController.cpp:318] Completed Stage: Collection
STAGE:2025-08-26 08:21:22 4705:4705 ActivityProfilerController.cpp:322] Completed Stage: Post Processing
manual attention == pytorch attention True
Manual Execution Time: 0.047617435455322266

----------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 Name Self CPU % Self CPU CPU total % CPU total CPU time avg CPU Mem Self CPU Mem # of Calls
----------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 aten::empty 0.06% 30.000us 0.06% 30.000us 7.500us 1.04 Mb 1.04 Mb
 4
 aten::clone 0.07% 34.000us 0.82% 391.000us 195.500us 1.00 Mb 0 b
 2
 aten::zeros 0.18% 88.000us 0.25% 118.000us 39.333us 548.00 Kb 0 b
 3
 STUDENT - FUSED ATTENTION 92.52% 44.102ms 99.81% 47.580ms 47.580ms 544.00 Kb -1.00 Mb
 1
 model_inference 0.19% 89.000us 100.00% 47.669ms 47.669ms 512.00 Kb -32.00 Kb
 1
 aten::flatten 1.44% 688.000us 2.56% 1.221ms 2.362us 512.00 Kb 0 b 517
 aten::empty_like 0.01% 5.000us 0.02% 10.000us 10.000us 512.00 Kb 0 b
 1
 aten::empty_strided 0.03% 16.000us 0.03% 16.000us 16.000us 512.00 Kb 512.00 Kb
 1
 aten::zero_ 0.03% 15.000us 0.13% 61.000us 20.333us 0 b 0 b
 3
 aten::fill_ 0.10% 46.000us 0.10% 46.000us 46.000us 0 b 0 b
 1
----------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
Self CPU time total: 47.669ms

STUDENT - FUSED ATTENTION statistics
cpu time: 47.58ms
mem usage: 557056 bytes

# python3 gpt149.py part3 -N <val>
# 随便再测了几个，没有问题

Part 4 : Putting it all Together - Flash Attention

为了更好的融合分块与 Softmax，Flash Attnetion 诞生了。

对着伪代码实现即可，注意变量名不要打错，找了半天 QnQ。

B H 多轮，应该只有 l 是需要重新初始化的。（当然根据写法不同有不同）

实验只要求正确性，不过超过得也比较轻松。挺多可以做融合 fused 的地方，不过为了和伪代码对应，就没去做。

也就不去进一步优化了。

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108


// module.cpp myFlashAttention()

// -------- YOUR CODE HERE  -------- //
const int Tr = (N + Br - 1) / Br;
const int Tc = (N + Bc - 1) / Bc;

for (int b = 0; b < B; b++) {
 for (int h = 0; h < H; h++) {
 // 初始化 l
 for (int t = 0; t < N; t++) {
 l[t] = 0.0;
 }

 for (int j = 0; j < Tc; j++) {
 // 读入 Kj, Vj
 int j_e = std::min(Bc, N - j * Bc);
 for (int j_b = 0; j_b < j_e; j_b++) {
 int idx = j * Bc + j_b;
 for (int k = 0; k < d; k++) {
 float Kj_val = fourDimRead(K, b, h, idx, k, H, N, d);
 twoDimWrite(Kj, j_b, k, d, Kj_val);
 float Vj_val = fourDimRead(V, b, h, idx, k, H, N, d);
 twoDimWrite(Vj, j_b, k, d, Vj_val);
 }
 }

 for (int i = 0; i < Tr; i++) {
 // 读入 Qi, Oi, li
 int i_e = std::min(Br, N - i * Br);
 for (int i_b = 0; i_b < i_e; i_b++) {
 int idx = i * Br + i_b;
 for (int k = 0; k < d; k++) {
 float Qi_val =
 fourDimRead(Q, b, h, idx, k, H, N, d);
 float Oi_val =
 fourDimRead(O, b, h, idx, k, H, N, d);
 twoDimWrite(Qi, i_b, k, d, Qi_val);
 twoDimWrite(Oi, i_b, k, d, Oi_val);
 }
 li[i_b] = l[idx];
 }

 // 计算 Sij
 for (int i_b = 0; i_b < i_e; i_b++) {
 for (int j_b = 0; j_b < j_e; j_b++) {
 float Sij_val = 0.0;
 for (int k = 0; k < d; k++) {
 float Qi_val = twoDimRead(Qi, i_b, k, d);
 float Kj_val = twoDimRead(Kj, j_b, k, d);
 Sij_val += Qi_val * Kj_val;
 }
 twoDimWrite(Sij, i_b, j_b, Bc, Sij_val);
 }
 }

 // 计算 Pij
 for (int i_b = 0; i_b < i_e; i_b++) {
 for (int j_b = 0; j_b < j_e; j_b++) {
 float Sij_val = twoDimRead(Sij, i_b, j_b, Bc);
 float Pij_val = exp(Sij_val);
 twoDimWrite(Pij, i_b, j_b, Bc, Pij_val);
 }
 }

 // 计算 lij
 for (int i_b = 0; i_b < i_e; i_b++) {
 float sum = 0.0;
 for (int j_b = 0; j_b < j_e; j_b++) {
 float Pij_val = twoDimRead(Pij, i_b, j_b, Bc);
 sum += Pij_val;
 }
 lij[i_b] = sum;
 }

 // 计算 lnew
 for (int i_b = 0; i_b < i_e; i_b++) {
 lnew[i_b] = li[i_b] + lij[i_b];
 }

 // 计算 Oi
 for (int i_b = 0; i_b < i_e; i_b++) {
 for (int k = 0; k < d; k++) {
 float PV_val = 0.0;
 for (int j_b = 0; j_b < j_e; j_b++) {
 float Pij_val = twoDimRead(Pij, i_b, j_b, Bc);
 float Vj_val = twoDimRead(Vj, j_b, k, d);
 PV_val += Pij_val * Vj_val;
 }
 float Oi_val = twoDimRead(Oi, i_b, k, d);
 float Oi_val_new =
 (li[i_b] * Oi_val + PV_val) / lnew[i_b];
 twoDimWrite(Oi, i_b, k, d, Oi_val_new);
 }
 }

 // 写回 Oi, lnew
 for (int i_b = 0; i_b < i_e; i_b++) {
 int idx = i * Br + i_b;
 for (int k = 0; k < d; k++) {
 float Oi_val = twoDimRead(Oi, i_b, k, d);
 fourDimWrite(O, b, h, idx, k, H, N, d, Oi_val);
 }
 l[idx] = lnew[i_b];
 }
 }
 }
 }
}

测试结果：

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73


# python3 gpt149.py part4

Running Part 4 Test: Flash Attention

-----RUNNING REFERENCE IMPLEMENTATION-----

STAGE:2025-08-26 14:10:25 8891:8891 ActivityProfilerController.cpp:312] Completed Stage: Warm Up
STAGE:2025-08-26 14:10:26 8891:8891 ActivityProfilerController.cpp:318] Completed Stage: Collection
STAGE:2025-08-26 14:10:26 8891:8891 ActivityProfilerController.cpp:322] Completed Stage: Post Processing
manual attention == pytorch attention True
Manual Execution Time: 0.7275524139404297

------------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 Name Self CPU % Self CPU CPU total % CPU total CPU time avg CPU Mem Self CPU Mem # of Calls
------------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 aten::zeros 0.01% 109.000us 0.34% 2.459ms 175.643us 9.16 Mb 0 b
 14
 aten::empty 0.02% 110.000us 0.02% 110.000us 7.857us 9.13 Mb 9.13 Mb
 14
 model_inference 0.04% 274.000us 100.00% 727.590ms 727.590ms 512.00 Kb -679.00 Kb
 1
 REFERENCE - FLASH ATTENTION 97.59% 710.021ms 99.89% 726.786ms 726.786ms 512.00 Kb -8.00 Mb
 1
 aten::zero_ 0.21% 1.546ms 2.35% 17.065ms 46.122us 32.00 Kb 32.00 Kb
 370
 aten::fill_ 2.13% 15.530ms 2.13% 15.530ms 116.767us 0 b 0 b
 133
------------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
Self CPU time total: 727.590ms

REFERENCE - FLASH ATTENTION statistics
cpu time: 726.786ms
mem usage: 524288 bytes
-----RUNNING STUDENT IMPLEMENTATION-----

STAGE:2025-08-26 14:10:31 8891:8891 ActivityProfilerController.cpp:312] Completed Stage: Warm Up
STAGE:2025-08-26 14:10:32 8891:8891 ActivityProfilerController.cpp:318] Completed Stage: Collection
STAGE:2025-08-26 14:10:32 8891:8891 ActivityProfilerController.cpp:322] Completed Stage: Post Processing
manual attention == pytorch attention True
Manual Execution Time: 0.21417665481567383

----------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 Name Self CPU % Self CPU CPU total % CPU total CPU time avg CPU Mem Self CPU Mem # of Calls
----------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
 aten::empty 0.01% 30.000us 0.01% 30.000us 2.308us 1.63 Mb 1.63 Mb
13
 aten::zeros 0.02% 40.000us 0.08% 164.000us 13.667us 1.16 Mb 32.00 Kb
12
 aten::clone 0.03% 58.000us 0.27% 585.000us 292.500us 1.00 Mb 0 b
 2
 model_inference 0.08% 179.000us 100.00% 214.232ms 214.232ms 512.00 Kb -679.00 Kb
 1
 STUDENT - FLASH ATTENTION 99.52% 213.207ms 99.85% 213.906ms 213.906ms 512.00 Kb -1.00 Mb
 1
 aten::flatten 0.03% 60.000us 0.18% 384.000us 25.600us 512.00 Kb 0 b
15
 aten::empty_like 0.00% 4.000us 0.00% 6.000us 6.000us 512.00 Kb 0 b
 1
 aten::empty_strided 0.01% 13.000us 0.01% 13.000us 13.000us 512.00 Kb 512.00 Kb
 1
 aten::zero_ 0.02% 36.000us 0.04% 96.000us 8.000us 0 b 0 b
12
 aten::fill_ 0.03% 74.000us 0.03% 74.000us 24.667us 0 b 0 b
 3
----------------------------- ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------
Self CPU time total: 214.232ms

STUDENT - FLASH ATTENTION statistics
cpu time: 213.906ms
mem usage: 524288 bytes

# python3 gpt149.py part4 -N <val> -br <val> -bc <val>
# 随便再测了几个，没有问题（br bc 在合法范围)

Extra Credit: Optimize Further

用 ISPC 进一步优化上面每一个 Part。

感觉意义一般，也跑路了。

结语

总的来说，这个是做下来目前感觉最简单的。

『学习笔记』CS149 (2024): Assignment 2

Fri, 22 Aug 2025 16:35:33 +0000

CS149 (2024): Assignment 2

封面来源：@Ge_DaZuo

相关文章：Stanford-CS149-并行计算-Assignment2-任务执行库 - 知乎、CS149 Programming Assignment 2 - Scheduling Task Graphs on a Multi-Core CPU | MizukiCry’s Blog

C++ 并发帮助的文章：std::condition_variable.wait()的用法和设计缺陷带来的坑_condition variable wait-CSDN博客

原始实验材料仓库：stanford-cs149/asst2

我的实现仓库：Livinfly/15-418u15-618uCS149u

任务推荐资料：

C++ Interfaces - abstract class 抽象类介绍

C++ synchronization tutorial 基础的 std::thread, std::mutex, std::condition_variable, std::atomic 使用介绍

环境

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 系统版本
uname -a
lsb_release -a
nvidia-smi
cat /proc/cpuinfo
cat /proc/cpuinfo | grep processor | wc -l
# Mac OS
uname -a
sysctl machdep.cpu.brand_string
sysctl hw.physicalcpu
sysctl hw.logicalcpu

OS: Darwin MacBook-Pro.local 24.1.0 Darwin Kernel Version 24.1.0: Thu Oct 10 21:06:57 PDT 2024; root:xnu-11215.41.3~3/RELEASE_ARM64_T6041 arm64
CPU: Apple M4 Pro (14 physicalcpu, 14 logicalcpu)，（10性能和4能效）
GPU: 20 Cores
Memory: 24 GB
Python 3.9.6

（不过不影响，测试同时也在 wsl2 上测试，环境同 asst1）

Part A: Synchronous Bulk Task Launch

完成类似 ispc task 的功能，任务分成三个类的实现。

因为 pthread 要传递函数参数的话，可能要额外再写个包装函数void* wrapper_function(void* arg) return NULL;，再观察到编译 c++ 版本是 c++ 11，决定用 std::thread 实现多线程了。

测试和run_test_harness.py 统一放到最后。

因为核心数是 10 性能 + 4 能效，所以线程数为 10 时的结果会可能更好。（因为不用等能效核的慢任务）

发现，最大困难是明确要求，初版实现基本都有点偏离要求了，写晕了。（不过也就懒得删，放实现仓库了，以 .bak 结尾的 tasksys 文件）

参考其他人的实现，重新搞清楚了要求。

TaskSystemParallelSpawn

固定最大工作线程数，每次在 run 的时候创建，只创建最大工作线程数次。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50


// tasksys.h

#include <atomic>
#include <thread>

class TaskSystemParallelSpawn : public ITaskSystem {
 private:
 int _num_threads;
 std::thread* _threads_worker;
};

// tasksys.cpp

TaskSystemParallelSpawn::TaskSystemParallelSpawn(int num_threads)
 : ITaskSystem(num_threads),
 _num_threads(num_threads),
 _threads_worker(new std::thread[num_threads]) {}

TaskSystemParallelSpawn::~TaskSystemParallelSpawn() {
 delete[] _threads_worker;
}

void TaskSystemParallelSpawn::run(IRunnable *runnable, int num_total_tasks) {
 std::atomic<int> task_id(0);

 auto work = [&task_id, &runnable, &num_total_tasks]() {
 // 可以批量处理，减少原子操作
 // const int BATCH_SIZE = 16;
 while (true) {
 int id = task_id.fetch_add(1);
 if (id >= num_total_tasks) break;
 runnable->runTask(id, num_total_tasks);

 // 可以批量处理，减少原子操作
 // int start_id = task_id.fetch_add(BATCH_SIZE);
 // if (start_id >= num_total_tasks) break;
 // int end_id = std::min(start_id + BATCH_SIZE, num_total_tasks);
 // for (int id = start_id; id < end_id; id++) {
 // runnable->runTask(id, num_total_tasks);
 // }
 }
 };

 for (int i = 0; i < _num_threads; i++) {
 _threads_worker[i] = std::thread(work);
 }
 for (int i = 0; i < _num_threads; i++) {
 _threads_worker[i].join();
 }
}

TaskSystemParallelThreadPoolSpinning

构建类的时候就创建好最大工作线程（线程池），在类析构的时候才停止工作进程，线程等待的时候，选择 spin，即 while(!condition);。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77


// tasksys.h

#include <atomic>
#include <mutex>
#include <thread>

class TaskSystemParallelThreadPoolSpinning : public ITaskSystem {
private:
 int _num_threads;
 std::thread* _threads_worker;
 // run_info
 bool _end;
 IRunnable* _runnable;
 int _num_total_tasks;
 int _current_task_id;
 std::mutex* _mtx;
 std::atomic<int> _num_done_tasks;
};

// tasksys.cpp

TaskSystemParallelThreadPoolSpinning::TaskSystemParallelThreadPoolSpinning(
 int num_threads)
 : ITaskSystem(num_threads),
 _num_threads(num_threads),
 _threads_worker(new std::thread[num_threads]),
 _end(false),
 _runnable(nullptr),
 _mtx(new std::mutex) {
 auto work = [&]() {
 while (true) {
 IRunnable *runnable = nullptr;
 int task_id;
 _mtx->lock();
 if (_runnable) {
 runnable = _runnable;
 task_id = _current_task_id++;
 if (_current_task_id >= _num_total_tasks) _runnable = nullptr;
 }
 bool is_end = _end;
 _mtx->unlock();
 if (runnable) {
 runnable->runTask(task_id, _num_total_tasks);
 _num_done_tasks.fetch_add(1);
 } else if (is_end) {
 break;
 }
 }
 };
 for (int i = 0; i < _num_threads; i++) {
 _threads_worker[i] = std::thread(work);
 }
}

TaskSystemParallelThreadPoolSpinning::~TaskSystemParallelThreadPoolSpinning() {
 _mtx->lock();
 _end = true;
 _mtx->unlock();
 for (int i = 0; i < _num_threads; i++) {
 _threads_worker[i].join();
 }
 delete[] _threads_worker;
 delete _mtx;
}

void TaskSystemParallelThreadPoolSpinning::run(IRunnable *runnable,
 int num_total_tasks) {

 _mtx->lock();
 _runnable = runnable;
 _num_total_tasks = num_total_tasks;
 _current_task_id = 0;
 _num_done_tasks = 0;
 _mtx->unlock();

 while (_num_done_tasks < _num_total_tasks);
}

TaskSystemParallelThreadPoolSleeping

在 TaskSystemParallelThreadPoolSpinning 的基础上，使用 std::condition_variable 降低 spin 带来的开销。

提示可以添加在工作线程没任务做和主线程等待工作线程完成任务这两个阶段。

这里保留了其他实现与调试的注释。

调试过程中，对 std::mutex, std::condition_variable 逐渐有了些感觉。

（不过像什么生产者-消费者模型，只是知道，还没有去实现学习，咕咕）

这里主要原因是，主线程的等待好像用条件变量，会慢不少，所以保留了（我也不再细究这个情况了）

这种多线程并发的程序调试，感觉很大程度还是需要用输出调试来调，有些时候稍微顺序错位一点点在几次测试中可能并不会出错。

有输出可以更加清楚的知道，运行的情况。

比如我保留的注释，让我发现在 super_super_light 测试中，可能在主线程开始等待前，工作线程就做完了等情况。

后面也学着把会被别的线程修改的数据先读到本地，然后在释放锁之后，再做处理。

又可以避免忘记释放锁，也能在后面再使用的时候更加安全。

这里再简单说说我对 std::condition_variable 粗浅认识：

（如有错误，敬请指正，最好附上代码案例）

主要分为 wait(unique_lock, [condition]) 和 notify_one() / notify_all()。

wait(unique_lock, [condition])

需要在 wait() 之前，该线程有获得 / 锁上 unique_lock 这个锁。

到 wait() 的时候，会检测条件是否符合：
- 符合，不会堵塞，继续运行；
- 不符合，会堵塞，等待其他线程唤醒 notify_*()。
  
  唤醒后再判断条件是否符合，以此类推。
因此，可以等价于 while(!condition) {wait();}。

这里的 wait() 就是事实的堵塞，被唤醒后，继续进行循环条件的判断。

所以，如果恒为真，就不会堵塞，恒为假就永远堵塞。

因此，对于工作线程的 std::condition_variale 只要在最开始执行一次 notify_all()，

然后就会把这一批次执行完了，不需要在内部再反复 notify_*() 了。
notify_one() / notify_all()

随机唤醒一个等待线程 / 唤醒所有等待线程。

notify_*() 和释放当前锁的先后。

从结果上来说是都可以，不过先释放锁，在 notify_*() 可以减少一步竞争锁这一步（大概？）

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122


// tasksys.h

#include <atomic>
#include <condition_variable>
#include <mutex>
#include <thread>

class TaskSystemParallelThreadPoolSleeping : public ITaskSystem {
private:
 int _num_threads;
 std::thread* _threads_worker;
 // run_info
 bool _end;
 IRunnable* _runnable;
 int _num_total_tasks;
 int _current_task_id;
 int _num_done_tasks;
 std::mutex *_mtx, *_mtx_done;
 std::condition_variable *_cv, *_cv_done;
}

// tasksys.cpp

TaskSystemParallelThreadPoolSleeping::TaskSystemParallelThreadPoolSleeping(
 int num_threads)
 : ITaskSystem(num_threads),
 _num_threads(num_threads),
 _threads_worker(new std::thread[num_threads]),
 _end(false),
 _runnable(nullptr),
 _mtx(new std::mutex),
 _mtx_done(new std::mutex),
 _cv(new std::condition_variable),
 _cv_done(new std::condition_variable) {
 auto work = [&]() {
 while (true) {
 IRunnable *runnable = nullptr;
 int task_id;
 std::unique_lock<std::mutex> lk(*_mtx);
 _cv->wait(lk, [&]() { return _runnable || _end; });
 if (_runnable) {
 runnable = _runnable;
 task_id = _current_task_id++;
 if (_current_task_id >= _num_total_tasks) _runnable = nullptr;
 }
 bool is_end = _end;
 lk.unlock();
 if (runnable) {
 runnable->runTask(task_id, _num_total_tasks);
 // 需要 lock，不然可能主线程还没开始 wait
 // 这边的通知就已经发出去了（任务特别轻的时候
 // super_super_light）
 _mtx_done->lock();
 _num_done_tasks++;
 // printf("%d\n", _num_done_tasks);

 // 1
 // bool is_done = _num_done_tasks >= _num_total_tasks;
 _mtx_done->unlock();
 // if (is_done) {
 // // puts("done 0");
 // _cv_done->notify_one();
 // }
 // 2
 // _cv_done->notify_one();
 } else if (is_end) {
 break;
 }
 }
 };
 for (int i = 0; i < _num_threads; i++) {
 _threads_worker[i] = std::thread(work);
 }
}

TaskSystemParallelThreadPoolSleeping::~TaskSystemParallelThreadPoolSleeping() {
 _mtx->lock();
 _end = true;
 _mtx->unlock();
 _cv->notify_all();
 for (int i = 0; i < _num_threads; i++) {
 _threads_worker[i].join();
 }
 delete[] _threads_worker;
 delete _mtx;
 delete _mtx_done;
 delete _cv;
 delete _cv_done;
}

void TaskSystemParallelThreadPoolSleeping::run(IRunnable *runnable,
 int num_total_tasks) {
 // 要先为 wait 获取锁，堵塞后释放

 // 1, 2
 // std::unique_lock<std::mutex> lk_done(*_mtx_done);
 {
 std::unique_lock<std::mutex> lk(*_mtx);
 _runnable = runnable;
 _num_total_tasks = num_total_tasks;
 _current_task_id = 0;
 _num_done_tasks = 0;
 }
 _cv->notify_all();

 // puts("wait");

 // 1
 // _cv_done->wait(lk_done);
 // 2
 // _cv_done->wait(lk_done,
 // [&]() { return _num_done_tasks >= _num_total_tasks; });
 // 3
 while (true) {
 _mtx_done->lock();
 bool is_done = _num_done_tasks >= _num_total_tasks;
 _mtx_done->unlock();
 if (is_done) break;
 }

 // puts("done 1");
}

测试

~~加测试还是算了，看看测试得了~~

我调试调出比较多问题的就是 super_super_light 了，具体测试的任务，见 tests/README.md，找到适合调试的测试，或试着自己创建测试。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// tests/main.cpp

// TODO: do this better
if (j + 1 == num_timing_iterations) {
 printf("[%s]:\t\t[%.3f] ms\n", t->name(), minT * 1000);
 // 更多的信息显示
 // 然而 run_test_harness 需要保持输出格式不能出现太多变化
 // printf(
 // "[%-30s]: min=%8.3f ms, max=%8.3f ms, avg=%8.3f "
 // "ms\n",
 // t->name(), minT * 1000, maxT * 1000,
 // avgT * 1000 / num_timing_iterations);
}

后面就是具体的测试了，展示两个测试结果：

本机 MacOS 的运行结果，我前面发布的 Assignment 1 的 wsl2 的测试结果。

不知道什么缘故，MacOS 跑得很奇怪，不能过的测试的情况，甚至不需要改的串行，打不过参照版本。

记得把对应的 ref 可执行文件设置执行权限

MacOS 的测试结果：

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115


# python3 ../tests/run_test_harness.py

# MacOS
runtasks_ref
Darwin arm64
================================================================================
Running task system grading harness... (11 total tests)
 - Detected CPU with 14 execution contexts
 - Task system configured to use at most 14 threads
================================================================================
================================================================================
Executing test: super_super_light...
Reference binary: ./runtasks_ref_osx_arm
Results for: super_super_light
 STUDENT REFERENCE PERF?
[Serial] 3.333 3.388 0.98 (OK)
[Parallel + Always Spawn] 40.791 41.765 0.98 (OK)
[Parallel + Thread Pool + Spin] 30.702 60.015 0.51 (OK)
[Parallel + Thread Pool + Sleep] 23.379 23.475 1.00 (OK)
================================================================================
Executing test: super_light...
Reference binary: ./runtasks_ref_osx_arm
Results for: super_light
 STUDENT REFERENCE PERF?
[Serial] 13.892 18.94 0.73 (OK)
[Parallel + Always Spawn] 49.262 50.518 0.98 (OK)
[Parallel + Thread Pool + Spin] 34.876 85.981 0.41 (OK)
[Parallel + Thread Pool + Sleep] 32.64 31.334 1.04 (OK)
================================================================================
Executing test: ping_pong_equal...
Reference binary: ./runtasks_ref_osx_arm
Results for: ping_pong_equal
 STUDENT REFERENCE PERF?
[Serial] 233.014 372.162 0.63 (OK)
[Parallel + Always Spawn] 70.801 89.837 0.79 (OK)
[Parallel + Thread Pool + Spin] 55.278 118.816 0.47 (OK)
[Parallel + Thread Pool + Sleep] 49.07 64.635 0.76 (OK)
================================================================================
Executing test: ping_pong_unequal...
Reference binary: ./runtasks_ref_osx_arm
Results for: ping_pong_unequal
 STUDENT REFERENCE PERF?
[Serial] 687.359 529.064 1.30 (NOT OK)
[Parallel + Always Spawn] 112.08 96.883 1.16 (OK)
[Parallel + Thread Pool + Spin] 109.983 132.2 0.83 (OK)
[Parallel + Thread Pool + Sleep] 94.275 72.262 1.30 (NOT OK)
================================================================================
Executing test: recursive_fibonacci...
Reference binary: ./runtasks_ref_osx_arm
Results for: recursive_fibonacci
 STUDENT REFERENCE PERF?
[Serial] 917.397 908.294 1.01 (OK)
[Parallel + Always Spawn] 88.143 87.136 1.01 (OK)
[Parallel + Thread Pool + Spin] 93.761 91.151 1.03 (OK)
[Parallel + Thread Pool + Sleep] 90.891 87.237 1.04 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop...
Reference binary: ./runtasks_ref_osx_arm
Results for: math_operations_in_tight_for_loop
 STUDENT REFERENCE PERF?
[Serial] 206.775 208.574 0.99 (OK)
[Parallel + Always Spawn] 247.204 248.615 0.99 (OK)
[Parallel + Thread Pool + Spin] 142.73 337.597 0.42 (OK)
[Parallel + Thread Pool + Sleep] 115.278 104.963 1.10 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fewer_tasks...
Reference binary: ./runtasks_ref_osx_arm
Results for: math_operations_in_tight_for_loop_fewer_tasks
 STUDENT REFERENCE PERF?
[Serial] 206.505 208.375 0.99 (OK)
[Parallel + Always Spawn] 236.613 236.781 1.00 (OK)
[Parallel + Thread Pool + Spin] 152.883 317.297 0.48 (OK)
[Parallel + Thread Pool + Sleep] 107.491 93.697 1.15 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fan_in...
Reference binary: ./runtasks_ref_osx_arm
Results for: math_operations_in_tight_for_loop_fan_in
 STUDENT REFERENCE PERF?
[Serial] 106.303 107.268 0.99 (OK)
[Parallel + Always Spawn] 38.578 39.553 0.98 (OK)
[Parallel + Thread Pool + Spin] 29.772 59.795 0.50 (OK)
[Parallel + Thread Pool + Sleep] 25.858 23.483 1.10 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_reduction_tree...
Reference binary: ./runtasks_ref_osx_arm
Results for: math_operations_in_tight_for_loop_reduction_tree
 STUDENT REFERENCE PERF?
[Serial] 106.5 107.555 0.99 (OK)
[Parallel + Always Spawn] 17.227 16.92 1.02 (OK)
[Parallel + Thread Pool + Spin] 15.236 18.473 0.82 (OK)
[Parallel + Thread Pool + Sleep] 13.976 12.774 1.09 (OK)
================================================================================
Executing test: spin_between_run_calls...
Reference binary: ./runtasks_ref_osx_arm
Results for: spin_between_run_calls
 STUDENT REFERENCE PERF?
[Serial] 325.933 329.414 0.99 (OK)
[Parallel + Always Spawn] 168.387 166.579 1.01 (OK)
[Parallel + Thread Pool + Spin] 172.841 172.559 1.00 (OK)
[Parallel + Thread Pool + Sleep] 170.135 166.414 1.02 (OK)
================================================================================
Executing test: mandelbrot_chunked...
Reference binary: ./runtasks_ref_osx_arm
Results for: mandelbrot_chunked
 STUDENT REFERENCE PERF?
[Serial] 234.344 238.415 0.98 (OK)
[Parallel + Always Spawn] 23.441 23.949 0.98 (OK)
[Parallel + Thread Pool + Spin] 24.577 24.065 1.02 (OK)
[Parallel + Thread Pool + Sleep] 23.558 23.893 0.99 (OK)
================================================================================
Overall performance results
[Serial] : Perf did not pass all tests
[Parallel + Always Spawn] : All passed Perf
[Parallel + Thread Pool + Spin] : All passed Perf
[Parallel + Thread Pool + Sleep] : Perf did not pass all tests

接下来是 wsl2 的测试结果：

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115


# python3 ../tests/run_test_harness.py

# Linux (wsl2)
runtasks_ref
Linux x86_64
================================================================================
Running task system grading harness... (11 total tests)
 - Detected CPU with 16 execution contexts
 - Task system configured to use at most 16 threads
================================================================================
================================================================================
Executing test: super_super_light...
Reference binary: ./runtasks_ref_linux
Results for: super_super_light
 STUDENT REFERENCE PERF?
[Serial] 8.802 13.128 0.67 (OK)
[Parallel + Always Spawn] 605.881 598.953 1.01 (OK)
[Parallel + Thread Pool + Spin] 17.418 29.269 0.60 (OK)
[Parallel + Thread Pool + Sleep] 130.41 128.733 1.01 (OK)
================================================================================
Executing test: super_light...
Reference binary: ./runtasks_ref_linux
Results for: super_light
 STUDENT REFERENCE PERF?
[Serial] 77.868 82.437 0.94 (OK)
[Parallel + Always Spawn] 600.781 603.958 0.99 (OK)
[Parallel + Thread Pool + Spin] 23.272 35.303 0.66 (OK)
[Parallel + Thread Pool + Sleep] 121.364 121.066 1.00 (OK)
================================================================================
Executing test: ping_pong_equal...
Reference binary: ./runtasks_ref_linux
Results for: ping_pong_equal
 STUDENT REFERENCE PERF?
[Serial] 1258.518 1328.074 0.95 (OK)
[Parallel + Always Spawn] 644.312 653.419 0.99 (OK)
[Parallel + Thread Pool + Spin] 252.352 280.218 0.90 (OK)
[Parallel + Thread Pool + Sleep] 252.865 278.068 0.91 (OK)
================================================================================
Executing test: ping_pong_unequal...
Reference binary: ./runtasks_ref_linux
Results for: ping_pong_unequal
 STUDENT REFERENCE PERF?
[Serial] 1835.189 1872.283 0.98 (OK)
[Parallel + Always Spawn] 678.557 682.423 0.99 (OK)
[Parallel + Thread Pool + Spin] 293.994 320.018 0.92 (OK)
[Parallel + Thread Pool + Sleep] 300.234 312.32 0.96 (OK)
================================================================================
Executing test: recursive_fibonacci...
Reference binary: ./runtasks_ref_linux
Results for: recursive_fibonacci
 STUDENT REFERENCE PERF?
[Serial] 1053.251 1858.459 0.57 (OK)
[Parallel + Always Spawn] 163.893 227.547 0.72 (OK)
[Parallel + Thread Pool + Spin] 161.371 238.919 0.68 (OK)
[Parallel + Thread Pool + Sleep] 156.074 207.127 0.75 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop
 STUDENT REFERENCE PERF?
[Serial] 668.082 666.432 1.00 (OK)
[Parallel + Always Spawn] 3089.146 3064.197 1.01 (OK)
[Parallel + Thread Pool + Spin] 213.058 250.838 0.85 (OK)
[Parallel + Thread Pool + Sleep] 607.31 605.516 1.00 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fewer_tasks...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_fewer_tasks
 STUDENT REFERENCE PERF?
[Serial] 668.517 666.362 1.00 (OK)
[Parallel + Always Spawn] 3067.389 3094.792 0.99 (OK)
[Parallel + Thread Pool + Spin] 209.684 243.559 0.86 (OK)
[Parallel + Thread Pool + Sleep] 608.357 611.346 1.00 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fan_in...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_fan_in
 STUDENT REFERENCE PERF?
[Serial] 343.895 345.364 1.00 (OK)
[Parallel + Always Spawn] 400.428 400.808 1.00 (OK)
[Parallel + Thread Pool + Spin] 62.778 76.579 0.82 (OK)
[Parallel + Thread Pool + Sleep] 86.475 99.433 0.87 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_reduction_tree...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_reduction_tree
 STUDENT REFERENCE PERF?
[Serial] 341.52 341.368 1.00 (OK)
[Parallel + Always Spawn] 114.191 115.154 0.99 (OK)
[Parallel + Thread Pool + Spin] 51.682 56.073 0.92 (OK)
[Parallel + Thread Pool + Sleep] 59.162 59.922 0.99 (OK)
================================================================================
Executing test: spin_between_run_calls...
Reference binary: ./runtasks_ref_linux
Results for: spin_between_run_calls
 STUDENT REFERENCE PERF?
[Serial] 370.866 656.866 0.56 (OK)
[Parallel + Always Spawn] 193.432 337.548 0.57 (OK)
[Parallel + Thread Pool + Spin] 327.29 474.147 0.69 (OK)
[Parallel + Thread Pool + Sleep] 187.028 333.137 0.56 (OK)
================================================================================
Executing test: mandelbrot_chunked...
Reference binary: ./runtasks_ref_linux
Results for: mandelbrot_chunked
 STUDENT REFERENCE PERF?
[Serial] 431.728 429.047 1.01 (OK)
[Parallel + Always Spawn] 32.047 32.035 1.00 (OK)
[Parallel + Thread Pool + Spin] 33.911 33.334 1.02 (OK)
[Parallel + Thread Pool + Sleep] 33.27 31.475 1.06 (OK)
================================================================================
Overall performance results
[Serial] : All passed Perf
[Parallel + Always Spawn] : All passed Perf
[Parallel + Thread Pool + Spin] : All passed Perf
[Parallel + Thread Pool + Sleep] : All passed Perf

Part B: Supporting Execution of Task Graphs

实现异步的任务图。

并发这一部分还是挺折磨的，虽然其实就几项东西，但常常写挂，又要调试（我是输出调试了大部分都保留在代码中，有大佬说可以试试 C++ 有的日志库，可能可以节省点精力），特别是在修了一个地方后，发现修假了，只是奇妙正确了，然后继续修；改写法之后，之前改对又变成改错的。

所以，这一部分实现，再确定正确性没有什么问题之后，性能部分可能确实有点犯懒跑路了，咕咕。

因为有很多类任务，而前面的实现，有一系列参数都是给一类任务完成使用的。

所以，我们能够想到为一类任务，创建一个专属的结构体；对于最后的析构和同步，则是另一部分参数。

前期主要用 simple_test_async 在后面大部分时候使用 super_light_async 查问题。

说思路感觉有些繁杂，没有理出一条简洁的思考线路来，简单提一下遇到的几个坑吧。

关于测试的，记得最后用异步的测试去测异步啊（x

映射的 TaskInfo 和 _task_executable_list 的 TaskInfo 的信息同步更新。

有些正确性问题，默认的 run_test_harness.py 并不能测出来，建议增加一下全都测一遍正确性。

（简单应该就在该文件中的 LIST_OF_TESTS 增加些测试字段就好）

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170


// tasksys.h

#include <algorithm>
#include <condition_variable>
#include <list>
#include <mutex>
#include <thread>
#include <unordered_map>
#include <vector>

class TaskSystemParallelThreadPoolSleeping : public ITaskSystem {
private:
 struct TaskInfo { // 具体任务的完成情况
 TaskID _idx; // 任务编号
 IRunnable* runnable;
 int _num_total_tasks;
 int _current_task_id; // id 用于同类任务的执行进度标识
 int _num_done_tasks;
 int _num_deps; // 依赖的任务数
 std::vector<TaskID> _successores; // 后继
 };
 int _num_threads;
 std::thread* _threads_worker;
 bool _end;
 // 当前最大的任务类编号, idx 用于不同任务种类
 int _current_task_idx;
 // 任务编号到具体任务完成情况的映射
 // 一开始是指还有依赖的任务的映射，后面改错时变成单纯的映射关系了
 // 这里就懒得改变量名了
 std::unordered_map<TaskID, TaskInfo> _task_waiting_map;
 // 已经可以执行的任务列表
 std::list<TaskInfo*> _task_executable_list;
 std::mutex *_mtx, *_mtx_done;
 std::condition_variable *_cv, *_cv_done;
}

// tasksys.cpp

TaskSystemParallelThreadPoolSleeping::TaskSystemParallelThreadPoolSleeping(
 int num_threads)
 : ITaskSystem(num_threads),
 _num_threads(num_threads),
 _threads_worker(new std::thread[num_threads]),
 _end(false),
 _current_task_idx(0),
 _mtx(new std::mutex),
 _mtx_done(new std::mutex),
 _cv(new std::condition_variable),
 _cv_done(new std::condition_variable) {
 auto work = [&]() {
 while (true) {
 std::unique_lock<std::mutex> lk(*_mtx);
 _cv->wait(lk,
 [&]() { return !_task_executable_list.empty() || _end; });
 if (_end) return;

 auto iter_iter_task = std::find_if(
 _task_executable_list.begin(), _task_executable_list.end(),
 [](const TaskInfo* t) {
 return t->_current_task_id < t->_num_total_tasks;
 });
 if (iter_iter_task == _task_executable_list.end()) {
 // cv
 // all_work_dispatched
 continue;
 }

 TaskInfo* iter_task = *iter_iter_task;

 int id_cur = iter_task->_current_task_id++;
 lk.unlock();

 iter_task->runnable->runTask(id_cur, iter_task->_num_total_tasks);

 lk.lock();
 bool is_empty = false;
 iter_task->_num_done_tasks++;
 // printf("task_idx: %d -> num_done_tasks: %d\n", iter_task->_idx,
 // iter_task->_num_done_tasks);
 if (iter_task->_num_done_tasks == iter_task->_num_total_tasks) {
 for (TaskID successor : iter_task->_successores) {
 // printf("task_idx: %d -> successor: %d\n",
 // iter_task->_idx,
 // successor);
 if (--_task_waiting_map[successor]._num_deps == 0) {
 _task_executable_list.push_back(
 (TaskInfo*)&_task_waiting_map[successor]);
 // 原本指还有依赖的任务，所以erase，但是现在不是（x
 // _task_waiting_map.erase(successor);
 }
 }
 // printf("done task_idx: %d\n", iter_task->_idx);
 _task_executable_list.erase(iter_iter_task);
 // printf("_task_executable_list size: %d\n",
 // _task_executable_list.size());
 is_empty = _task_executable_list.empty();
 }
 lk.unlock();
 if (is_empty) {
 _cv_done->notify_one();
 }
 }
 };
 for (int i = 0; i < _num_threads; i++) {
 _threads_worker[i] = std::thread(work);
 }
}

TaskSystemParallelThreadPoolSleeping::~TaskSystemParallelThreadPoolSleeping() {
 // sync(); // 可能没啥必要（？
 _mtx->lock();
 _end = true;
 _mtx->unlock();
 _cv->notify_all();
 for (int i = 0; i < _num_threads; i++) {
 _threads_worker[i].join();
 }
 delete[] _threads_worker;
 delete _mtx;
 delete _mtx_done;
 delete _cv;
 delete _cv_done;
}

void TaskSystemParallelThreadPoolSleeping::run(IRunnable* runnable,
 int num_total_tasks) {
 runAsyncWithDeps(runnable, num_total_tasks, {});
 sync();
}

TaskID TaskSystemParallelThreadPoolSleeping::runAsyncWithDeps(
 IRunnable* runnable, int num_total_tasks, const std::vector<TaskID>& deps) {
 std::unique_lock<std::mutex> lk(*_mtx);
 TaskID task_idx = _current_task_idx++;
 // printf("begin run async %d, num_total_tasks: %d\n", task_idx,
 // num_total_tasks);
 // for (auto dep : deps) {
 // printf("%d depends on %d\n", task_idx, dep);
 // }
 TaskInfo task{task_idx, runnable, num_total_tasks, 0, 0, 0, {}};
 for (TaskID dep : deps) {
 // auto it = _task_waiting_map.find(dep);
 // if (it != _task_waiting_map.end()) {
 // // printf("%d depends on %d\n", task_idx, dep);
 // it->second._successores.push_back(task_idx);
 // task._num_deps++;
 // }
 // 因为修改了 _task_waiting_map 的含义，需要检测下是否还是需要考虑的依赖
 auto& t = _task_waiting_map[dep];
 if (t._num_done_tasks < t._num_total_tasks) {
 t._successores.push_back(task_idx);
 task._num_deps++;
 }
 }
 // printf("num_deps: %d\n", task._num_deps);
 _task_waiting_map[task_idx] = task;
 if (task._num_deps == 0) {
 _task_executable_list.push_back(
 (TaskInfo*)&_task_waiting_map[task_idx]);
 }
 lk.unlock();
 _cv->notify_all();
 return task_idx;
}

void TaskSystemParallelThreadPoolSleeping::sync() {
 std::unique_lock<std::mutex> lk(*_mtx);
 _cv_done->wait(lk, [&]() { return _task_executable_list.empty(); });
 return;
}

最后也是都列一下两次都测试结果

测试

原本看 MacOS 上的结果以为性能菜爆了，wsl2 上看起来很正常啊，~~可以安心逃了啊~~

MacOS 的测试结果：

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213


# python3 ../tests/run_test_harness.py -a

runtasks_ref
Darwin arm64
================================================================================
Running task system grading harness... (22 total tests)
 - Detected CPU with 14 execution contexts
 - Task system configured to use at most 14 threads
================================================================================
================================================================================
Executing test: super_super_light...
Reference binary: ./runtasks_ref_osx_arm
Results for: super_super_light
 STUDENT REFERENCE PERF?
[Serial] 3.632 3.658 0.99 (OK)
[Parallel + Always Spawn] 3.655 48.731 0.08 (OK)
[Parallel + Thread Pool + Spin] 3.75 56.003 0.07 (OK)
[Parallel + Thread Pool + Sleep] 53.49 25.094 2.13 (NOT OK)
================================================================================
Executing test: super_super_light_async...
Reference binary: ./runtasks_ref_osx_arm
Results for: super_super_light_async
 STUDENT REFERENCE PERF?
[Serial] 3.72 3.672 1.01 (OK)
[Parallel + Always Spawn] 3.756 46.866 0.08 (OK)
[Parallel + Thread Pool + Spin] 3.746 44.612 0.08 (OK)
[Parallel + Thread Pool + Sleep] 38.664 20.674 1.87 (NOT OK)
================================================================================
Executing test: super_light...
Reference binary: ./runtasks_ref_osx_arm
Results for: super_light
 STUDENT REFERENCE PERF?
[Serial] 14.85 20.105 0.74 (OK)
[Parallel + Always Spawn] 14.651 52.991 0.28 (OK)
[Parallel + Thread Pool + Spin] 14.855 81.532 0.18 (OK)
[Parallel + Thread Pool + Sleep] 74.186 32.391 2.29 (NOT OK)
================================================================================
Executing test: super_light_async...
Reference binary: ./runtasks_ref_osx_arm
Results for: super_light_async
 STUDENT REFERENCE PERF?
[Serial] 14.814 23.323 0.64 (OK)
[Parallel + Always Spawn] 14.984 47.708 0.31 (OK)
[Parallel + Thread Pool + Spin] 14.843 61.707 0.24 (OK)
[Parallel + Thread Pool + Sleep] 53.509 30.943 1.73 (NOT OK)
================================================================================
Executing test: ping_pong_equal...
Reference binary: ./runtasks_ref_osx_arm
Results for: ping_pong_equal
 STUDENT REFERENCE PERF?
[Serial] 238.754 380.542 0.63 (OK)
[Parallel + Always Spawn] 239.122 94.771 2.52 (NOT OK)
[Parallel + Thread Pool + Spin] 241.022 116.505 2.07 (NOT OK)
[Parallel + Thread Pool + Sleep] 85.505 65.267 1.31 (NOT OK)
================================================================================
Executing test: ping_pong_equal_async...
Reference binary: ./runtasks_ref_osx_arm
Results for: ping_pong_equal_async
 STUDENT REFERENCE PERF?
[Serial] 239.437 403.311 0.59 (OK)
[Parallel + Always Spawn] 239.308 90.367 2.65 (NOT OK)
[Parallel + Thread Pool + Spin] 238.84 88.308 2.70 (NOT OK)
[Parallel + Thread Pool + Sleep] 76.734 63.0 1.22 (NOT OK)
================================================================================
Executing test: ping_pong_unequal...
Reference binary: ./runtasks_ref_osx_arm
Results for: ping_pong_unequal
 STUDENT REFERENCE PERF?
[Serial] 709.493 541.609 1.31 (NOT OK)
[Parallel + Always Spawn] 718.295 100.511 7.15 (NOT OK)
[Parallel + Thread Pool + Spin] 703.033 127.53 5.51 (NOT OK)
[Parallel + Thread Pool + Sleep] 125.17 75.149 1.67 (NOT OK)
================================================================================
Executing test: ping_pong_unequal_async...
Reference binary: ./runtasks_ref_osx_arm
Results for: ping_pong_unequal_async
 STUDENT REFERENCE PERF?
[Serial] 721.091 539.725 1.34 (NOT OK)
[Parallel + Always Spawn] 717.866 99.581 7.21 (NOT OK)
[Parallel + Thread Pool + Spin] 713.579 103.787 6.88 (NOT OK)
[Parallel + Thread Pool + Sleep] 122.256 73.192 1.67 (NOT OK)
================================================================================
Executing test: recursive_fibonacci...
Reference binary: ./runtasks_ref_osx_arm
Results for: recursive_fibonacci
 STUDENT REFERENCE PERF?
[Serial] 959.968 959.784 1.00 (OK)
[Parallel + Always Spawn] 954.509 89.347 10.68 (NOT OK)
[Parallel + Thread Pool + Spin] 953.338 93.124 10.24 (NOT OK)
[Parallel + Thread Pool + Sleep] 91.292 87.707 1.04 (OK)
================================================================================
Executing test: recursive_fibonacci_async...
Reference binary: ./runtasks_ref_osx_arm
Results for: recursive_fibonacci_async
 STUDENT REFERENCE PERF?
[Serial] 948.398 951.048 1.00 (OK)
[Parallel + Always Spawn] 949.616 90.487 10.49 (NOT OK)
[Parallel + Thread Pool + Spin] 951.274 89.336 10.65 (NOT OK)
[Parallel + Thread Pool + Sleep] 86.217 86.383 1.00 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop...
Reference binary: ./runtasks_ref_osx_arm
Results for: math_operations_in_tight_for_loop
 STUDENT REFERENCE PERF?
[Serial] 211.938 214.021 0.99 (OK)
[Parallel + Always Spawn] 212.06 261.459 0.81 (OK)
[Parallel + Thread Pool + Spin] 211.18 338.989 0.62 (OK)
[Parallel + Thread Pool + Sleep] 275.752 107.634 2.56 (NOT OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_async...
Reference binary: ./runtasks_ref_osx_arm
Results for: math_operations_in_tight_for_loop_async
 STUDENT REFERENCE PERF?
[Serial] 213.092 213.828 1.00 (OK)
[Parallel + Always Spawn] 211.787 254.468 0.83 (OK)
[Parallel + Thread Pool + Spin] 212.237 211.598 1.00 (OK)
[Parallel + Thread Pool + Sleep] 213.743 94.511 2.26 (NOT OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fewer_tasks...
Reference binary: ./runtasks_ref_osx_arm
Results for: math_operations_in_tight_for_loop_fewer_tasks
 STUDENT REFERENCE PERF?
[Serial] 211.907 214.769 0.99 (OK)
[Parallel + Always Spawn] 210.929 259.859 0.81 (OK)
[Parallel + Thread Pool + Spin] 211.207 311.943 0.68 (OK)
[Parallel + Thread Pool + Sleep] 240.632 102.62 2.34 (NOT OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fewer_tasks_async...
Reference binary: ./runtasks_ref_osx_arm
Results for: math_operations_in_tight_for_loop_fewer_tasks_async
 STUDENT REFERENCE PERF?
[Serial] 213.373 213.476 1.00 (OK)
[Parallel + Always Spawn] 211.305 264.555 0.80 (OK)
[Parallel + Thread Pool + Spin] 211.191 24.4 8.66 (NOT OK)
[Parallel + Thread Pool + Sleep] 24.207 22.182 1.09 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fan_in...
Reference binary: ./runtasks_ref_osx_arm
Results for: math_operations_in_tight_for_loop_fan_in
 STUDENT REFERENCE PERF?
[Serial] 109.248 109.114 1.00 (OK)
[Parallel + Always Spawn] 109.071 41.26 2.64 (NOT OK)
[Parallel + Thread Pool + Spin] 108.701 56.159 1.94 (NOT OK)
[Parallel + Thread Pool + Sleep] 49.214 26.947 1.83 (NOT OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fan_in_async...
Reference binary: ./runtasks_ref_osx_arm
Results for: math_operations_in_tight_for_loop_fan_in_async
 STUDENT REFERENCE PERF?
[Serial] 109.575 110.209 0.99 (OK)
[Parallel + Always Spawn] 109.705 39.58 2.77 (NOT OK)
[Parallel + Thread Pool + Spin] 109.434 15.786 6.93 (NOT OK)
[Parallel + Thread Pool + Sleep] 15.39 12.864 1.20 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_reduction_tree...
Reference binary: ./runtasks_ref_osx_arm
Results for: math_operations_in_tight_for_loop_reduction_tree
 STUDENT REFERENCE PERF?
[Serial] 108.948 110.078 0.99 (OK)
[Parallel + Always Spawn] 109.232 17.412 6.27 (NOT OK)
[Parallel + Thread Pool + Spin] 108.214 18.468 5.86 (NOT OK)
[Parallel + Thread Pool + Sleep] 16.801 14.004 1.20 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_reduction_tree_async...
Reference binary: ./runtasks_ref_osx_arm
Results for: math_operations_in_tight_for_loop_reduction_tree_async
 STUDENT REFERENCE PERF?
[Serial] 108.334 109.013 0.99 (OK)
[Parallel + Always Spawn] 108.57 18.118 5.99 (NOT OK)
[Parallel + Thread Pool + Spin] 108.267 10.62 10.19 (NOT OK)
[Parallel + Thread Pool + Sleep] 10.563 10.466 1.01 (OK)
================================================================================
Executing test: spin_between_run_calls...
Reference binary: ./runtasks_ref_osx_arm
Results for: spin_between_run_calls
 STUDENT REFERENCE PERF?
[Serial] 340.303 342.15 0.99 (OK)
[Parallel + Always Spawn] 336.455 170.749 1.97 (NOT OK)
[Parallel + Thread Pool + Spin] 334.875 173.104 1.93 (NOT OK)
[Parallel + Thread Pool + Sleep] 172.416 171.488 1.01 (OK)
================================================================================
Executing test: spin_between_run_calls_async...
Reference binary: ./runtasks_ref_osx_arm
Results for: spin_between_run_calls_async
 STUDENT REFERENCE PERF?
[Serial] 338.136 341.188 0.99 (OK)
[Parallel + Always Spawn] 338.978 172.345 1.97 (NOT OK)
[Parallel + Thread Pool + Spin] 336.505 173.104 1.94 (NOT OK)
[Parallel + Thread Pool + Sleep] 172.307 169.91 1.01 (OK)
================================================================================
Executing test: mandelbrot_chunked...
Reference binary: ./runtasks_ref_osx_arm
Results for: mandelbrot_chunked
 STUDENT REFERENCE PERF?
[Serial] 252.483 262.149 0.96 (OK)
[Parallel + Always Spawn] 251.727 23.925 10.52 (NOT OK)
[Parallel + Thread Pool + Spin] 250.249 24.048 10.41 (NOT OK)
[Parallel + Thread Pool + Sleep] 23.44 23.751 0.99 (OK)
================================================================================
Executing test: mandelbrot_chunked_async...
Reference binary: ./runtasks_ref_osx_arm
Results for: mandelbrot_chunked_async
 STUDENT REFERENCE PERF?
[Serial] 251.258 261.307 0.96 (OK)
[Parallel + Always Spawn] 248.815 23.821 10.45 (NOT OK)
[Parallel + Thread Pool + Spin] 245.632 23.781 10.33 (NOT OK)
[Parallel + Thread Pool + Sleep] 23.621 23.713 1.00 (OK)
================================================================================
Overall performance results
[Serial] : Perf did not pass all tests
[Parallel + Always Spawn] : Perf did not pass all tests
[Parallel + Thread Pool + Spin] : Perf did not pass all tests
[Parallel + Thread Pool + Sleep] : Perf did not pass all tests

接下来是 wsl2 的测试结果：

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213


# python3 ../tests/run_test_harness.py -a

runtasks_ref
Linux x86_64
================================================================================
Running task system grading harness... (22 total tests)
 - Detected CPU with 16 execution contexts
 - Task system configured to use at most 16 threads
================================================================================
================================================================================
Executing test: super_super_light...
Reference binary: ./runtasks_ref_linux
Results for: super_super_light
 STUDENT REFERENCE PERF?
[Serial] 8.831 13.11 0.67 (OK)
[Parallel + Always Spawn] 8.804 599.641 0.01 (OK)
[Parallel + Thread Pool + Spin] 8.811 57.77 0.15 (OK)
[Parallel + Thread Pool + Sleep] 130.662 130.013 1.00 (OK)
================================================================================
Executing test: super_super_light_async...
Reference binary: ./runtasks_ref_linux
Results for: super_super_light_async
 STUDENT REFERENCE PERF?
[Serial] 8.866 13.174 0.67 (OK)
[Parallel + Always Spawn] 8.788 598.207 0.01 (OK)
[Parallel + Thread Pool + Spin] 8.821 43.615 0.20 (OK)
[Parallel + Thread Pool + Sleep] 60.365 129.248 0.47 (OK)
================================================================================
Executing test: super_light...
Reference binary: ./runtasks_ref_linux
Results for: super_light
 STUDENT REFERENCE PERF?
[Serial] 60.766 82.207 0.74 (OK)
[Parallel + Always Spawn] 60.947 606.574 0.10 (OK)
[Parallel + Thread Pool + Spin] 60.694 71.464 0.85 (OK)
[Parallel + Thread Pool + Sleep] 120.32 121.31 0.99 (OK)
================================================================================
Executing test: super_light_async...
Reference binary: ./runtasks_ref_linux
Results for: super_light_async
 STUDENT REFERENCE PERF?
[Serial] 60.707 82.553 0.74 (OK)
[Parallel + Always Spawn] 60.597 610.495 0.10 (OK)
[Parallel + Thread Pool + Spin] 60.862 47.856 1.27 (NOT OK)
[Parallel + Thread Pool + Sleep] 41.968 67.151 0.62 (OK)
================================================================================
Executing test: ping_pong_equal...
Reference binary: ./runtasks_ref_linux
Results for: ping_pong_equal
 STUDENT REFERENCE PERF?
[Serial] 974.77 1329.416 0.73 (OK)
[Parallel + Always Spawn] 975.46 657.312 1.48 (NOT OK)
[Parallel + Thread Pool + Spin] 976.396 313.672 3.11 (NOT OK)
[Parallel + Thread Pool + Sleep] 252.91 282.194 0.90 (OK)
================================================================================
Executing test: ping_pong_equal_async...
Reference binary: ./runtasks_ref_linux
Results for: ping_pong_equal_async
 STUDENT REFERENCE PERF?
[Serial] 972.789 1322.778 0.74 (OK)
[Parallel + Always Spawn] 972.383 643.996 1.51 (NOT OK)
[Parallel + Thread Pool + Spin] 972.607 273.881 3.55 (NOT OK)
[Parallel + Thread Pool + Sleep] 155.528 260.81 0.60 (OK)
================================================================================
Executing test: ping_pong_unequal...
Reference binary: ./runtasks_ref_linux
Results for: ping_pong_unequal
 STUDENT REFERENCE PERF?
[Serial] 1882.87 1868.685 1.01 (OK)
[Parallel + Always Spawn] 1898.237 690.707 2.75 (NOT OK)
[Parallel + Thread Pool + Spin] 1880.099 317.811 5.92 (NOT OK)
[Parallel + Thread Pool + Sleep] 325.156 310.165 1.05 (OK)
================================================================================
Executing test: ping_pong_unequal_async...
Reference binary: ./runtasks_ref_linux
Results for: ping_pong_unequal_async
 STUDENT REFERENCE PERF?
[Serial] 1880.953 1873.262 1.00 (OK)
[Parallel + Always Spawn] 1884.994 692.076 2.72 (NOT OK)
[Parallel + Thread Pool + Spin] 1897.06 305.934 6.20 (NOT OK)
[Parallel + Thread Pool + Sleep] 266.364 294.205 0.91 (OK)
================================================================================
Executing test: recursive_fibonacci...
Reference binary: ./runtasks_ref_linux
Results for: recursive_fibonacci
 STUDENT REFERENCE PERF?
[Serial] 1014.363 1864.386 0.54 (OK)
[Parallel + Always Spawn] 1020.526 228.204 4.47 (NOT OK)
[Parallel + Thread Pool + Spin] 1016.456 238.249 4.27 (NOT OK)
[Parallel + Thread Pool + Sleep] 139.825 203.31 0.69 (OK)
================================================================================
Executing test: recursive_fibonacci_async...
Reference binary: ./runtasks_ref_linux
Results for: recursive_fibonacci_async
 STUDENT REFERENCE PERF?
[Serial] 1014.671 1860.244 0.55 (OK)
[Parallel + Always Spawn] 1014.684 232.264 4.37 (NOT OK)
[Parallel + Thread Pool + Spin] 1016.029 209.449 4.85 (NOT OK)
[Parallel + Thread Pool + Sleep] 133.688 202.183 0.66 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop
 STUDENT REFERENCE PERF?
[Serial] 632.822 666.589 0.95 (OK)
[Parallel + Always Spawn] 635.033 3046.272 0.21 (OK)
[Parallel + Thread Pool + Spin] 632.319 353.398 1.79 (NOT OK)
[Parallel + Thread Pool + Sleep] 596.014 610.595 0.98 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_async...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_async
 STUDENT REFERENCE PERF?
[Serial] 634.919 665.761 0.95 (OK)
[Parallel + Always Spawn] 633.117 3036.841 0.21 (OK)
[Parallel + Thread Pool + Spin] 634.344 237.828 2.67 (NOT OK)
[Parallel + Thread Pool + Sleep] 145.622 300.302 0.48 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fewer_tasks...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_fewer_tasks
 STUDENT REFERENCE PERF?
[Serial] 636.664 665.167 0.96 (OK)
[Parallel + Always Spawn] 637.362 3134.877 0.20 (OK)
[Parallel + Thread Pool + Spin] 635.676 271.59 2.34 (NOT OK)
[Parallel + Thread Pool + Sleep] 627.586 617.228 1.02 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fewer_tasks_async...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_fewer_tasks_async
 STUDENT REFERENCE PERF?
[Serial] 639.336 666.136 0.96 (OK)
[Parallel + Always Spawn] 640.35 3133.556 0.20 (OK)
[Parallel + Thread Pool + Spin] 639.268 88.845 7.20 (NOT OK)
[Parallel + Thread Pool + Sleep] 80.065 620.919 0.13 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fan_in...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_fan_in
 STUDENT REFERENCE PERF?
[Serial] 331.053 342.919 0.97 (OK)
[Parallel + Always Spawn] 327.84 415.618 0.79 (OK)
[Parallel + Thread Pool + Spin] 328.253 128.856 2.55 (NOT OK)
[Parallel + Thread Pool + Sleep] 102.647 104.537 0.98 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_fan_in_async...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_fan_in_async
 STUDENT REFERENCE PERF?
[Serial] 327.295 345.385 0.95 (OK)
[Parallel + Always Spawn] 327.776 412.113 0.80 (OK)
[Parallel + Thread Pool + Spin] 328.803 51.38 6.40 (NOT OK)
[Parallel + Thread Pool + Sleep] 41.518 47.11 0.88 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_reduction_tree...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_reduction_tree
 STUDENT REFERENCE PERF?
[Serial] 325.711 341.696 0.95 (OK)
[Parallel + Always Spawn] 324.627 115.974 2.80 (NOT OK)
[Parallel + Thread Pool + Spin] 323.884 58.146 5.57 (NOT OK)
[Parallel + Thread Pool + Sleep] 59.128 60.844 0.97 (OK)
================================================================================
Executing test: math_operations_in_tight_for_loop_reduction_tree_async...
Reference binary: ./runtasks_ref_linux
Results for: math_operations_in_tight_for_loop_reduction_tree_async
 STUDENT REFERENCE PERF?
[Serial] 327.136 340.083 0.96 (OK)
[Parallel + Always Spawn] 324.501 116.149 2.79 (NOT OK)
[Parallel + Thread Pool + Spin] 325.255 43.811 7.42 (NOT OK)
[Parallel + Thread Pool + Sleep] 38.818 41.494 0.94 (OK)
================================================================================
Executing test: spin_between_run_calls...
Reference binary: ./runtasks_ref_linux
Results for: spin_between_run_calls
 STUDENT REFERENCE PERF?
[Serial] 363.723 663.649 0.55 (OK)
[Parallel + Always Spawn] 363.693 339.764 1.07 (OK)
[Parallel + Thread Pool + Spin] 364.711 460.236 0.79 (OK)
[Parallel + Thread Pool + Sleep] 278.05 332.255 0.84 (OK)
================================================================================
Executing test: spin_between_run_calls_async...
Reference binary: ./runtasks_ref_linux
Results for: spin_between_run_calls_async
 STUDENT REFERENCE PERF?
[Serial] 362.584 664.393 0.55 (OK)
[Parallel + Always Spawn] 362.411 334.19 1.08 (OK)
[Parallel + Thread Pool + Spin] 363.12 473.104 0.77 (OK)
[Parallel + Thread Pool + Sleep] 255.535 331.168 0.77 (OK)
================================================================================
Executing test: mandelbrot_chunked...
Reference binary: ./runtasks_ref_linux
Results for: mandelbrot_chunked
 STUDENT REFERENCE PERF?
[Serial] 432.242 429.148 1.01 (OK)
[Parallel + Always Spawn] 431.654 33.034 13.07 (NOT OK)
[Parallel + Thread Pool + Spin] 431.36 32.959 13.09 (NOT OK)
[Parallel + Thread Pool + Sleep] 31.432 32.407 0.97 (OK)
================================================================================
Executing test: mandelbrot_chunked_async...
Reference binary: ./runtasks_ref_linux
Results for: mandelbrot_chunked_async
 STUDENT REFERENCE PERF?
[Serial] 430.727 428.21 1.01 (OK)
[Parallel + Always Spawn] 431.037 31.553 13.66 (NOT OK)
[Parallel + Thread Pool + Spin] 431.366 33.024 13.06 (NOT OK)
[Parallel + Thread Pool + Sleep] 32.403 31.052 1.04 (OK)
================================================================================
Overall performance results
[Serial] : All passed Perf
[Parallel + Always Spawn] : Perf did not pass all tests
[Parallel + Thread Pool + Spin] : Perf did not pass all tests
[Parallel + Thread Pool + Sleep] : All passed Perf

『学习笔记』CS149 (2024): Assignment 3

Sat, 16 Aug 2025 02:46:17 +0000

CS149 (2024): Assignment 3

封面来源：@ch00suke

因为对着 15418 2016 看，顺序是先讲了写 CUDA，那就先做 Asst3 吧，做到一半感觉难度曲线有些高，滚去看了 CS149 的slides，dataparallel （于是后面觉得还是对着 CS149 学吧，逃）

相关文章：CS149 Programming Assignment 3 - A Simple Renderer in CUDA | MizukiCry’s Blog

原始实验材料仓库：stanford-cs149/asst3

我的实现仓库：Livinfly/15-418u15-618uCS149u

任务推荐资料：

The CUDA C programmer’s guide PDF 版本或 web 版本

CUDA 教程和 SDK 例子 Google 或 NVIDIA developer site

计算能力文档 CUDA C Programming Guide

C++ 的一些特性 C++ Super-FAQ

关于 pinned Optimizing Host-Device Data Communication I -Pinned Host Memory: DD2360 HT19 (50340) Applied GPU Programming

An Easy Introduction to CUDA C and C++ | NVIDIA Technical Blog

（更新版）An Even Easier Introduction to CUDA (Updated) | NVIDIA Technical Blog （新接触到 grid-stride loop 写法，Where To From Here?，有不少经典优化方法，还没直接去看）

[!TIP]

建议进入 c++ edit configuration，

添加 "C:\\Program Files\\NVIDIA GPU Computing Toolkit\\CUDA\\v12.1\\**" 的路径类似物到 includePath，获取一些补全。

环境

因为本机没有 N 卡，在另一台 1660s 的机器上 ssh 做，这里给出这台机器的环境。

1
2
3
4
5
6


# 系统版本
uname -a
lsb_release -a
nvidia-smi
cat /proc/cpuinfo
cat /proc/cpuinfo | grep processor | wc -l

OS: Windows10 - wsl2 (6.6.87.2-microsoft-standard-WSL2) - Ubuntu 22.04.5 LTS
CPU: AMD Ryzen 5 3600 6-Core Processor (6 cores, 12 processors)
GPU: NVIDIA GeForce GTX 1660 super (6 GB, bandwidth 336 GB/s, 192-bit bus), Driver Version: 576.02, CUDA Version: 12.9
Python 3.10.1

Part 1: CUDA Warm-Up 1: SAXPY

自行查看学习cudaMemcpy的定义。（应该是在device-memory 这一部分）

文档中已说明，默认情况下，GPU 上的 kernel 调用和 CPU 的主线程是异步的，需要用cudaDeviceSynchronize()同步（CPU 等待 GPU的同步，__syncthreads()是块内同步）。

同时，cudaMemcpy()在我们使用的情况下是同步的；CPU 不能访问cudaMalloc分配在 CUDA 设备的内存（使用cudaMallocManaged分配的可以访问，但按需搬运易有Page Fault，使得 Memory-bound，使用cudaMemPrefetchAsync预取到 Device 上）

任务：实现saxpy.cu。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87


// saxpy.cu
void saxpyCuda(int N, float alpha, float* xarray, float* yarray,
 float* resultarray) {
 // must read both input arrays (xarray and yarray) and write to
 // output array (resultarray)
 int totalBytes = sizeof(float) * 3 * N;

 // compute number of blocks and threads per block. In this
 // application we've hardcoded thread blocks to contain 512 CUDA
 // threads.
 const int threadsPerBlock = 512;

 // Notice the round up here. The code needs to compute the number
 // of threads blocks needed such that there is one thread per
 // element of the arrays. This code is written to work for values
 // of N that are not multiples of threadPerBlock.
 const int blocks = (N + threadsPerBlock - 1) / threadsPerBlock;

 // These are pointers that will be pointers to memory allocated
 // *one the GPU*. You should allocate these pointers via
 // cudaMalloc. You can access the resulting buffers from CUDA
 // device kernel code (see the kernel function saxpy_kernel()
 // above) but you cannot access the contents these buffers from
 // this thread. CPU threads cannot issue loads and stores from GPU
 // memory!
 float* device_x = nullptr;
 float* device_y = nullptr;
 float* device_result = nullptr;

 //
 // CS149 TODO: allocate device memory buffers on the GPU using cudaMalloc.
 //
 // We highly recommend taking a look at NVIDIA's
 // tutorial, which clearly walks you through the few lines of code
 // you need to write for this part of the assignment:
 //
 // https://devblogs.nvidia.com/easy-introduction-cuda-c-and-c/
 //

 // start timing after allocation of device memory
 // cudaSetDevice(0);
 cudaMalloc(&device_x, sizeof(float) * N);
 cudaMalloc(&device_y, sizeof(float) * N);
 cudaMalloc(&device_result, sizeof(float) * N);

 double startTime = CycleTimer::currentSeconds();
 //
 // CS149 TODO: copy input arrays to the GPU using cudaMemcpy
 //
 cudaMemcpy(device_x, xarray, sizeof(float) * N, cudaMemcpyHostToDevice);
 cudaMemcpy(device_y, yarray, sizeof(float) * N, cudaMemcpyHostToDevice);
 // run CUDA kernel. (notice the <<< >>> brackets indicating a CUDA
 // kernel launch) Execution on the GPU occurs here.

 double startKernelTime = CycleTimer::currentSeconds();
 saxpy_kernel<<<blocks, threadsPerBlock>>>(N, alpha, device_x, device_y,
 device_result);
 cudaDeviceSynchronize();
 double endKernelTime = CycleTimer::currentSeconds();

 //
 // CS149 TODO: copy result from GPU back to CPU using cudaMemcpy
 //
 cudaMemcpy(resultarray, device_result, sizeof(float) * N,
 cudaMemcpyDeviceToHost);
 // end timing after result has been copied back into host memory
 double endTime = CycleTimer::currentSeconds();

 cudaError_t errCode = cudaPeekAtLastError();
 if (errCode != cudaSuccess) {
 fprintf(stderr, "WARNING: A CUDA error occured: code=%d, %s\n", errCode,
 cudaGetErrorString(errCode));
 }

 double overallDuration = endTime - startTime;
 double overallKernelDuration = endKernelTime - startKernelTime;
 printf("Effective BW by CUDA saxpy: %.3f ms\t\t[%.3f GB/s]\n",
 1000.f * overallDuration, GBPerSec(totalBytes, overallDuration));
 printf("Effective kernel by CUDA saxpy: %.3f ms\n",
 1000.f * overallKernelDuration);
 //
 // CS149 TODO: free memory buffers on the GPU using cudaFree
 //
 cudaFree(device_x);
 cudaFree(device_y);
 cudaFree(device_result);
}

运行结果：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# N 默认 100M
---------------------------------------------------------
Found 1 CUDA devices
Device 0: NVIDIA GeForce GTX 1660 SUPER
 SMs: 22
 Global mem: 6144 MB
 CUDA Cap: 7.5
---------------------------------------------------------
Running 3 timing tests:
Effective BW by CUDA saxpy: 201.713 ms [5.540 GB/s]
Effective kernel by CUDA saxpy: 5.995 ms
Effective BW by CUDA saxpy: 214.931 ms [5.200 GB/s]
Effective kernel by CUDA saxpy: 4.311 ms
Effective BW by CUDA saxpy: 185.933 ms [6.011 GB/s]
Effective kernel by CUDA saxpy: 4.790 ms

# startTime 计时如果放在，分配 cudaMalloc 之前
Running 3 timing tests:
Effective BW by CUDA saxpy: 447.963 ms [2.495 GB/s]
Effective kernel by CUDA saxpy: 6.083 ms
Effective BW by CUDA saxpy: 205.574 ms [5.436 GB/s]
Effective kernel by CUDA saxpy: 4.299 ms
Effective BW by CUDA saxpy: 218.466 ms [5.116 GB/s]
Effective kernel by CUDA saxpy: 4.311 ms

为什么第一次会慢 250ms 左右呢？

CUDA 上下文创建，在第一次调用需要与 GPU 通信的 CUDA API 时会触发，后续所有的 CUDA API 调用都可以快速执行了。

手动初始化（CUDA 上下文创建），cudaSetDevice(Device)，下面这种写法，第一次的测试速度与后两次无异。

1
2
3
4
5
6
7


cudaSetDevice(0);

double startTime = CycleTimer::currentSeconds();

cudaMalloc(&device_x, sizeof(float) * N);
cudaMalloc(&device_y, sizeof(float) * N);
cudaMalloc(&device_result, sizeof(float) * N);

对比 Asst1 的saxpy的串行实现与 ISPC 实现，实验结果如下：

1
2
3
4
5
6
7
8
9


// 为了实验参数对齐，N 为 100M（默认 20M）
[saxpy serial]: [60.025] ms [24.825] GB/s [3.332] GFLOPS
[saxpy avx2]: [34.177] ms [43.600] GB/s [5.852] GFLOPS
[saxpy ispc]: [53.822] ms [27.686] GB/s [3.716] GFLOPS
[saxpy task ispc]: [44.228] ms [33.692] GB/s [4.522] GFLOPS
 (1.76x speedup from My AVX2)
 (1.22x speedup from use of tasks)
 (1.12x speedup from ISPC)
 (1.36x speedup from task ISPC)

对比串行，能快 10~12 倍，但是内存通信的开销大。

对比峰值内存带宽，显然没有达到预期。

不难发现，数据移动占了绝大部分的时间，导致整个运算总时间比串行还长。

根据材料给出的视频 / 文字稿学习。

原因是cudaMemcpy()的实现使用 DMA 设备，在 Host 端，DMA 操作的是物理地址，会出现超出一页 page 的情况，导致错误。

所以，DMA 的传输源必须是固定内存 pinned memory（特殊标记的虚拟内存页面），所以在传输时，会先复制到 pinned memory 中，产生额外开销。

因此，优化数据移动，我们可以使用以下方法：

使用 pinned memory，具体地，使用cudaMallocHost()或cudaHostAlloc()而不是malloc()或new。

两个函数的区别是，如果要兼容特别老的 CUDA 版本，需要用前者，后者提供了额外的 flag 来操控，是前者的超集。

cuda-runtime-api cudaHostAlloc 和cudaMallocHost and cudaHostAlloc differences and usage 。
使用 pinned memory 时，可以小数据传输批量处理成一次大数据传输。（我的测试试验中好像变化不大，可能是只有两段数据，不明显，便不列出来了）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// main.cpp

// pinned memory
float* xarray = nullptr;
float* yarray = nullptr;
float* resultarray = nullptr;
// cudaMallocHost(&xarray, sizeof(float) * N);
// cudaMallocHost(&yarray, sizeof(float) * N);
// cudaMallocHost(&resultarray, sizeof(float) * N);
cudaHostAlloc(&xarray, sizeof(float) * N, cudaHostAllocDefault);
cudaHostAlloc(&xarray, sizeof(float) * N, cudaHostAllocDefault);
cudaHostAlloc(&xarray, sizeof(float) * N, cudaHostAllocDefault);

// pinned memory
cudaFreeHost(xarray);
cudaFreeHost(yarray);
cudaFreeHost(resultarray);

运行结果：

1
2
3
4
5
6
7


Running 3 timing tests:
Effective BW by CUDA saxpy: 117.512 ms [9.510 GB/s]
Effective kernel by CUDA saxpy: 5.163 ms
Effective BW by CUDA saxpy: 116.699 ms [9.577 GB/s]
Effective kernel by CUDA saxpy: 4.826 ms
Effective BW by CUDA saxpy: 110.485 ms [10.115 GB/s]
Effective kernel by CUDA saxpy: 4.140 ms

加速效果明显，数据搬运耗时减少一半，符合预期。

同时，还尝试了cudaMemcpyAsync()，不过效果同样不明显，不再列出。

Part 2: CUDA Warm-Up 2: Parallel Prefix-Sum

实验中给出的nextPow2()只使用于大于零的情况，还有1<<(__lg(n-1)+1)可能不被某些编译器兼容的求法。

cpu_exclusive_scan()的PARALLEL版本，用来验证，需要数组长度为2的倍数，不然结果有误。
修改 Device 中的内存，直接修改直接报段错误；需要用cudaMemset()等其他 CUDA API 来操作，注意同步。

因为写这部分代码的时候，没文档记录，具体的情况与结果标写在注释中了，劳烦翻阅。

下面就对着代码，然后说明我遇到的一些情况。

Exclusive Prefix Sum

根据任务要求给出的示例串行代码实现一下就可以。

首先，先说一下 cpu_exclusive_scan() 的模拟并行部分的使用问题。

在 upsweep 阶段，twod <= N / 2是要带上等号的，虽然对于 exclusive_scan 的结果不影响，但不符合定义上的要求，区别见下。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


# cpu_exclusive_scan
(two_d < N / 2)
 ./cudaScan -i ones -n 7
 Array size: 7
 1 2 1 4 1 2 1 (upsweep phase)
 2 3 4 6 3 4 3 (downsweep phase)

 ./cudaScan -i ones -n 8
 Array size: 8
 1 2 1 4 1 2 1 4 (upsweep phase)
 0 1 2 3 4 5 6 7 (downsweep phase)

(two_d <= N / 2)
 ./cudaScan -i ones -n 7
 Array size: 7
 1 2 1 4 1 2 1 (upsweep phase)
 2 3 4 6 3 4 3 (downsweep phase)

 ./cudaScan -i ones -n 8
 Array size: 8
 1 2 1 4 1 2 1 8 (upsweep phase)
 0 1 2 3 4 5 6 7 (downsweep phase)

其次，downsweep 阶段，在非 2 的整幂次时，访问 output[i + twod1 - 1] 是溢出的。

若多开空间到 2 的整幂次，根据计算结果的定义，给拓展后的最后一位赋值为 0（或者都初始化为 0）。

总之，修改会同时该比较多的地方，所以，还是就只在 2 的整幂次使用吧。

在实现 CUDA 版本的exclusive_scan()遇到的坑点，下面给出情况解释与分析。

线程总数可能溢出int的问题。

根据分块代码 $\text{idx} = \text{numBlocks} \cross \text{THREADS_PER_BLOCK} = \text{numThreads} + [0, 255]$。

如果在外面乘 $\text{stride_2}$ 变成下标 $\text{idx_} = (\text{numThreads} + ( < 256)) \cross \text{stride_2} = \text{N} + [0, 255] \cross \text{stride_2}$，

$\text{stride_2}$ 范围 $[2, \text{N}]$ 所以，$\text{idx_}$ 范围 $[\text{N}, 256 * \text{N}]$ 这种情况下，$\text{INT_MAX} = 2^{31} - 1$，

在大约超出 $8388607.996 ( ≈ 2^{23})$ 时，会产生溢出。

1
2
3
4
5
6
7
8
9


# (idx < N)，内部的话，因为会申请 nextPow2 的内存，所以不会越界
# 实验结果符合预期：
(idx < N)
 8388608 correct, 8388609 error

(idx + stride_2 - 1 < N)
 4194304 correct, 4194305 error
因为 4194305，N 自动变成 8388608，按照上面的分析，idx 刚好在 int 范围，
在加上，就是刚好不在了，所以报错。

错误代码示例留存：

1
2
3
4
5
6
7


// scan.cu upsweep
int stride_2 = stride * 2;
idx *= stride_2;
assert(1LL * idx + stride_2 - 1 < 2147483647);
if (idx + stride_2 - 1 < numThreads) {
 output[idx + stride_2 - 1] += output[idx + stride - 1];
}

经验就是尽量不要在判断外对 $\text{idx}$ 做其他的运算，找好比较的对象，爆 int 也太难查了。

运行结果：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


-------------------------
Scan Score Table:
-------------------------
-------------------------------------------------------------------------
| Element Count | Ref Time | Student Time | Score |
-------------------------------------------------------------------------
| 1000000 | 1.296 | 2.676 | 0.6053811659192825 |
| 10000000 | 10.398 | 9.67 | 1.25 |
| 20000000 | 20.531 | 16.089 | 1.25 |
| 40000000 | 39.415 | 31.501 | 1.25 |
-------------------------------------------------------------------------
| | Total score: | 4.355381165919282/5.0 |
-------------------------------------------------------------------------

1e6 的没拿满，不太懂，也不是全都开 N 个线程，已经随着遍历改了。

大改写法还是算了。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75


// scan.cu
__global__ void upsweep(int numThreads, int* output, int stride) {
 int idx = blockIdx.x * blockDim.x + threadIdx.x;
 // idx = numBlocks * THREADS_PER_BLOCK = numThreads + [0, 255]
 // 如果在外面乘 stride_2 变成下标
 // idx_ = (numThreads + ( < 256)) * stride_2 = N + [0, 255] * stride_2
 // stride_2 范围 [2, N]
 // 所以，idx_ 范围 [N, 256 * N]
 // 这种情况下，INT_MAX = 2^31 - 1，在大约超出 8388607.996 ( ≈ 2^23)
 // 时，会产生溢出。
 /*
 (idx < N)，内部的话，因为会申请 nextPow2 的内存，所以不会越界
 实验结果符合预期：
 (idx < N)
 8388608 correct, 8388609 error

 (idx + stride_2 - 1 < N)
 4194304 correct, 4194305 error
 因为 4194305，N 自动变成 8388608，按照上面的分析，idx 刚好在 int 范围，
 在加上，就是刚好不在了，所以报错。

 错误代码示例留存：
 int stride_2 = stride * 2;
 idx *= stride_2;
 assert(1LL * idx + stride_2 - 1 < 2147483647);
 if (idx + stride_2 - 1 < numThreads) {
 output[idx + stride_2 - 1] += output[idx + stride - 1];
 }

 经验就是尽量不要在判断外对 idx 做其他的运算，
 找好比较的对象，爆 int 也太难查了。
 */
 if (idx < numThreads) {
 int stride_2 = stride * 2;
 idx *= stride_2;
 output[idx + stride_2 - 1] += output[idx + stride - 1];
 }
}

__global__ void downsweep(int numThreads, int* output, int stride) {
 int idx = blockIdx.x * blockDim.x + threadIdx.x;
 if (idx < numThreads) {
 int stride_2 = stride * 2;
 idx *= stride_2;
 int t = output[idx + stride - 1];
 output[idx + stride - 1] = output[idx + stride_2 - 1];
 output[idx + stride_2 - 1] += t;
 }
}

void exclusive_scan(int* input, int N, int* result) {
 N = nextPow2(N);

 for (int two_d = 1; two_d <= N / 2; two_d *= 2) {
 int two_dplus1 = 2 * two_d;
 int numThreads = N / two_dplus1;
 int numBlocks =
 (numThreads + THREADS_PER_BLOCK - 1) / THREADS_PER_BLOCK;
 upsweep<<<numBlocks, THREADS_PER_BLOCK>>>(numThreads, result, two_d);
 cudaDeviceSynchronize();
 }

 // result[N - 1] = 0;
 cudaMemset(&result[N - 1], 0, sizeof(int));
 cudaDeviceSynchronize();

 for (int two_d = N / 2; two_d >= 1; two_d /= 2) {
 int two_dplus1 = 2 * two_d;
 int numThreads = N / two_dplus1;
 int numBlocks =
 (numThreads + THREADS_PER_BLOCK - 1) / THREADS_PER_BLOCK;
 downsweep<<<numBlocks, THREADS_PER_BLOCK>>>(numThreads, result, two_d);
 cudaDeviceSynchronize();
 }
}

应该挺好用，但是没怎么用的 cudaCheckError

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


#define DEBUG

#ifdef DEBUG
#define cudaCheckError(ans) { cudaAssert((ans), __FILE__, __LINE__); }
inline void cudaAssert(cudaError_t code, const char *file, int line, bool
abort=true)
{
 if (code != cudaSuccess)
 {
 fprintf(stderr, "CUDA Error: %s at %s:%d\n",
 cudaGetErrorString(code), file, line);
 if (abort) exit(code);
 }
}
#else
#define cudaCheckError(ans) ans
#endif

cudaCheckError( cudaMalloc(&a, size*sizeof(int)) );

Find Repeats

还太能直接反映出，并行的实现，有些发懵，先学习了下别人的才反应过来 QnQ。

要利用exclusive_scan()。

先标记和相邻的相同的下标，再利用exclusive_scan()方便后面映射到结果数组，提取出未相邻重复的数。

运行结果：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


-------------------------
Find_repeats Score Table:
-------------------------
-------------------------------------------------------------------------
| Element Count | Ref Time | Student Time | Score |
-------------------------------------------------------------------------
| 1000000 | 2.49 | 3.613 | 0.8614724605590922 |
| 10000000 | 15.93 | 15.16 | 1.25 |
| 20000000 | 32.058 | 22.803 | 1.25 |
| 40000000 | 61.725 | 42.734 | 1.25 |
-------------------------------------------------------------------------
| | Total score: | 4.611472460559092/5.0 |
-------------------------------------------------------------------------``

包括这个 find_repeats，也是只有 1e6 的没拿满，不太清楚是什么问题，甚至拿别人在他的机器上满分的代码，也有部分没拿满。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


// scan.cu
__global__ void find_repeats_kernel_1(int length, int* input, int* device_tmp) {
 int idx = blockIdx.x * blockDim.x + threadIdx.x;
 if (idx + 1 < length) {
 device_tmp[idx] = (input[idx] == input[idx + 1] ? 1 : 0);
 }
}

__global__ void find_repeats_kernel_2(int length, int* device_tmp,
 int* output) {
 int idx = blockIdx.x * blockDim.x + threadIdx.x;
 if (idx + 1 < length && device_tmp[idx] != device_tmp[idx + 1]) {
 output[device_tmp[idx]] = idx;
 }
}

int find_repeats(int* device_input, int length, int* device_output) {
 int N = nextPow2(length);

 int numBlocks = (N + THREADS_PER_BLOCK - 1) / THREADS_PER_BLOCK;
 int* device_tmp;
 cudaMalloc((void**)&device_tmp, N * sizeof(int));

 find_repeats_kernel_1<<<numBlocks, THREADS_PER_BLOCK>>>(
 length, device_input, device_tmp);
 cudaDeviceSynchronize();

 exclusive_scan(device_tmp, length, device_tmp);

 find_repeats_kernel_2<<<numBlocks, THREADS_PER_BLOCK>>>(length, device_tmp,
 device_output);
 cudaDeviceSynchronize();

 int result;
 cudaMemcpy(&result, &device_tmp[length - 1], sizeof(int),
 cudaMemcpyDeviceToHost);

 cudaFree(device_tmp);
 return result;
}

Part 3: A Simple Circle Renderer

如同任务要求开头所说，"Now for the real show!

上来就丢了很多文件和一些说明文档，说原本实现是错的，把他改对。

因为自己在阅读这些资料的过程中，有些迷失了（晕了，看着看着，不知道在看什么，迷茫）。

后参看了下 MizukiCry 这部分的实现，然后重新又自己理了理，写了写。

所以，这部分再会增加一些对代码结构的一些说明。

首先，尝试按照任务说明的编译运行一下，若提示找不到 #include <GL/glut.h>：

1
2


# 安装 GLUT 开发库
sudo apt-get install freeglut3-dev

然后，通过任务要求文档，我们得知，渲染器 renderer 需要按照一定顺序渲染，不然在有图像重叠时，可能会出错。

强调 Atomicity 和 Order。

这两个点，是我们后面具体修正 CUDA 实现的时候需要注意的。

随后，我们开始阅读代码。

发现文件很多，个人建议先主要看main.cpp, refRenderer.cpp / h，cudaRenderer.cu / h，把握核心逻辑，重点在kernelRenderCircles() 和 shadePixel()。

看完 main.cpp 搞清楚程序运行的逻辑后，后面两个文件的大多数函数，我们只要先知道他做了什么，先不要看他的实现逻辑。（比如每个材质，渲染方式不同，这种逻辑看了对我们没有太大的帮助，当然有兴趣都是可以看的，不过容易直接看晕）

之后按照前面提到的 Atomicity 和 Order 的实现原则去检查和渲染 render 相关的代码实现，查看是否有错误。

我觉得主要搞清楚一下一些变量的含义，还有它们的范围之后，应该会好看很多。

再要具体写代码的时候，查看 *.cu_inl 文件，看看有没有可以重复利用的函数。

如果确定了方向，可以先自己尝试去看，还是比较晕，可以看看我下面的 hint。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


struct GlobalConstants {
 SceneName sceneName; // 场景名字

 int numCircles; // 渲染的圆的数量
 float* position; // 位置
 float* velocity; // 速度
 float* color; // 颜色
 float* radius; // 半径

 int imageWidth; // 图片宽度
 int imageHeight; // 图片高度
 float* imageData; // 图片数据
};

具体的存储方式，如 float3，范围的话可以在出现的函数中找到，比如很大部分的值时归一化的 float 存储的，位置分 （x, y, 深度）。

（当然，这些是我理解的，没有仔细查证）

接下来，我介绍我的实现（几种实现的介绍可以参考 data parallel - slide 最后几页）。

我们先思考，CUDA 开的线程是什么信息，圆的编号，还是像素，还是其他？

我这边先给出我第一个实现思路，也是 data parallel - slide 的第一种 solution 1 / 2。（代码统一放在最后）

对每个像素建一个线程，按圆编号顺序以此检查是否在圆内，在圆内才渲染。

满足了两个原则。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


# kernelRenderCircles_1_bf 运行结果
# ./checker.py 

Running scene: rgb...
[rgb] Correctness passed!
[rgb] Student times: [0.3469, 0.3525, 0.362]
[rgb] Reference times: [0.4353, 0.4865, 0.4146]

Running scene: rand10k...
[rand10k] Correctness passed!
[rand10k] Student times: [65.4322, 66.6227, 70.4742]
[rand10k] Reference times: [5.2589, 5.229, 5.3398]

Running scene: rand100k...
[rand100k] Correctness passed!
[rand100k] Student times: [642.4314, 638.4485, 639.3848]
[rand100k] Reference times: [45.3885, 47.9276, 48.3938]

Running scene: pattern...
[pattern] Correctness passed!
[pattern] Student times: [9.0589, 9.1332, 9.0711]
[pattern] Reference times: [0.7231, 0.7794, 0.7507]

Running scene: snowsingle...
[snowsingle] Correctness passed!
[snowsingle] Student times: [595.5139, 593.2695, 597.059]
[snowsingle] Reference times: [29.8196, 30.8086, 30.8295]

Running scene: biglittle...
[biglittle] Correctness passed!
[biglittle] Student times: [91.9496, 88.6234, 88.3303]
[biglittle] Reference times: [27.8894, 27.8606, 28.044]

Running scene: rand1M...
[rand1M] Correctness passed!
[rand1M] Student times: [6243.6725, 6278.3903, 6286.1439]
[rand1M] Reference times: [271.1312, 269.9863, 270.0433]

Running scene: micro2M...
[micro2M] Correctness passed!
[micro2M] Student times: [12637.5187, 12641.5866, 12667.2077]
[micro2M] Reference times: [500.5195, 501.222, 504.6417]
------------
Score table:
------------
--------------------------------------------------------------------------
| Scene Name | Ref Time (T_ref) | Your Time (T) | Score |
--------------------------------------------------------------------------
| rgb | 0.4146 | 0.3469 | 9 |
| rand10k | 5.229 | 65.4322 | 2 |
| rand100k | 45.3885 | 638.4485 | 2 |
| pattern | 0.7231 | 9.0589 | 2 |
| snowsingle | 29.8196 | 593.2695 | 2 |
| biglittle | 27.8606 | 88.3303 | 5 |
| rand1M | 269.9863 | 6243.6725 | 2 |
| micro2M | 500.5195 | 12637.5187 | 2 |
--------------------------------------------------------------------------
| | Total score: | 26/72 |
--------------------------------------------------------------------------

再看到 shadePixel()注释中提到的 specialized template magic，对 shadePixel() 进行模版优化，实现 shadePixel_template()。

（然后就发现差别不大，像是正常波动，就不放出来了，不知道是不是实现的其实有问题？后续也继续用原本的shadePixel()）

后面写优化感觉自己烂完了，看懂 MizukiCry 的版本跑路了。

优化方式就是增加了像素分块，并行检测块是否在圆内，最后把有交集的整理出来，像素并行，顺序遍历这些圆，去渲染。

具体地实现方面，用exclusive_scan()完整并行检测后的排序。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


# MizukiCry 运行结果
# ./checker.py

Running scene: rgb...
[rgb] Correctness passed!
[rgb] Student times: [0.5717, 0.5957, 0.491]
[rgb] Reference times: [0.4137, 0.4899, 0.4276]

Running scene: rand10k...
[rand10k] Correctness passed!
[rand10k] Student times: [6.5862, 6.5918, 6.5984]
[rand10k] Reference times: [5.3212, 5.232, 5.2773]

Running scene: rand100k...
[rand100k] Correctness passed!
[rand100k] Student times: [59.2156, 56.0504, 55.9814]
[rand100k] Reference times: [44.41, 48.7485, 45.5738]

Running scene: pattern...
[pattern] Correctness passed!
[pattern] Student times: [0.8356, 0.9017, 0.841]
[pattern] Reference times: [0.7524, 0.7637, 0.7094]

Running scene: snowsingle...
[snowsingle] Correctness passed!
[snowsingle] Student times: [30.8606, 30.921, 31.0172]
[snowsingle] Reference times: [30.7988, 30.901, 31.0349]

Running scene: biglittle...
[biglittle] Correctness passed!
[biglittle] Student times: [50.6408, 51.9845, 47.8579]
[biglittle] Reference times: [27.885, 28.0244, 27.989]

Running scene: rand1M...
[rand1M] Correctness passed!
[rand1M] Student times: [277.3871, 271.2555, 278.4894]
[rand1M] Reference times: [267.8346, 261.9554, 264.5599]

Running scene: micro2M...
[micro2M] Correctness passed!
[micro2M] Student times: [491.7058, 492.4224, 488.8702]
[micro2M] Reference times: [492.4264, 497.237, 500.9529]
------------
Score table:
------------
--------------------------------------------------------------------------
| Scene Name | Ref Time (T_ref) | Your Time (T) | Score |
--------------------------------------------------------------------------
| rgb | 0.4137 | 0.491 | 9 |
| rand10k | 5.232 | 6.5862 | 8 |
| rand100k | 44.41 | 55.9814 | 8 |
| pattern | 0.7094 | 0.8356 | 9 |
| snowsingle | 30.7988 | 30.8606 | 9 |
| biglittle | 27.885 | 47.8579 | 7 |
| rand1M | 261.9554 | 271.2555 | 9 |
| micro2M | 492.4264 | 488.8702 | 9 |
--------------------------------------------------------------------------
| | Total score: | 68/72 |
--------------------------------------------------------------------------

WSL2 快速配置

Tue, 22 Jul 2025 07:29:46 +0000

WSL2 快速配置

封面来源：@sasamik_

因为近期又重复配 wsl2，干脆自己给自己列一下常见操作。

Windows功能

开启虚拟化相关设置：Hyper-V, 适用于 Linux 的 Windows 子系统等，BIOS 打开虚拟化的设置。

重启生效。

注：如果遇到和虚拟化相关的报错（具体报错信息没有留），可能需要更新 wsl 版本，wsl --update。

1
2
3
4
5


# （以管理员打开 powershell 等）
# 启用适用于 Linux 的 Windows 子系统
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
# 启用虚拟化
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

安装 Linux 内核

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 查看本机有的 Linux 发行版
wsl --list
# 查看可安装的发行版
wsl.exe --list --online
# 安装，如 Ubuntu-22.04
wsl --install <DistributionName>
# 设置默认发行版
wsl --set-default <DistributionName>
# 查看 wsl 发行版本
wsl -l --all -v
# 卸载发行版
wsl --unregister <DistributionName>
# wsl 默认版本设置成 wsl2（可选）
# 注意：wsl2 读取挂载 /mnt 的文件，是通过网络通信的（smb协议）
# 不是 wsl1 的 IO，建议运行先转移到 wsl2 运行下
wsl --set-default-version 2

更改 wsl 的存储位置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 查看 wsl 发行版本，后续的 Ubuntu-22.04 替换成你的发行版
wsl -l --all -v
# 导出发行版为 tar 到存储位置
# 注意：如果需要像我一样，放在某个文件夹下，需要先自己手动建立文件夹（在此命令下就是 wsl2 文件夹）
wsl --export Ubuntu-22.04 d:\wsl2\ubuntu22.04.tar
# 注销当前分发版
wsl --unregister Ubuntu-22.04
# 重新导入，刚刚导出的发行版，并且安装在xxx目录，这里是 d:\wsl2\ubuntu22.04，可以更改
# 如果前面正常设置了，这时遇到导入失败的问题，可以尝试更新 wsl
wsl --import Ubuntu-22.04 d:\wsl2\ubuntu22.04 d:\wsl2\ubuntu22.04.tar --version 2
# 设置默认登录用户名 sername 自选
ubuntu2204 config --default-user <username>
# 删除导出的 tar 文件（可选）
del d:\wsl2\ubuntu22.04.tar
# 设置默认发行版
wsl --set-default <DistributionName>
# 此时，d:\wsl2\ubuntu22.04 就是 wsl 的根目录了

建立网络位置访问

右键此电脑

添加类似于\\wsl.localhost\Ubuntu-22.04\home\luo的地址，具体可以在资源管理器界面的，Linux下访问 wsl 的文件目录，复制下来。

添加后的效果

设置代理

进入 wsl setting 设置 mirror（？）

允许本地局域网请求 Allow LAN 好像就行了

后面的可能不需要（？）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# git
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

# windows 端 crlf
git config core.autocrlf false
git config --global core.autocrlf false
git config --system core.autocrlf false

安装常用环境

1
2
3


sudo apt update
sudo apt-get update
sudo apt install gcc g++

本地 vscode 需要安装 wsl 插件，否则 vscode 上的文件列表更新不及时。

CUDA 根据官方教程安装 CUDA （windows 下 Nvidia 显卡驱动）

1
2
3
4
5
6
7


wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-wsl-ubuntu.pin
sudo mv cuda-wsl-ubuntu.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/12.9.1/local_installers/cuda-repo-wsl-ubuntu-12-9-local_12.9.1-1_amd64.deb
sudo dpkg -i cuda-repo-wsl-ubuntu-12-9-local_12.9.1-1_amd64.deb
sudo cp /var/cuda-repo-wsl-ubuntu-12-9-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-12-9

给bash换皮肤（可选）

在 cmd 下的显示效果好像有问题，Powershell 还ok，vscode 的终端部分显示效果较好。

Starship 的 Pastel Powerline Preset 皮肤，字体网站 Nerd fonts 个人是用 Cascadia Mono。

按照 Starship 安装 Starship，下面以 Linux 上的安装方式为例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 下载 TOML 配置文件（也可以在上面网站上，点击 TOML 的下载链接 或 复制下来创建文件）
wget https://starship.rs/presets/toml/pastel-powerline.toml
# 若没有目标路径，先创建路径，-p 参数用于递归创建，这里可以省略
mkdir -p ~/.config
# 移动到指定路径并改名
mv pastel-powerline.toml ~/.config/starship.toml
# 安装 Starship，这步失败大概率是网络代理配置没配好
curl -sS https://starship.rs/install.sh | sh
# 按照安装成功后，显示的命令行方法，应用，这里给出 bash 的版本
eval "$(starship init bash)"

安装 zsh （可选）

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52


# 安装 zsh
sudo apt install zsh
# 设置默认终端为 zsh，不要用 sudo
chsh -s /bin/zsh
# 安装 oh-my-zsh
# curl sh -c "$(curl -fsSL https://install.ohmyz.sh/)"
# wget sh -c "$(wget -O- https://install.ohmyz.sh/)" # 1
# fetch sh -c "$(fetch -o - https://install.ohmyz.sh/)"
# 国内curl镜像 sh -c "$(curl -fsSL https://gitee.com/pocmon/ohmyzsh/raw/master/tools/install.sh)"
# 国内wget镜像 sh -c "$(wget -O- https://gitee.com/pocmon/ohmyzsh/raw/master/tools/install.sh)"

# 主题 powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k
# 中国用户可以使用 gitee.com 上的官方镜像加速下载
git clone --depth=1 https://gitee.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

vim ~/.zshrc
ZSH_THEME="powerlevel10k/powerlevel10k"
source ~/.zshrc
# 配置
yyy1y1112211111n1
# 内置插件
ls ~/.oh-my-zsh/plugins

# autosuggestions 补全
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
# 中国用户可以使用下面任意一个加速下载
# 加速1
git clone https://github.moeyy.xyz/https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
# 加速2
git clone https://gh.xmly.dev/https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
# 加速3
git clone https://gh.api.99988866.xyz/https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# zsh-syntax-highlighting 语法校验
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting
# 中国用户可以使用下面任意一个加速下载
# 加速1
git clone https://github.moeyy.xyz/https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting
# 加速2
git clone https://gh.xmly.dev/https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting
# 加速3
git clone https://gh.api.99988866.xyz/https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

# z 文件夹快捷跳转
z xxx
# extract 解压任何压缩文件
x xx.tar
# web-search 搜索引擎关键字+搜索内容 google baidu bing

# 启用插件
plugins=(git zsh-autosuggestions zsh-syntax-highlighting z extract web-search jsontools)

vim 配置（可选）

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


# ~/.vimrc
" basic

syntax on
set showmode
set showcmd
set mouse=a
set encoding=utf-8
filetype indent on

" indent

set autoindent
set tabstop=4
set shiftwidth=4
set expandtab
set softtabstop=4

" view

set number
set relativenumber
set cursorline
set textwidth=80
set laststatus=2
set ruler

" search

set hlsearch

" clip

let s:clip = '/mnt/c/Windows/System32/clip.exe' " clip path, depends
if executable(s:clip)
 augroup WSLYank
 autocmd!
 autocmd TextYankPost * if v:event.operator ==# 'y' | call system(s:clip, @0) | endif
 augroup END
endif

miniconda（可选）

https://www.anaconda.com/download/success 找到对应的安装包

1
2
3


wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
# chmod 777 ./Miniconda3-latest-Linux-x86_64.sh
./Miniconda3-latest-Linux-x86_64.sh

参考文章

WSL入门到入土 - 知乎

Win10/11下安装WSL并修改WSL默认安装目录到其他盘_wsl 设置目录-CSDN博客

zsh 安装与配置，使用 oh-my-zsh 美化终端 | Leehow的小站

『学习笔记』CS149 (2024): Assignment 1

Sun, 20 Jul 2025 08:26:06 +0000

封面来源：@ponkotuREIN

相关文章：Stanford-CS149-并行计算-Assignment1-指南 - 知乎

环境

1
2
3


# 系统版本
uname -a
lsb_release -a

OS: Windows11 - wsl2 (6.6.87.2-microsoft-standard-WSL2) - Ubuntu 22.04.5 LTS
CPU: AMD Ryzen 7 6800H (8 cores, 16 logical processors, AVX2 256-bit)
Python 3.10.12

Prog1_mandelbrot_threads

由于笔者设备有 8x2 个逻辑处理器，为了实现原实验的效果（4x2 个逻辑处理器，最大 16 线程），将实验最大线程设为 32 线程。

优化前后的实验结果如下，前两张图为连续等分，第三张图为连续不等分，后两张为交叉等分。（具体耗时结果，可见prog1文件夹下csv文件）。

接下来，回答实验中的问题。

首先，针对加速比没有按照线程数的增长，线性增长。甚至，在图一中，3 线程效率低于 2 线程。

这是由于连续等分的划分方式，对于稀疏运算来说，不同线程的计算量不同，具体地，View 1 的结果如下。

1
2
3


NumThread: 3, Thread: 0, Time: 0.084 ms
NumThread: 3, Thread: 1, Time: 0.261 ms
NumThread: 3, Thread: 2, Time: 0.085 ms

可以发现 Thread 1 是瓶颈。

因此，我观察到图像上下对称，先尝试了连续不均等分，即上下两侧靠外的线程运算的区域大，中间的运算区域小，试图去平衡，各个线程中的计算量，虽然对比连续等分有明显进步，但仍然达不到实验要求。

再之后，根据相近的地方，计算量相似，使用交叉等分的方式划分，使得在到达 8 线程前几乎都是线性加速，Thread 8 达到 7.35x 的加速比。交叉间隔根据图形不同、线程数不同可以再调优。

不同方法，随着线程超过逻辑处理器后的变化，连续等分因为中间的线程负载还是很大，就是根据运算量最大的线程计算量减小而降低，最后到 29 最快，后面可能是因为划分的偏移，又导致峰值变高；连续不等分与交叉等分都是到超过逻辑处理器数量之后，基本维持在同一个加速比，由于划分的区别而产生波动，或因为切换上下文，性能略下降。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


// workerThreadStart 函数实现，三种方法
void workerThreadStart(WorkerArgs* const args) {
 // TODO FOR CS149 STUDENTS: Implement the body of the worker
 // thread here. Each thread should make a call to mandelbrotSerial()
 // to compute a part of the output image. For example, in a
 // program that uses two threads, thread 0 could compute the top
 // half of the image and thread 1 could compute the bottom half.

 // printf("Hello world from thread %d\n", args->threadId);
 double startTime = CycleTimer::currentSeconds();

 // 1. thread 8 => 7.3x speedup
 constexpr unsigned int CHUNK_SIZE = 16;

 for (unsigned int startRow = args->threadId * CHUNK_SIZE;
 startRow < args->height; startRow += args->numThreads * CHUNK_SIZE) {
 int numRows = std::min(CHUNK_SIZE, args->height - startRow);
 mandelbrotSerial(args->x0, args->y0, args->x1, args->y1, args->width,
 args->height, startRow, numRows, args->maxIterations,
 args->output);
 }

 // 2. thread 8 => 5.8x speedup
 // int startRow = 0, nowRow = 0, tot = 0;
 // for (int i = 0; i < args->numThreads; i++) {
 // int j = std::max(i + 1, args->numThreads - i);
 // tot += j * j;
 // if (i == args->threadId - 1)
 // startRow = tot;
 // else if (i == args->threadId)
 // nowRow = tot;
 // }
 // double perThread = static_cast<double>(args->height) / tot;
 // startRow = static_cast<int>(startRow * perThread);
 // nowRow = static_cast<int>(nowRow * perThread);
 // int numRows = nowRow - startRow;
 // if (args->threadId == args->numThreads - 1)
 // numRows = args->height - startRow;
 // mandelbrotSerial(args->x0, args->y0, args->x1, args->y1, args->width,
 // args->height, startRow, numRows, args->maxIterations,
 // args->output);

 // 3. thread 8 => 4.x speedup
 // int perThread = (args->height - 1) / args->numThreads + 1;
 // int startRow = args->threadId * perThread,
 // numRows =
 // std::min(perThread, static_cast<int>(args->height) - startRow);

 // printf("width: %d, height: %d, startRow: %d, numRows: %d\n", args->width,
 // args->height, startRow, numRows);
 // mandelbrotSerial(args->x0, args->y0, args->x1, args->y1, args->width,
 // args->height, startRow, numRows, args->maxIterations,
 // args->output);

 double endTime = CycleTimer::currentSeconds();
 printf("NumThread: %d, Thread: %d, Time: %.3lf ms\n", args->numThreads,
 args->threadId, endTime - startTime);
}

Prog2_vecintrin

观察abs()函数的实现，不难看出，maskAll的初始化存在问题，只有默认值，不能适应多种向量宽度；向量宽度必须是数组长度的因子。

做出如下修改（如需测试，解除main()函数中，相关的注释即可）：

1
2
3
4


// void absVector(float* values, float* output, int N);
// All ones
// maskAll = _cs149_init_ones(); // original
maskAll = _cs149_init_ones(std::min(VECTOR_WIDTH, N - i));

而后参照absVector()函数实现中的vecintrin库函数的应用，照猫画虎。

其中值得注意的是标有corner ???注释的地方，由于库函数实现中，比较函数，未被mask掩盖（为0）时，是沿用目标数组的结果，所以会有需要初始化的地方。

建议多次、多试不同的参数，来测试（写个脚本最好，不过我懒了）。

同时也存在实际不影响的未初始化，比如absVector()中的maskIsNegative，后半部分，其实不是合法的，但是由于只会影响中间结果，不影响最后赋值的情况，所以，不需要额外处理。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49


void clampedExpVector(float* values, int* exponents, float* output, int N) {
 //
 // CS149 STUDENTS TODO: Implement your vectorized version of
 // clampedExpSerial() here.
 //
 // Your solution should work for any value of
 // N and VECTOR_WIDTH, not just when VECTOR_WIDTH divides N
 //
 __cs149_vec_float x, result, oneFloat = _cs149_vset_float(1.f),
 ceiling = _cs149_vset_float(9.999999f);
 __cs149_vec_int y, count, zero = _cs149_vset_int(0),
 oneInt = _cs149_vset_int(1);
 __cs149_mask maskAll, maskEqZero, maskNotEqZero, maskGtCeiling,
 maskCountGtZero;

 for (int i = 0; i < N; i += VECTOR_WIDTH) {
 // 全 1（且未越界）
 maskAll = _cs149_init_ones(std::min(VECTOR_WIDTH, N - i));
 _cs149_vload_float(x, values + i, maskAll); // x = value[i];
 _cs149_vload_int(y, exponents + i, maskAll); // y = exponents[i];
 // 等于 0（且未越界）
 maskEqZero = _cs149_init_ones(0); // init corner ???
 _cs149_veq_int(maskEqZero, y, zero, maskAll); // if (y == 0) {
 _cs149_vstore_float(output + i, oneFloat,
 maskEqZero); // output[i] = 1.f;
 // 不等于 0（且未越界）
 maskNotEqZero = _cs149_mask_not(maskEqZero); // if (y != 0) {
 maskNotEqZero = _cs149_mask_and(maskNotEqZero, maskAll); // corner ???
 _cs149_vmove_float(result, x, maskNotEqZero); // result = x;
 count = _cs149_vset_int(0); // init ???
 _cs149_vsub_int(count, y, oneInt, maskNotEqZero); // count = y - 1;
 maskCountGtZero = _cs149_init_ones(0); // corner ???
 _cs149_vgt_int(maskCountGtZero, count, zero, maskNotEqZero);
 while (_cs149_cntbits(maskCountGtZero) > 0) { // while (count > 0) {
 _cs149_vmult_float(result, result, x,
 maskCountGtZero); // result *= x;
 _cs149_vsub_int(count, count, oneInt, maskCountGtZero); // count--;
 _cs149_vgt_int(maskCountGtZero, count, zero, maskNotEqZero);
 }
 // 大于上界值（且未越界）
 // maskGtCeiling = _cs149_init_ones(0); // corner ??? can remove.
 _cs149_vgt_float(maskGtCeiling, result, ceiling,
 maskNotEqZero); // if (result > 9.999999f) {
 _cs149_vmove_float(result, ceiling,
 maskGtCeiling); // result = 9.999999f;
 _cs149_vstore_float(output + i, result,
 maskNotEqZero); // output[i] = result;
 }
}

然后是实验要求第二点所要求的测试。

发现随着VECTOR_WIDTH增大，vector utilization减小。

在测试设置的参数下，向量位宽都是长度的因子，不存在浪费增多的问题。

观察到计算方式是(double)stats.utilized_lane/stats.total_lane*100，也就是输出log时，活跃的*和不活跃的_之比，猜测是向量位宽越长，出现发散Divergence的概率越大。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68


# Test ./myexp -s 10000
# 测试时只实现了CLAMPED EXPONENT，忽略ARRAY SUM的结果

Vector_Width = 2:

[1;31mCLAMPED EXPONENT[0m (required)
Results matched with answer!
****************** Printing Vector Unit Statistics *******************
Vector Width: 2
Total Vector Instructions: 172728
Vector Utilization: 83.8%
Utilized Vector Lanes: 289354
Total Vector Lanes: 345456
************************ Result Verification *************************
Passed!!!

[1;31mARRAY SUM[0m (bonus)
Expected 9825.218750, got 0.000000
.@@@ Failed!!!
Vector_Width = 4:
[1;31mCLAMPED EXPONENT[0m (required)
Results matched with answer!
****************** Printing Vector Unit Statistics *******************
Vector Width: 4
Total Vector Instructions: 99576
Vector Utilization: 78.6%
Utilized Vector Lanes: 313250
Total Vector Lanes: 398304
************************ Result Verification *************************
Passed!!!

[1;31mARRAY SUM[0m (bonus)
Expected 9825.218750, got 0.000000
.@@@ Failed!!!

Vector_Width = 8:

[1;31mCLAMPED EXPONENT[0m (required)
Results matched with answer!
****************** Printing Vector Unit Statistics *******************
Vector Width: 8
Total Vector Instructions: 54128
Vector Utilization: 76.0%
Utilized Vector Lanes: 329300
Total Vector Lanes: 433024
************************ Result Verification *************************
Passed!!!

[1;31mARRAY SUM[0m (bonus)
Expected 9825.218750, got 0.000000
.@@@ Failed!!!

Vector_Width = 16:

[1;31mCLAMPED EXPONENT[0m (required)
Results matched with answer!
****************** Printing Vector Unit Statistics *******************
Vector Width: 16
Total Vector Instructions: 28218
Vector Utilization: 74.9%
Utilized Vector Lanes: 337955
Total Vector Lanes: 451488
************************ Result Verification *************************
Passed!!!

[1;31mARRAY SUM[0m (bonus)
Expected 9825.218750, got 0.000000
.@@@ Failed!!!

最后是arraySumVector()，实现比较简单，主要是并行归约/树形归约的优化，在这里优化其实是很小的常数，但是在CUDA编程中，在Reduce归约求和的情境下涉及更多，包括如何优化线程利用率、解决 Bank conflict 等问题。

 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
26
27
28
29
30
31
32
33
34


// returns the sum of all elements in values
// You can assume N is a multiple of VECTOR_WIDTH
// You can assume VECTOR_WIDTH is a power of 2
float arraySumVector(float* values, int N) {
 //
 // CS149 STUDENTS TODO: Implement your vectorized version of arraySumSerial
 // here
 //

 // 实验保证向量位宽是 N 的因子

 // O(N / VECTOR_WIDTH)
 __cs149_vec_float sum = _cs149_vset_float(0.f), tmp;
 __cs149_mask maskAll = _cs149_init_ones(VECTOR_WIDTH);
 for (int i = 0; i < N; i += VECTOR_WIDTH) {
 _cs149_vload_float(tmp, values + i, maskAll);
 _cs149_vadd_float(sum, sum, tmp, maskAll);
 }

 // 1. O(VECTOR_WIDTH)
 // float result = 0.f;
 // for (int i = 0; i < VECTOR_WIDTH; i++) {
 // result += sum.value[i];
 // }
 // return result;

 // 2. O(log2(VECTOR_WIDTH))
 // 并行归约 / 树形归约
 for (int s = VECTOR_WIDTH / 2; s > 0; s >>= 1) {
 _cs149_hadd_float(tmp, sum);
 _cs149_interleave_float(sum, tmp);
 }
 return sum.value[0];
}

prog3_mandelbrot_ispc

任务是优化性能问题。

Part 1.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# ./mandelbrot_ispc -t 
[mandelbrot serial]: [214.754] ms
Wrote image file mandelbrot-serial.ppm
[mandelbrot ispc]: [36.824] ms
Wrote image file mandelbrot-ispc.ppm
[mandelbrot multicore ispc]: [18.593] ms
Wrote image file mandelbrot-task-ispc.ppm
 (5.83x speedup from ISPC)
 (11.55x speedup from task ISPC)

# ./mandelbrot_ispc -t -v 2 
[mandelbrot serial]: [129.845] ms
Wrote image file mandelbrot-serial.ppm
[mandelbrot ispc]: [26.140] ms
Wrote image file mandelbrot-ispc.ppm
[mandelbrot multicore ispc]: [15.506] ms
Wrote image file mandelbrot-task-ispc.ppm
 (4.97x speedup from ISPC)
 (8.37x speedup from task ISPC)

理论加速比为 8，但实际不到 6 倍。

同时，view 2的效果比view 1差。（view 2 更加分散）

推测是，在一个 SIMD 中，有些数据结束得快，有的结束得慢，导致控制流发散Divergence，并且，局部越不同，效果越差。

Part 2.

如 Part 1. 列出的结果，–tasks 加速比多一倍（view 1）。

只修改mandelbrot_ispc_withtasks()的taskCount，由于只修改此函数，不修改内部函数，不是图像高度的因子，会产生越界等情况。

 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
26
27


# taskCount = 2
# ./mandelbrot_ispc -t 
[mandelbrot serial]: [214.754] ms
Wrote image file mandelbrot-serial.ppm
[mandelbrot ispc]: [36.824] ms
Wrote image file mandelbrot-ispc.ppm
[mandelbrot multicore ispc]: [18.593] ms
Wrote image file mandelbrot-task-ispc.ppm
 (5.83x speedup from ISPC)
 (11.55x speedup from task ISPC)

# taskCount = 4
(14.50x speedup from task ISPC)

# taskCount = 8
(23.71x speedup from task ISPC)

# taskCount = 16
(41.14x speedup from task ISPC)

# taskCount = 32
# ./mandelbrot_ispc -t
(64.76x speedup from task ISPC)

# taskCount = 50
# ./mandelbrot_ispc -t
(56.79x speedup from task ISPC)

测试下来 32 是最好的，因为曼德博集合计算量不均，所以，32 比逻辑处理器数量 16 还会大约 50% 的增长，能更加均衡。

直觉上会认为切得越碎应该加速效果会进一步提升，但实际上可能由于再增加，使得负载又不均衡了，同时也会增加调度的开销，加速比又下降了。

因为我的逻辑处理器是实验要求的两倍，实验要求 32 倍加速，我这里获得 64 倍加速，应该也是合格了。

线程抽象 Thread Abstraction 和 ISPC 的任务抽象 Task Abstraction，线程/任务数很多的话（如 10,000），线程抽象创建线程的开销大，而任务抽象能自动分配线程。（？）

foreach是 SIMD 层级的抽象，launch是 Cores 层级的抽象。

Prog4_sqrt

给定实现的测试结果，SIMD 加速 5x，Multi-Core 加速 11.6x ：

1
2
3
4
5
6
7


# ./sqrt
[sqrt serial]: [915.247] ms
[sqrt ispc]: [184.232] ms
[sqrt task ispc]: [15.848] ms
 (4.97x speedup from ISPC)
 (57.75x speedup from task ISPC)
 (11.6x)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


for (unsigned int i = 0; i < N; i++) {
 // TODO: CS149 students. Attempt to change the values in the
 // array here to meet the instructions in the handout: we want
 // to you generate best and worse-case speedups

 // starter code populates array with random input values
 values[i] = .001f + 2.998f * static_cast<float>(rand()) / RAND_MAX;
 // values[i] = 1.f;
 // values[i] = 2.999f;
 // values[i] = ((i % 8) ? 1.f : 2.999f);
}

 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
26
27
28
29
30
31
32


# 初始化 0.001f
[sqrt serial]: [796.618] ms
[sqrt ispc]: [137.250] ms
[sqrt task ispc]: [12.865] ms
 (5.80x speedup from ISPC)
 (61.92x speedup from task ISPC)
 (10.7x)

# 初始化 1.0f
[sqrt serial]: [14.291] ms
[sqrt ispc]: [9.292] ms
[sqrt task ispc]: [6.772] ms
 (1.54x speedup from ISPC)
 (2.11x speedup from task ISPC)
 (1.4x)

# 初始化 2.999f
[sqrt serial]: [1921.892] ms
[sqrt ispc]: [289.794] ms
[sqrt task ispc]: [24.470] ms
 (6.63x speedup from ISPC)
 (78.54x speedup from task ISPC)
 (11.8x)


# 初始化 七个 1.f 和 一个 2.999f 一组，即 values[i] = ((i % 8) ? 1.f : 2.999f);
[sqrt serial]: [262.380] ms
[sqrt ispc]: [289.699] ms
[sqrt task ispc]: [24.079] ms
 (0.91x speedup from ISPC)
 (10.90x speedup from task ISPC)
 (12.0x)

有上述结果可以看出：

SIMD 并行效果最差是分散且大部分都是 lanes 都是空闲的情况下，最好是不分散且计算量大的时候；

Multi-Core 并行效果最差是计算量小的时候，此时线程启动开销大（猜测）。

AVX2 实现一版，因为不熟悉相关指令，基本是让 AI 写对照串行代码，写了一版，然后改了改错。

主要涉及，标量常量转换为向量常量、向量乘、向量减、向量与、向量比较的指令。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68


// 导入相关库
#include <immintrin.h>

void sqrt_my_avx2(int N, float initialGuess, float* values, float* output) {
 static const float kThreshold = 0.00001f;
 const __m256 initialGuess_v = _mm256_set1_ps(initialGuess);
 const __m256 kThreshold_v = _mm256_set1_ps(kThreshold);
 const __m256 one_v = _mm256_set1_ps(1.f);
 const __m256 three_v = _mm256_set1_ps(3.f);
 const __m256 half_v = _mm256_set1_ps(0.5f);

 // 做与操作，实现取绝对值
 const __m256 abs_mask_v =
 _mm256_castsi256_ps(_mm256_set1_epi32(0x7FFFFFFF));

 for (int i = 0; i <= N - 8; i += 8) {
 __m256 x = _mm256_loadu_ps(values + i);
 __m256 guess = initialGuess_v;

 __m256 continue_mask;

 while (true) {
 __m256 guess_sq = _mm256_mul_ps(guess, guess);
 __m256 term = _mm256_mul_ps(guess_sq, x);
 __m256 error =
 _mm256_and_ps((_mm256_sub_ps(term, one_v)), abs_mask_v);

 continue_mask = _mm256_cmp_ps(error, kThreshold_v, _CMP_GT_OQ);

 if (_mm256_movemask_ps(continue_mask) == 0) {
 break;
 }

 __m256 guess_cubed = _mm256_mul_ps(guess_sq, guess);
 __m256 term2 = _mm256_mul_ps(x, guess_cubed);
 __m256 term3 = _mm256_mul_ps(three_v, guess);
 __m256 new_guess_unscaled = _mm256_sub_ps(term3, term2);
 __m256 new_guess = _mm256_mul_ps(new_guess_unscaled, half_v);

 guess = _mm256_blendv_ps(guess, new_guess, continue_mask);
 }

 __m256 result = _mm256_mul_ps(x, guess);
 _mm256_storeu_ps(output + i, result);
 }
}

// main()

// My version of AVX2

double minMyAVX2 = 1e30;
for (int i = 0; i < 3; ++i) {
 double startTime = CycleTimer::currentSeconds();
 sqrt_my_avx2(N, initialGuess, values, output);
 double endTime = CycleTimer::currentSeconds();
 minMyAVX2 = std::min(minMyAVX2, endTime - startTime);
}

printf("[sqrt my avx2]:\t\t[%.3f] ms\n", minMyAVX2 * 1000);

verifyResult(N, output, gold);

// Clear out the buffer
for (unsigned int i = 0; i < N; ++i) output[i] = 0;


printf("\t\t\t\t(%.2fx speedup from My AVX2)\n", minSerial / minMyAVX2);

最后结果是优于 ispc 的版本。

 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
26
27
28
29
30
31
32
33
34
35


# 随机数据
[sqrt serial]: [917.327] ms
[sqrt ispc]: [186.708] ms
[sqrt my avx2]: [155.992] ms
[sqrt task ispc]: [16.230] ms
 (4.91x speedup from ISPC)
 (5.88x speedup from My AVX2)
 (56.52x speedup from task ISPC)

# values[i] = 1.f;
[sqrt serial]: [14.391] ms
[sqrt ispc]: [9.552] ms
[sqrt my avx2]: [8.411] ms
[sqrt task ispc]: [6.627] ms
 (1.51x speedup from ISPC)
 (1.71x speedup from My AVX2)
 (2.17x speedup from task ISPC)

# values[i] = 2.999f;
[sqrt serial]: [1922.672] ms
[sqrt ispc]: [290.222] ms
[sqrt my avx2]: [214.912] ms
[sqrt task ispc]: [24.780] ms
 (6.62x speedup from ISPC)
 (8.95x speedup from My AVX2)
 (77.59x speedup from task ISPC)

# values[i] = ((i % 8) ? 1.f : 2.999f);
[sqrt serial]: [267.990] ms
[sqrt ispc]: [291.000] ms
[sqrt my avx2]: [212.485] ms
[sqrt task ispc]: [27.419] ms
 (0.92x speedup from ISPC)
 (1.26x speedup from My AVX2)
 (9.77x speedup from task ISPC)

Prog5_saxpy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# ./saxpy
[saxpy ispc]: [11.335] ms [26.292] GB/s [3.529] GFLOPS
[saxpy task ispc]: [8.950] ms [33.299] GB/s [4.469] GFLOPS
 (1.27x speedup from use of tasks)

# 取消注释掉后的完整输出
[saxpy serial]: [12.749] ms [23.376] GB/s [3.137] GFLOPS
[saxpy ispc]: [11.794] ms [25.269] GB/s [3.392] GFLOPS
[saxpy task ispc]: [9.080] ms [32.821] GB/s [4.405] GFLOPS
 (1.30x speedup from use of tasks)
 (1.08x speedup from ISPC)
 (1.40x speedup from task ISPC)

tasks 只加速了 1.27x，猜测是卡在 IO 上（内存带宽密集型任务，Memory-Bound），单个计算量不算大，两种方式的加速都很有限。

因为卡在内存带宽上，无法通过优化代码来接近线性加速。

写分配 (Write-Allocate) 机制，写未命中、分配并读取（写入的缓存行）。

为了优化saxpy程序，我们要考虑解决内存带宽的瓶颈。

对于实际 result 只写入，不会读取的写入操作，不做标准写操作的读入缓存行的操作，而是直接写在主内存中
预取数据（未实现）

具体地，用 AVX2 实现了以下内容（由于这些指令需要对齐内存，所以申请内存的方式统一修改）：

1
2


# 在原本的 CXXFLAGS 中加入对 avx2 的支持
CXXFLAGS=-I../common -Iobjs/ -O2 -Wall -mavx2

代码实现：

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66


// main.cpp

#include <immintrin.h>


// stream_ps，直接写入主内存
static void saxpy_avx2(int N, float scale, float* X, float* Y, float* result) {
 const __m256 scale_v = _mm256_set1_ps(scale);

 int i = 0;
 for (; i <= N - 8; i += 8) {
 __m256 x = _mm256_load_ps(X + i), y = _mm256_load_ps(Y + i);
 __m256 res = _mm256_add_ps(_mm256_mul_ps(scale_v, x), y);
 _mm256_stream_ps(result + i, res);
 }
 for (; i < N; i++) {
 result[i] = scale * X[i] + Y[i];
 }
}
/**********************************************************************
[saxpy serial]: [12.063] ms [24.705] GB/s [3.316] GFLOPS
[saxpy avx2]: [6.954] ms [42.859] GB/s [5.752] GFLOPS
[saxpy ispc]: [11.196] ms [26.618] GB/s [3.573] GFLOPS
[saxpy task ispc]: [9.088] ms [32.792] GB/s [4.401] GFLOPS
 (1.73x speedup from My AVX2)
 (1.23x speedup from use of tasks)
 (1.08x speedup from ISPC)
 (1.33x speedup from task ISPC)
**********************************************************************/



// main()
const int ALIGNMENT = 32;

float* arrayX = (float*)_mm_malloc(N * sizeof(float), ALIGNMENT);
float* arrayY = (float*)_mm_malloc(N * sizeof(float), ALIGNMENT);
float* resultSerial = (float*)_mm_malloc(N * sizeof(float), ALIGNMENT);
float* resultISPC = (float*)_mm_malloc(N * sizeof(float), ALIGNMENT);
float* resultTasks = (float*)_mm_malloc(N * sizeof(float), ALIGNMENT);
float* resultAVX2 = (float*)_mm_malloc(N * sizeof(float), ALIGNMENT);

// My AVX2 version

double minAVX2 = 1e30;
for (int i = 0; i < 3; ++i) {
 double startTime = CycleTimer::currentSeconds();
 saxpy_avx2(N, scale, arrayX, arrayY, resultAVX2);
 double endTime = CycleTimer::currentSeconds();
 minAVX2 = std::min(minAVX2, endTime - startTime);
}

verifyResult(N, resultAVX2, resultSerial);

printf("[saxpy avx2]:\t\t[%.3f] ms\t[%.3f] GB/s\t[%.3f] GFLOPS\n",
 minAVX2 * 1000, toBW(TOTAL_BYTES, minAVX2),
 toGFLOPS(TOTAL_FLOPS, minAVX2));

printf("\t\t\t\t(%.2fx speedup from My AVX2)\n", minSerial / minAVX2);

_mm_free(arrayX);
_mm_free(arrayY);
_mm_free(resultAVX2);
_mm_free(resultSerial);
_mm_free(resultISPC);
_mm_free(resultTasks);

从结果上，相比 ISPC 实现，还是有不小的提升的。

Prog6_kmeans

找性能热点 Performance hotspot。

修一些new []的内存，使用delete[]而非free()。
修requirements.txt，matplotlib需要更高级（我安装的3.10.3），适配 Numpy 2，或者就按照文件的版本强制符合。

约 800MB 的用于 grade 的data.dat没有开源给出，但是代码中也给出了 “for fun” 的代码，用于自主测试。

生成完data.dat后，再次注释掉，使用readData()。

M 个 N 维 K 个中心的数据。

 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
26
27
28
29
30
31
32
33
34


// main.cpp

// readData("./data.dat", &data, &clusterCentroids, &clusterAssignments, &M, &N, &K, &epsilon);

// NOTE: if you want to generate your own data (for fun), you can use the below code
M = 1e6;
N = 100;
K = 3;
epsilon = 0.1;

data = new double[M * N];
clusterCentroids = new double[K * N];
clusterAssignments = new int[M];

// Initialize data
initData(data, M, N);
initCentroids(clusterCentroids, K, N);

// Initialize cluster assignments
for (int m = 0; m < M; m++) {
 double minDist = 1e30;
 int bestAssignment = -1;
 for (int k = 0; k < K; k++) {
 double d = dist(&data[m * N], &clusterCentroids[k * N], N);
 if (d < minDist) {
 minDist = d;
 bestAssignment = k;
 }
 }
 clusterAssignments[m] = bestAssignment;
}

// Uncomment to generate data file
writeData("./data.dat", data, clusterCentroids, clusterAssignments, &M, &N, &K, &epsilon);

1
2
3
4


# 默认生成，测试
# ./kmeans
Running K-means with: M=1000000, N=100, K=3, epsilon=0.100000
[Total Time]: 9421.894 ms

 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
26
27


// kmeansThread.cpp
double tot1 = 0.f, tot2 = 0.f, tot3 = 0.f;

// while (!stoppingConditionMet(prevCost, currCost, epsilon, K)) {
 double t1 = CycleTimer::currentSeconds();
 computeAssignments(&args);
 double t2 = CycleTimer::currentSeconds();
 computeCentroids(&args);
 double t3 = CycleTimer::currentSeconds();
 computeCost(&args);
 double t4 = CycleTimer::currentSeconds();
// }
tot1 += t2 - t1;
tot2 += t3 - t2;
tot3 += t4 - t3;

iter = std::max(iter, 1);
tot1 /= iter, tot2 /= iter, tot3 /= iter;
double sum = tot1 + tot2 + tot3;

printf("cost per iteration:\n");
printf("compute Assignments:\t[%.2lf] ms\n", tot1 * 1000);
printf("\t\tout of all: [%.2lf] %%\n", tot1 / sum * 100);
printf("compute Centroids:\t[%.2lf] ms\n", tot2 * 1000);
printf("\t\tout of all: [%.2lf] %%\n", tot2 / sum * 100);
printf("compute Cost:\t\t[%.2lf] ms\n", tot3 * 1000);
printf("\t\tout of all: [%.2lf] %%\n", tot3 / sum * 100);

结果：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 分析性能瓶颈
Running K-means with: M=1000000, N=100, K=3, epsilon=0.100000
cost per iteration:
compute Assignments: [261.63] ms
 out of all: [65.42] %
compute Centroids: [64.91] ms
 out of all: [16.23] %
compute Cost: [73.35] ms
 out of all: [18.34] %
[Total Time]: 9597.698 ms

要达到 2.1x 加速比，重点优化computeAssignments()，其中，为了避免多线程之间的冲突，需要对函数内部进行调整。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68


// kmeansThread.cpp

void computeAssignments(WorkerArgs *const args) {
 double *minDist = new double[args->M];

 // Initialize arrays
 // for (int m = 0; m < args->M; m++) {
 for (int m = args->start; m < args->end; m++) {
 minDist[m] = 1e30;
 args->clusterAssignments[m] = -1;
 }

 // Assign datapoints to closest centroids
 // for (int k = args->start; k < args->end; k++) {
 // for (int m = 0; m < args->M; m++) {
 for (int k = 0; k < args->K; k++) {
 for (int m = args->start; m < args->end; m++) {
 double d = dist(&args->data[m * args->N],
 &args->clusterCentroids[k * args->N], args->N);
 if (d < minDist[m]) {
 minDist[m] = d;
 args->clusterAssignments[m] = k;
 }
 }
 }

 // free(minDist);
 delete[] minDist;
}

// kMeansThread();
static constexpr int numThreads = 8;

int perThread = M / numThreads;

WorkerArgs args[numThreads];
for (int i = 0; i < numThreads; i++) {
 args[i].data = data;
 args[i].clusterCentroids = clusterCentroids;
 args[i].clusterAssignments = clusterAssignments;
 args[i].currCost = currCost;
 args[i].M = M;
 args[i].N = N;
 args[i].K = K;
 args[i].start = i * perThread;
 args[i].end = std::min((i + 1) * perThread, M);
}

std::thread workers[numThreads];

// while (!stoppingConditionMet(prevCost, currCost, epsilon, K)) {
double t1 = CycleTimer::currentSeconds();
for (int i = 1; i < numThreads; i++) {
 workers[i] = thread(computeAssignments, &args[i]);
}
computeAssignments(&args[0]);
for (int i = 1; i < numThreads; i++) {
 workers[i].join();
}
double t2 = CycleTimer::currentSeconds();

args[0].start = 0;
args[0].end = K;
computeCentroids(&args[0]);
double t3 = CycleTimer::currentSeconds();
computeCost(&args[0]);
double t4 = CycleTimer::currentSeconds();
// }

在做出以上computeAssignments()的修改后，八线程加速开销最大的一部分，已达成 2.21x 的加速比。

后续测试numThreads为 4 或 16，效果均不如 8，推测是线程启动开销等原因。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# numThreads = 8
Running K-means with: M=1000000, N=100, K=3, epsilon=0.100000
cost per iteration:
compute Assignments: [60.94] ms
 out of all: [32.30] %
compute Centroids: [52.40] ms
 out of all: [27.78] %
compute Cost: [75.29] ms
 out of all: [39.91] %
[Total Time]: 4338.599 ms

（后来才看到限制Constraints中提到并行化dist, computeAssignments, computeCentroids, computeCost其中一个，反正按照上面的挑选上来说，也是选computeAssignments。

另外几个函数的优化方法类似，建议考虑 M N K 的量级，来权衡开销，有的需要函数内部实现多线程，因为后续有依赖关系，所以就懒得实现了，这里不在给出了代码。）

以下给出完整代码：

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117


void computeAssignments(WorkerArgs *const args) {
 double *minDist = new double[args->M];

 // Initialize arrays
 // for (int m = 0; m < args->M; m++) {
 for (int m = args->start; m < args->end; m++) {
 minDist[m] = 1e30;
 args->clusterAssignments[m] = -1;
 }

 // Assign datapoints to closest centroids
 // for (int k = args->start; k < args->end; k++) {
 // for (int m = 0; m < args->M; m++) {
 for (int k = 0; k < args->K; k++) {
 for (int m = args->start; m < args->end; m++) {
 double d = dist(&args->data[m * args->N],
 &args->clusterCentroids[k * args->N], args->N);
 if (d < minDist[m]) {
 minDist[m] = d;
 args->clusterAssignments[m] = k;
 }
 }
 }

 // free(minDist);
 delete[] minDist;
}

void kMeansThread(double *data, double *clusterCentroids,
 int *clusterAssignments, int M, int N, int K,
 double epsilon) {
 // Used to track convergence
 double *prevCost = new double[K];
 double *currCost = new double[K];

 // The WorkerArgs array is used to pass inputs to and return output from
 // functions.
 static constexpr int numThreads = 8;

 int perThread = M / numThreads;

 WorkerArgs args[numThreads];
 for (int i = 0; i < numThreads; i++) {
 args[i].data = data;
 args[i].clusterCentroids = clusterCentroids;
 args[i].clusterAssignments = clusterAssignments;
 args[i].currCost = currCost;
 args[i].M = M;
 args[i].N = N;
 args[i].K = K;
 args[i].start = i * perThread;
 args[i].end = std::min((i + 1) * perThread, M);
 }

 // Initialize arrays to track cost
 for (int k = 0; k < K; k++) {
 prevCost[k] = 1e30;
 currCost[k] = 0.0;
 }

 double tot1 = 0.f, tot2 = 0.f, tot3 = 0.f;
 std::thread workers[numThreads];

 /* Main K-Means Algorithm Loop */
 int iter = 0;
 while (!stoppingConditionMet(prevCost, currCost, epsilon, K)) {
 // Update cost arrays (for checking convergence criteria)
 for (int k = 0; k < K; k++) {
 prevCost[k] = currCost[k];
 }

 // Setup args struct
 // args.start = 0;
 // args.end = K;
 // computeAssignments(&args);
 double t1 = CycleTimer::currentSeconds();
 for (int i = 1; i < numThreads; i++) {
 workers[i] = thread(computeAssignments, &args[i]);
 }
 computeAssignments(&args[0]);
 for (int i = 1; i < numThreads; i++) {
 workers[i].join();
 }

 args[0].start = 0;
 args[0].end = K;

 double t2 = CycleTimer::currentSeconds();
 computeCentroids(&args[0]);
 double t3 = CycleTimer::currentSeconds();
 computeCost(&args[0]);
 double t4 = CycleTimer::currentSeconds();

 tot1 += t2 - t1;
 tot2 += t3 - t2;
 tot3 += t4 - t3;

 iter++;
 }

 iter = std::max(iter, 1);
 tot1 /= iter, tot2 /= iter, tot3 /= iter;
 double sum = tot1 + tot2 + tot3;

 printf("cost per iteration:\n");
 printf("compute Assignments:\t[%.2lf] ms\n", tot1 * 1000);
 printf("\t\tout of all: [%.2lf] %%\n", tot1 / sum * 100);
 printf("compute Centroids:\t[%.2lf] ms\n", tot2 * 1000);
 printf("\t\tout of all: [%.2lf] %%\n", tot2 / sum * 100);
 printf("compute Cost:\t\t[%.2lf] ms\n", tot3 * 1000);
 printf("\t\tout of all: [%.2lf] %%\n", tot3 / sum * 100);

 // free(currCost);
 // free(prevCost);
 delete[] currCost;
 delete[] prevCost;
}

扩展阅读

IMHO it’s a must read for CS149 students!

The story of ispc: all the links

~~咕咕中，如果去看完了，可能会出个 note 或翻译版？~~

原始实验材料仓库：stanford-cs149/asst1 at 308e409ff3b75796702ca2cb0905bad0db752405

我的实现仓库：Livinfly/15-418u15-618uCS149u: Notes & assignments implements for 15-418 / 15-618 / CS149

Snow, Falling and Melting ~ 雪，降融 ~

Sat, 28 Jun 2025 07:33:30 +0000

Snow, Falling and Melting ~ 雪，降融 ~

笔者从25年除夕玩完之后，几次想要写感想总结，但始终未能如愿，总是害怕未能达意，却又没有细细雕琢的本领。

感谢自己前已有个人游玩实况文本吐槽记录下自己游玩时刻的一些很直接的情感心路历程。

浅浅重温前文后，而就带着暂存的些许感觉来拟一篇泛感想，如果能引起一些角度思考的话题点，那不甚荣幸。

行文结构不佳，配图大多堆在附录，敬请谅解，可能会有细节错误、看法角度的不同，欢迎交流。

内含剧透，谨慎观看，建议游玩后阅读，同时补充材料是不可或缺的。

前言

笔者自认是冬马党，因为冬马那种性格、偏冷的音色，就是我喜欢的、想守护的类型。可能也有笔者由动画入坑，动画揉IC本篇的内容和相关补充材料的会对和纱有些许偏心（个人觉得）有关，推完游戏后对角色有更深刻的了解，大概也是春希那种，主观喜好因素决定的和纱多一些。

在笔者主观喜好下的角色排名大概是：冬马 > 雪菜 > 千晶 > 小春 » 麻理。

小春排在千晶后面，大约是因为被千晶伤得重一些，可能五个角色里伤我最重的就是千晶。

同时觉得小春线的走向比较痛苦（杂糅了些剧情给人的感受），觉得有些小悲剧。

而麻理对笔者个人而言没有什么特别的感觉吧，情节的刻画上感觉也不多（？）。

以上算是笔者的个人看法角度背景。

雪，将一切埋藏起来

「雪，将一切埋藏起来。

然而，雪毕竟只是雪。

一旦雪融化了，那被埋藏起来的事实，那被忘却的回忆，又会重现在白日之下。

就如同乌黑肮脏，被踩得不堪入目的烂泥一般。」

「抢跑」的消解

关于有些把雪菜更对应现实，和纱更对应理想的说法本身是有偏向的，实际觉得这样粗暴的划分是不妥的，因为北原春希对二人的喜欢是四十九和五十一（原文我忘记了，但大概是这个意思）。

事实上，具体玩下来人物都有很多面，特别是在补充材料广播剧『祭りの前〜ふたりの24時間〜（庆典之前，两人的24小时）』（推荐高质量广播剧自制）中，让我对冬马和纱、小木曾雪菜都产生了更加复杂的看法，是虽然能理解，也认可就是很可能发生的事情，但是很难过的感受。

「也许你没有自觉，不，如果真是那样的话，那就更过分了。」

重垣叠锁的冬马和纱，小木曾雪菜痛苦的独自清楚，就算雪菜已经在她的范围内尽可能让大家一起面对。

补充材料**广播剧『祭りの後～雪菜の三十分～（庆典之后，雪菜的30分钟）』**中，雪菜痛苦的、纠结的、做出自己都觉得讨厌的决定前的三十分钟，也很能反映出雪菜的害怕。

「你为什么会这么焦急呢？」

把「抢跑」这个说法，在我这里消解掉了，只能说，那就只能这样随之发展了。

越理越乱的善意谎言

北原春希在被表白后，说着不会撒谎，却又把明明是雪菜的表白，说成自己的表白（虽然在熟练街的时候，急着说出来真相过）。

和纱与雪菜在天台的会面，更是完美的信息差，不一样的心境，却造就一番看着无比和谐的温馨场面。

再是和纱准备逃离回到钢琴的世界，雪菜的三人迁就与春希放不下的内心，又让三人的故事继续延绵了下去。

「我低估了春希和和纱彼此对感情的强度，他们对这份感情认真到悲伤。」

三人的痛苦正式开始。

从和纱那里得到了，放弃和纱的勇气了吧？

「为什么会变成这样呢……

喜欢的他，不惜对我撒谎，向我转过身来。

不惜舍弃自己的思念，向我补偿一切。

跨越三年的感情，终于实现了。

那样本应该已经满足了。

只要我的心愿实现，应该就能和好了。

但，为什么，会变成这样呢……」

补充材料小说『歌を忘れた偶像（忘记如何唱歌的偶像）』，为 IC、CC 之间的过渡内容，主要以雪菜的视角讲述中间的三年的故事。

雪菜是某种意义上的三人关系的交叉路口的抉择人，当然，充满了感性元素的抉择，她自然地陷入自责与自身的厌恶；

春希已经把自己（大部分）不忠的行为说给了雪菜，机场送机场面更是「贴脸开大」，自然陷入痛苦之中；

和纱亦是如此。

友尽君的角色，揭示出春希和雪菜关于三人之间「剪不断，理还乱」的关系的坚决态度，对三人以外的人不愿告诉、不愿使之参杂的态度。

二人默契地、刻意地避开和纱的话题，本要在又一年学园祭复合了，但在那首歌想起的瞬间，两人都知道，他们之间还有和纱这一障碍还没法跨过、说清。

关于春希转部的事情，二人的心理活动都呈现出来──雪菜是那么「拧巴」的人。

同时，武也「春希党」的立场也是在和依绪等人的冲突中更加明显的显现出来。

关于和纱的采访杂志，变成两人再次联系的契机，北原知道了但是不去和小木曾分享，而小木曾知道了第一时间就来分享，多少也反映出他们对三人关系的想法。

我隐隐觉得，这样的三个人组成的「三人」本质是个「结构性悲剧」，因为三人都是有障碍的人。

及时没有真实世界中度过三年，和和纱分开的三年，从春希要写杂志报告来写冬马的故事，从只能和雪菜、周边人的对话中，有的没的提起她，「那家伙」，再加上新的人进入北原的世界，和纱的身影确实地在淡去，当然，在涉及雪菜的时候，在涉及情感经历的时候，又会无比清晰。

众人设计的圣诞夜复合计划，最终在早已受到春希对和纱的深度报道的那篇，事实上就是给所有人看的，写给和纱的情书，折磨到胃疼的雪菜，终于在最后关头爆发出来。

「从和纱那里得到了，放弃和纱的勇气了吧？」

来自雪菜的，我无法对和纱说谎。

其实，并不想，两个人都不想，也不能忘记。

值得一提的是，春希与和纱，有雪菜的电话；春希与雪菜，有和纱的杂志。丸户，对称狂魔。（逃）

我自己 CC 一周目是滑雪线，好像就有一个地方以为千晶遇到麻烦了，不然就雪菜线了。没有从三女身上汲取到足够的勇气。

到了春天，一切都会恢复原样的

「那，那个……没关系的！

到了春天，一切都会恢复原样的」

和泉千晶线。

其实多多少少又被各大平台的相关视频的评论区，分享文章浅浅剧透，但好在没想太多，玩下来还是一波三折，甚至还有时候在想，她怎么知道这么多的，哈哈哈，狠狠代入。（bushi）

特别是，在推千晶线的时候，内心也是在蛮脆弱的时候。

我在前面提到「结构性悲剧」，也就是我对于「三人」的解决，在这个时候事实上是悲观的，因为三人不在同一个地点，而有些结是需要当面解的（CODA 给了这解的条件）。

所以，滑雪线后，我先推了千晶线，太想要一个抛开痛苦，可以停靠的港湾，同时也不代表是放下了「三人」，只是……只是逃走了。

而千晶作为仅次于当事人、武也的最清楚「三人」关系的人（当然，前期是有偏差的），这里 cue 下「外野的真啰嗦」的水泽依绪，评价复用千晶这个评价，又是就是会很不爽。

千晶NE就像是里面的春希一样，觉得她怎么消失了，像是从未出现。

而在千晶TE中，补充了在春希了解不到的角度的细节，太多套话话术了，坏女人！（x）

同时，也让我们更加明晰地看到雪菜的内心，希望多一份偏爱等等。

后面便是对千晶真实身份的揭晓，当头一棒，对她的一次次揭晓，即是一次次刀刮。

就感觉，真的不是正常人，一个为了表演，可以付出一切的「天才/疯子」，真「过分」啊……

「至今为止我所知道的这家伙的表情，到底占她整体的几成呢？」

这也正是我想问的，看着春希在苦笑，我也在苦笑，哈哈……

就是在这样的冲击下，后面的雪菜的探望让我感到弥足珍贵。

紧随质问的是大病一场，感谢没有设置千晶先来探望，不然如果北原能捏住他的拳头，我真的受不了。

雪菜，此时应该是我最想进入雪菜怀抱的场景之一了。

雪菜，做了粥送过来，其实是和当时「三人」，和纱发烧，雪菜教春希做的粥是一样的。

真的感慨万千，很想哭。

再后面，我其实对走和千晶的故事线不感兴趣了，只能说春希在这样的情况下，还是去选择千晶，既有千晶的真话，也有对三人关系的决心抛弃的因素。

所以千晶的认识还是有偏颇的，她认为，雪菜的忌妒、恐惧占主导。

千晶线作为我进入 CC 后的第一个其他线，多周目、多线路让我已经能够初步窥见，不同线对同一人物的深度刻画。

以下我觉得用原文（中译）来表达会好些。

（千晶臆想的梦中的和雪菜的对话）

「那个时候，我还是以自己的身份……」

「你自己……？

那是，指谁呢？」

「……」

「结果，作为演员取得了巨大的成长，

然而作为人类却止步不前了」

「但是，即使时间是无止尽的，

但无论绕了多远路却有走完的时候。」

「明明能够理解他人的悲伤和痛苦，但是『那又如何？』」

克里特悖论。

和泉千晶说和泉千晶是骗子。

那到底要怎样才能变成有关系啊？！

「……你在说什么啊。这不是和你完全没有关系吗」

「那到底要怎样才能变成有关系啊！？」

「……」

这还是第一次看到。 ……理论破绽百出的杉浦小春。

杉浦小春线。

经典名图的出现，雪菜的平淡放手，推的一把。

发展走向是，在小春逐渐对春希的好奇、了解的情况下，并且在帮助其和雪菜复合无望后，决心在一起的发展走向。

主要矛盾在于，小春的好朋友美穗子之前表白被春希拒绝，而小春甚至开始接触春希也是这个原因，最后被好朋友发现撒谎，在和春希夜谈。

小春和春希是互相救赎的关系，在前面春希失魂落魄的时候，她温暖了春希，以至于在被校园霸凌的时候，也不曾向春希求助，甚至有种独自走向地狱的感觉。

但仍然是在意好朋友的未来，以至于可以放弃自己的光明的未来，除了给出春希的秘密。

在前面小春温暖春希的过程中，春希一直也没有察觉到小春的一样，所以，在小春独自面对的时候，真的心在不断的下沉，非常伤心。

虽然后续春希出手，但这个结局，在我看来，还是太伤心了。

果然还是，很像、的吧…

虽然，这样想真的很轻浮…… 但是这个人，仍旧是一闹别扭就超可爱呢。果然还是，很像、的吧……

风冈麻理线。

因为我对于麻理没有什么特别的感觉，偏向于北原的麻痹自我的自暴自弃。

从剧情结构上来说，像是做了个北原春希追冬马和纱到欧洲的if线。

从角色表现上也是，春希除了最后赶过去那点是高光，别的地方其实很颓。

因为，这是只有我才能做到的事情

「因为，这是只有我才能做到的事情。」

小木曾雪菜线。

也是进入 CODA 前的必要篇章。

对于小春线，小春开始的孤立无援的缺憾，雪菜线的小春也算是落得我认为的HE了。

依绪看到春希这么努力，而雪菜却有退一步，少有的站春希的立场，到底是「外野的人」。（x）

二人开始了「分手之后再恋爱」，在「三人」之后，经历出「二人」的故事，最终迈向婚姻的殿堂。

而后的故事是。

「至于语言沟通上的问题，你大可不必担心。因为对方也精通日语」

「毕竟你的采访对象」

「这里是法国东北部的城市，斯特拉斯堡。

从巴黎坐特快列车到这里，大概需要两个半小时。」

「然后……

从维也纳到这里，坐直达的东方特快……」

那错位……直到现在

「因为如此悲伤。

我那，向前推进了的时间，

与和纱她，停滞不前的时间之间，

产生如此决定性的错位吧。

那错位……直到现在」

在 CC 线和雪菜重归于好，即将走向结婚的情况下，在我自己的选择下（如果有选项的话），在正常照顾完和纱后，就应该走掉，或者和雪菜说这件事。

可能是白月光吧，可能是某种缺憾吧，我们的男主角，北原春希，走不动路了。

又想要，又克制。

所以在我看来的北原春希的渣，主要还是在 CODA 的开头。

所以，在我看来，CODA 的「始作俑者」毫无疑问是北原春希，比如（事实上）使得和纱来日本开演唱会。

CODA 共通线中，开始对和纱的独家采访后，内容重心基本都在和纱上，而工作的其他、雪菜的描写，边缘化了很多，觉得其实会有些许不合理。

后面又是一段剧情演绎的情感高潮。

「是我，是我先……

明明都是我先来的」

「接吻也好，拥抱也好。

……还是喜欢上那家伙也好」

「因为如此悲伤。

我那，向前推进了的时间，

与和纱她，停滞不前的时间之间，

产生如此决定性的错位吧。

那错位……直到现在」

「你觉得……我是在开玩笑？

到现在为止我所说的，你都能当作玩笑而笑出来吗？春希」

「我怎么可能笑的出来呢……

所以求你了，换你来笑我啊」

「你要是不笑的话，

我，会不知道自己该怎么办才好啊……」

然而，在这般对话后，北原春希竟然去找小木曾雪菜的温柔乡，可能冲击真的大吧，自己骗自己。

第一个打出来的结局是雪菜NE，腰斩线，按照冬T的选项来看，其实只差一个，第二个选项，直接变成NE Flag，甚至不能选「我无法对和纱说谎」。

我对那个选项的理解的话，就是如果什么都不告诉，其实是逃避，和五年前一样，没有能够承担责任的勇气，不足以下定决心走向冬T。

而告诉一半的真话，其实说明北原春希和五年前相比已经成长了。

除了我爱她，胜过一切

「因为，让我选择和纱的理由，其实根本就不存在。

除了我爱她，胜过一切」

冬马TE，或者说北原春希主导的线。

音乐会，北原春希为了逃避对和纱的思念，跑去雪菜的地点。

雪菜妥协，只要最后的最后是她的话……

再经过一番辗转后，北原春希说出「我无法对和纱说谎」，终于拾起了责任，变成超人。

「要是对只能依靠我的你，弃之不顾的话，那么我，果然还是会一生都无法释怀的」

「如果你给出了答案，我就会全力开辟出那个你所期望的未来」

随后和纱也下定了她的决心。

「别再……和雪菜见面了」

「春希……

请你，背叛雪菜。

然后，选择我吧」

春希超人对着友人说明着他的决断。

每一句话，所有认识的人，发的每一句话，不管是什么内容，都会像利剑一般插入他北原春希的心脏。

特别是先前与雪菜复合、甚至 IC 和雪菜许下的承诺，都是最锋利的刀刺。

这样的一道道惩罚、罪条下来之后，终于让北原春希终于对与冬马和纱一起而要承受的痛苦有了实感。

把小木曾雪菜与他们隔得更远。

「我不会再抢和纱的春希了」

「三人就好，不把我抛弃就好」

「我果然无法放弃现在的生存方式」

此时的雪菜与春希和和纱的决心，所能放弃的东西，所能做出的决定是不一样的。

冬马和纱也愿意为春希，把她的所有，她钢琴家的双手也舍弃掉。

雪菜想要再最后一搏，车祸了，尝试抛下一切，但果然，还是不行呢。

最后，春冬二人在欧洲生活，传来了小木曾雪菜的消息，两人有些战战兢兢（当时我也以为是什么不好的消息，幸好没那么刀），他们是幸福的，但又不是幸福的。

雪菜，还在歌唱呢。

咏唱着时间的魔法

「愿望总是会实现的

只要闭上双眼

咏唱着时间的魔法

从零开始重新来过吧」

雪菜TE，或者说小木曾雪菜主导的线。

雪T真的，只要你对雪菜诚实，她就会好好对你的，夫复何求。

相比与冬T春希背负的，雪T中的，春希能够向雪菜求助真的是大大的舒了口气。

冬马先打的雪菜，然后雪菜又打了冬马。然后，后面每说一句话，每打一下，白1名场面复刻。

结果又是合宿，让人怀念「三人」第一次合宿的时候。

这就是「时间魔法」吧。

看着冬马能这样子坚强起来、成长起来，我其实也还是开心的。

最后是春雪的HS，毕竟是为了说明雪菜的情感释放，不然我其实不太喜欢在这个场景下有HS。

只凭感情、还是有办不到的东西的

「只凭感情、还是有办不到的东西的。

我没有为此，在一直以来的人生中去努力奋斗过。

没有切实的掌握那些」

浮气线，或者说冬马和纱（「东野和美」、「坂本纯生」、「北原和纱」）主导的线。

HS中的心理活动，都是北原春希的逃避、懦弱，甘愿陷入。

真的是坏掉了，同时也表明北原春希在这条线中没有能走出冬T的决心。

这里发展中，我怀疑曜子生病的消息，和纱是还不知道的，如果得知后，这样的春希，又会是怎么的发展呢？

按照前面曜子提到的，「大世界」和「小世界」的说法，这种情况下，两个世界的交集，是三个字──「不可能」。

冬马和纱的幸福，不只是有北原春希，是要有一个幸福的北原春希。

而在浮气线，北原春希常常出于不安的状态。

放手了。

和纱在肉眼可见的成长，相比之下，春希……

结语

试图从读者习得角度来说的话，笔者主观评价，『白色相簿2』这部作品是一部对人物刻画深刻，细节堆砌杰出，音乐经典应景，剧情胃疼精彩，情感冲突激烈，共情者、个人哲学家的素材盛宴。

对笔者自己而言，集中的情感激动的部分是千晶线和浮气线（大概是和推的时候的心理状态相关），冬T、雪T自也不必多说，荡气回肠，然后再是 CC 各个线中的「虐菜」，把雪菜的形象，以一种近乎残忍的方式，建立了起来。

有机会还是挺想去斯特拉斯堡圣地巡礼的。

附录

『学习笔记』MIT6.5940-TinyML-and-Efficient-Deep-Learning-Computing

Sat, 14 Jun 2025 10:17:32 +0000

封面来源：X(Twitter)@giname93076

Lec01 引入

Lec02 基础

Fully-Connected Layer (Linear Layer)

The output neuron is connected to all input neurons.
Convolution Layer

The output neuron is connected to input neurons in the receptive field.

1D conv, 2D conv, 还要在加上 channel 的维度
1. feature map 特征图的大小变化（公式）
2. Padding 填充，zero padding, others (reflection, replication, constant …)
3. receptive field 感受野（公式）
4. strided，在不增加深度的情况下增大感受野
5. grouped conv, 减少计算量，初始版本，所有的 channel_i 和 channel_o 都是相连的，参数量会减少到原来的 g 倍（组数倍）
6. depthsise conv, 分组卷积的极限情况，
7. pooling layer，得到小的特征图，对高分辨率的图，max, average
Normalization Layer
1. BN, CNN, HW B
2. LN, atention, HW c
3. IN, HW
4. GN, HW g
Activation Function
1. sigmoid, 易于量化quantize，梯度消失
2. ReLU, 输入为正不会梯度消失，为负死了，易于实现稀疏性sparsify，不易量化
3. ReLU6，最大为6的ReLU，相对易于量化
4. Leaky ReLU，为负，失去稀疏性
5. Swish，x / (1 + e&-x)，硬件实现困难
6. Hard Swish
  - 0, <= -3
  - x, >= 3
  - x * (x + 3) / 6

Lab0

熟悉pytorch用法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


lr_lambda = lambda step: np.interp(
 [step / steps_per_epoch],
 [0, num_epochs * 0.3, num_epochs],
 [0, 1, 0]
)[0]

steps = np.arange(steps_per_epoch * num_epochs)
plt.plot(steps, [lr_lambda(step) * 0.4 for step in steps])

scheduler = LambdaLR(optimizer, lr_lambda)

Lec03 - 04 剪枝

Pruning at different granularities
1. fine-grained / unstructured, 细粒度剪枝，灵活，剪枝比率高，不好并行化
2. coarse-grained / structured,
  
  1. pattern-based，提供几种模式，模式旋转等方式，规律性
  
  N2M，N:M sparsity，不如 2:4，M个为一组，至少有N个被置零。
  
  需要用两位来表示非零，为了稀疏，需要花费额外的内存来存储索引
  
  2. vector-level 行
  
  3. Kernel-level 一块
  
  4. channel-level，拿掉一整个通道，加速简单，剪枝率低。
  
  设计不同层的稀疏度，uniform shrink 均匀压缩；xxx
  
  如何得到最佳稀疏度分配？AMC
Pruning Criteria 剪枝标准

选最不重要的，heuristic 启发式
1. magnitude-based pruning，基于权重大小，绝对值最小的
2. scaling-based pruning，给每一个滤波器一个缩放参数，或者是channel，学n个参数就行，然后再去除靠近零的filter，因为Batch Normalization 中有缩放因子scaling factor，可以用来复用
3. second-order-based pruning，泰勒展开 - 海森矩阵 - 近似
4. neurons to prune，实际是去掉一行，一块核
5. percentage-of-zero-based pruning，用ReLU的时候，会出现零，然后看激活值的零的占比，去掉占比最高的，需要运行，得到activation tensor
6. regression-based pruning，
Finding pruning ratios

大部分都是假设层与层之间是独立的
1. analyze the sensitivity of each layer，对每一层进行不同程度的剪枝，看准确率下降情况，设定降低5%~10%，画线对应过去，得到横坐标就是剪枝率
2. automatic pruning，自动剪枝
  1. AMC: AutoML for Model Compression，RL
  2. NetAdapt, rule-based iterative/progressive method，设定减小的延迟latency，每一层看需要剪枝多少才能达成，后面进行short-term fine-tune，在能够得到一样的结果──减小设定的延迟的情况下，选择fine-tune后准确率最高的剪枝，不断迭代，最后整体进行 long-term fune-tune
Fine-tuning pruned neural networks

经验值，把学习率降低10~100倍
1. iterative pruning，迭代剪枝，边剪枝边微调，为了70%，经过 30% - 50% - 70%
System & Hardware Support for Sparsity
1. EiE，权重稀疏 + 激活值稀疏？
  
  对稀疏模型的硬件加速器设计
2. Tensor Core, M:N Weight Sparsity，相对规则，需要用2bit索引，乘法，用mask掩码
3. TorchSparsity & PointAcc，激活值稀疏，点云，稀疏卷积，不扩散，保持和输入的稀疏模式一致
  
  自适应分组，MM & BMM
  
  稀疏卷积硬件加速，归并排序找重叠部分

Lab1

实现 VGG 在 Cifar-10 模型的fine-grained pruning细颗粒剪枝与channel pruning通道剪枝。

同时应用了，sensitive敏感性排序，参数量排序等实际优化剪枝的方法

Lec05 量化

data type 数据类型，怎么样表示的
1. IEEE FP32 1符号 + 8指数 + 23尾数，single precision
2. IEEE FP16 1符号 + 5指数 + 10尾数，half precision
3. Google BF16 ，1符号 + 8指数 + 7尾数，Brain Float，有时 FP32 -> FP16 训练不稳定，可以换成 BF 16
4. Nvidia FP8 (E4M3)，1符号 + 4指数 + 3尾数，hopper
5. Nvidia FP8 (E5M2)，1符号 + 5指数 + 2尾数
  
  指数（数值范围、动态跨度大小），尾数（精度）
6. Nvidia INF4，1符号 + 3尾数，BlackWell
  
  FP4 (E1M2), (E2M1), (E3M0)
  
  E1M2 和 INT8一致，但是浪费应该 +- 0
Quantization 量化

把输入从连续集合转换成离散数值集合的过程，之间的差异，称为量化误差，目标是最小化差异
1. 存储、计算：浮点数，浮点数
2. K-Means-based Quantization，code book
  - 概念
    
    存储、计算：整数，浮点数
    
    节省空间；计算量不变
    
    存储的是代码本（k-means的质心）和分类的下标
    
    N-bit quantization 量化，#parameters = M » 2^N
    
    32 bit x M = 32 M bit; N bit x M = NM bit + 32bit x 2^N = NM + 2^(N+5) bit
    
    where 2^(N+5) bit can be ignored
  - 量化后微调 fine-tune
    
    得到梯度矩阵，把原本权重的分组，用在梯度矩阵上，求和，在权重的code book上去对应颜色的减掉（乘学习率）
    
    这个图有点神奇的，两个结合，但是得到了更好的结果：
    
    先剪枝后量化，降低量化工作量，降低量化误差
    
    低精度计算单元
    
    经验值，Conv，在4bits后，才下降明显；FC，在2bits后才下降明显；所以4bits保持不错
  - 其他的编码方式
    
    Huffman Coding 哈夫曼编码
    
    不同的权重出现的频率不同，变长编码策略
    
    出现多的，用短编码
    - three-stage pipeline Deep compression
      
      深度压缩三阶段流水线
      1. 剪枝，减少权重数量
      2. 量化，用k-means聚类算法，权重分组
      3. 编码，huffman coding，出现频率
  1. Linear Quantization
    - 概念
      
      存储、计算：整数，整数
      
      节省空间；减少计算量
      
      原始参数权重 =>
      
      （量化后的参数权重 - zero point (int) ）* scale(float)
      
      r(fp) = (q(int) - z(int)) * s(fp)
      
      q_min max 是确定的，
      
      s = (r_max - r_min) / (q_max - q_min)
      
      z = round(q_min - r_min / S)
    - 矩阵乘法运算
      
      为了防止溢出，计算是需要类型转换
      
      括号内后两项是常数（输入的零点，权重的量化值），包括括号外一项是常数，可以提前算
      
      零点不变，量化权重不变
      
      经验值，缩放因子在 (0, 1)，权重w的分布，遵循正态分布，Z_w = 0，为什么（？）
      
      当 Z = 0，S = r_min / (q_min - Z) = - |r|_max / 2^(N-1)

Lec06 量化提高结果

Post-Training Quantization (PTQ)

quantization granularity
Quantization-Aware Training (QAT)
更低的量化位数
1. binary quantization
2. ternary quantization
automatic mixed-precision quantization 混合精度量化

每一层不一定要一样的精度

Post-training Quantization

Quantization Granularity
1. Per-Tensor Quantization
  
  对整个张量用一个缩放因子
  
  大模型上效果好，小模型精度下降
  
  原因：不同的channel的权重范围不一样
2. Per-Channel Quantization
  
  更精细，误差更小，存储更多的值
3. Group Quantization，在4bit及以下，很重要
  - VS-Quant: Per-Vector Quantization
    
    全局浮点缩放因子，局部整数缩放因子
    
    Multi-level scaling scheme 多级缩放
  - Shared Micro-exponent(MX) data type
    
    L0 和 datatype 是共享的
Dynamic Range Clipping 动态范围裁剪

收集激活值的统计信息，在部署模型之前
1. During Training 在训练的同时
  
  Exponential Moving Averages (EMA)
  
  维护 r_min, r_max，r(t) = alpha * r(t) + (1-alpha) * r(t-1)，平滑维护动态范围
  
  （必须参与在训练）
2. calibration batch 训练后
  
  不过可以使用多训练一个batch，用calibration校准数据集，估算动态范围
可能不希望用真正的最大值
1. 最小化 MSE 均方误差
  
  假设是高斯分布或者拉普拉斯分布，最两端的地方数量其实少，有对应封闭解
  
  但实际符合这样分布的输入数据很少
2. 最小化损失的信息
  
  使用 KL divergence散度来校准量化范围
Rounding 舍入

权重之间是相关的，舍入到最近的值不一定是最好的
1. Round-to-Nearest
2. AdaRound
  
  引入可学习的 delta 然后再四舍五入

Quantization-Aware Training (QAT)

量化感知训练，fine-tuning 恢复精度

K-means-based 量化，fine-tuning，更新质心即可

线性量化？

Simulated quantization 模拟量化，fake quantization 伪量化

在训练的时候，维护一个全精度的参数权重，能累计非常小的梯度

再加上对激活值的量化的过程

增加这两个量化节点 Q(W), Q(Y)

训练好后，全精度参数权重就被抛弃

量化激活，阶跃的，梯度是0
Straight-Through Estimator (STE)

把weight-quantization node看成恒定函数 Y = X，传递梯度

Binary/Ternary Quantization

概念

Binary Weight Networks (BWN)

储存，计算：Binary/Ternary，Bit Operations
1. deterministic binarization 确定性二值化
2. stochastic binarization 随机性二值化
  
  需要随机数生成硬件
精度下降大，量化误差大，再次引入缩放因子，1/n * |W|_1

啊？量化误差变化不大，精度能提升，从-21.2% 能到 0.2%？

激活值的二值化？

XNOR 同或，用他来代替乘法

默认值，0 是 -1，1 是 +2，起因也是有 XNOR 硬件计算快

y = -n + popcount(W_i xnor x) « 1
Ternary Weight Networks (TWN)

和 delta 比较，得到 +1 -1 0，经验值，0.7 * E(W)

同样缩放系数

Trained Ternary Quantization (TTQ)

可以再引入，正缩放系数 Wp 与负缩放系数 Wn
降低精度的时候，内存是线性下降，计算量，模型表达能力，二次下降

Mixed-Precision Quantization

混合精度量化

设计的空间很大

Hardward-aware automated quantization with mixed precision (HAQ)

Lab2

K-means Quantization

QAT，简化，k-means直接用权重再更新

训练/微调的时候是伪量化，部署时才是真量化

Linear Quantization

Lec07 NAS 神经网络结构搜索

Neural Architecture Search (NAS)

不同于前面的训练、推理的优化，这是模型结构的优化

ResNet，1x1 卷积，bottleneck block
ResNeXt，1x1 分出来channel，分组卷积
MobileNet: depthwise-separable block

空间信息depthwise和通道信息pointwise，分开区分

depthwise conv 表达能力弱
MobileNetV2: inverted bottleneck block

和bottleneck相反，中间增大

激活值的特性不好

可以用来减小模型大小和计算量，但激活内存不能（训练常常是激活内存为瓶颈）
ShuffleNet

混洗shuffle，促进不同通道的信息的流动
Transformer

Multi-Head Self-Attention (MHSA)

感受野一层就可以全了

Search Space
1. Cell-level search space
  
  重复使用两种、
  
  reduction cell 归约单元，降低分辨率
  
  normal cell 普通单元
2. Network-level search space
  1. TinyML，内存更关键，在同样的内存限制下有更高FLOPs更好
搜索策略
1. Grid search 网格搜索
  
  需要训练，根据各个指标剔除
  
  compound scaling 复合缩放
2. Random search
  
  同样的搜索空间，但是随机变化，快速评估
3. Reinforcement learning
  
  决策序列
4. Gradient descent
  
  指标考虑，计算选择概率
5. Evoluitionary search 进化算法
  
  变异、交叉等
Performance Estimation Strategy
1. Train from scratch
  
  成本高
2. Inherit weight
  
  从预训练的基础上，继承权重，拆分点，保持数学等价，改变深度、宽度
  
  降低成本 net-to-net
3. Hypernetwork
  
  用网络来预测网络参数，层作为node embedding
  
  init embedding => final embedding 生成权重
  
  用来降低训练成本

Lec08 NAS 更高效

定制模型

前面的 NAS 太贵，选择proxy task代理任务，如更小的数据集，更少的训练轮数，FLOPs，参数量等

但是proxy task的相关性可能也没这么好。

ProxylessNAS

路径级二值化，指走概率最高的路径

训练按概率，推理选概率最高
- MACs 不等于真实硬件效率
  
  需要用真实硬件，效率低？并行！太贵？用延迟预测模型『架构，延迟』，最简单的模型是查询表，算子和延迟（一层一层的测延迟，相加）
  
  GPU会有 kernel fusion，两个kernel 可能会变成一个kernel 而变快
  
  计算密集型的两个，通畅不能kernel fusion，如两个矩阵乘法
  
  但矩阵乘法 + 非线性激活函数是可以的，计算密集型 + 内存密集型
  
  GPU会在更浅、更宽的表现好，CPU在更深、更细的表现好（对自己设备来说）
- 每个设备都要重新训练一个太贵，Once-For-All approach
  
  同时训练多个模型？
  
  用一个单一模型，包含许多子网络，稀疏激活
  
  相比之前的重新训练，现在只需要在小型网络中抽取不同的subnetwork子网络就行了
  
  设备不同，电量不同（适应不同能耗）等
  - 共享参数，不同子网络之间相互干扰？elastic 弹性的
    1. 卷积核大小，不采用单独不同的卷积核大小，而是选择用变换矩阵处理，只用一个 7x7 的参数就好，小的参数都在7x7的内部
    2. 深度，shrink the depth 归约深度
    3. 通道，通过不同channel的magnitude幅值，对重要性进行排序，选择前 i 个通道
  - Roofline Analysis 屋顶线分析
    
    折线图，X-获得一个字节的操作数，Y-GFLOPS 浮点算力
    
    computation is cheap; memory is expensive.
    
    内存瓶颈，计算瓶颈。
Zero-shot NAS

原本需要需要训练才知道评估acc准确率，变成只要看它的结构，推测是否能拿到高的准确率

ZenNAS, GradSign（感觉很直觉地开始套娃）
1. ZenNAS 启发式
  
  random weights 随机权重，粗略估计，结果不错
  1. 随机初始化输入，符合正态分布
  2. 加入小的扰动
  3. 再把所有的权重，映射到正态分布
  4. 论文指出，z = log(f(x’) - f(x))，如果模型效果好，应该对模型输入感到敏感，也就是说两个输出的差值应该大
  5. + batch normalization variance 批归一化（另一种启发式）
    
    对于不同的批次，方差大好
    
    计算每层的方差均值，加起来，希望这个方差越大越好
    
    这样，不同的输出，容易得到不同的结果
2. GradSign
  
  好的模型会非常密集的sample-wise样本级局部最小值，两个局部最小值应该非常接近
  
  在图中，绿色是梯度符号相同的部分，好的模型绿色部分应该更大，红色部分小
  
  在初始点附近，随机选择些点，计数梯度符号相同的数量。

Neural-hardware achitecture co-search，设计硬件

不仅搜索神经网络架构，也搜索加速器架构

硬件结构上会有些「非数值参数」需要设计，如连接性
1. temporal mapping 时间映射
  
  顺序处理
2. spatial parallelism 空间映射
  
  空间并行处理
两种 embedding，选择并行维度与顺序维度，分别按照重要性排序
应用
1. Once-for-ALL for Transformer and NLP
  - HAT
2. 3D建模
3. GAN
  
  小模型预览结果，大模型输出结果
4. Pose estimation
5. Quantum AI 量子
  
  搜索最佳电路门

Lec09 知识蒸馏 KD

Temperature 温度，高的温度，不同的区别越小，smooth，T在softmax的x => x / T

匹配/对齐什么？

对齐中间权重 matching intermediate weights

难点，维度不一样低秩近似/全连接/
中间特征 intermediate future / activation matching

激活值，中间的结果，也是相似的
梯度 Gradients

计算权重梯度或计算激活值梯度匹配

表现好的模型的注意力图是相似的
稀疏模式 sparsity patterns

来源于激活函数 ReLU 例如。
Relational information
- 不同的层之间 C_in x C_out
- 不同样本之间，同一个模型，不同样本输入的不同输出之间的关系

online distillation 在线蒸馏

self-distillation

教师模型和学生模型架构一致

教师模型正常训练，学生模型用教师模型的交叉熵概率来训。

用前一步的作为教师模型，后一个以前一个为结果，

最后把所有模型ensemble，得一个更好的结果

Deep Mutual Learning 互学习 DML

两个不一定相同的模型架构，互为师生，N1训练时，N2指导，反之亦然。

真实标签的交叉熵误差 + KL散度两者结果

不需要预先训练，教师模型不一定要比学生模型大。

Combined 前面两种方法结合 Be Your Own Teacher: deep supervision + distillation

用深层网络输出，作为浅层网络的教师，来自统一模型的不同部分。

蒸馏损失，在对真实标签的结果上，教师模型比学生模型的效果好时才能作为教师

物体识别，也可以看成（区域）分类

增强小模型的效果

容易过拟合，做数据增强 cut out, mixup, dropout

容易欠拟合，做网络增强，NetAug，基础模型扩展

Lec10 MCUnet TinyML

瓶颈

参数数量，峰值激活，与，内存

TinyNAS

Resolution 分辨率和 Width Multipler 宽度调节因子

Automated search space optimization 自动搜索空间优化

分析满足限制的模型的FLOPs分布，在各自的搜索空间中，高FLOPs=>高模型能力=>更可能高ACC

在同样的内存限制下，能有更高的运算量的设计空间更好

Flash 存储权重，SRAM 存储激活值

（最好的配比）

Flash↑，宽度调节因子（通道数）↑，分辨率↓，否则在 SRAM 中存不下分辨率 x 通道数

SRAM↑，宽度调节因子基本不变，分辨率↑
Resource-constrained model specialization 资源有限的模型特化

层的内存的峰值最小

Patch-based Inference 分块

不再是 per-layer 整层输入输出，改为 per-patch，分成几部分输入输出

坏处，增加了latency延迟，限制了并行能力（不过微控制器的并行能力是弱的）

卷积的重复计算，感受野，多了重叠的部分。感受野扩展
可以调整（减小早期的感受野，1x1，减少分块阶段的卷积层），总的需要不一样，在后面增加回卷积层，消除影响

早期用分块推理，后期降下来，是正常推理
再把这种分块推理的方式，放入搜索空间，推理调度
可以支持更大的输入分辨率

应用

Tiny Vision

classification, visual wake words，检测任务分辨率敏感（相比分类），所以分块推理，能使得分辨率提高

on-device training
Tiny Audio

二维语音，（时间，频率）功率，conv，相邻的频率、时间关联
Tiny time series/anomaly detection 微型时间序列异常检测

异常事件、产品（autoencoder，符合正常分布，重建误差小，不符合，误差大）

VLA，多个任务

Lec11 TinyEngine

Loop optimization 循环优化

Loop reordering 循环重排

让访问内存更符合 cache line，连续访问

矩阵乘法 i, j, k => i, k, j，虽然输出访问变得不连续，但是还是会被cover掉

Loop tiling 循环分块

内存访问就 N*N => N*Tiling_size => Tiling_size * Tiling_size

内存局部性，降低缓存未命中

一般循环内层往外吧（？）

for ti, N block

for ti, ti + block

两层缓存？

设置第二层分块大小，多层次的分块 Tile2，和L2 cache 大小设计

Loop unrolling 循环展开

分支预测，for 条件判定，循环展开，减少分支；但会增加重复代码，增加二进制文件大小

SIMD (single instruction, multiple data) programming 单指令多数据

ISA (Instruction set architecture) 指令集架构

CISC (Complex Instruction Set Computer) 复杂指令集计算机

Intel x86

并行处理范式

Vector Register，向量寄存器

Vector Operation，向量运算

提高吞吐量，速度

RISC (Reduced Instruction Set Computer) 精简指令计算机

Arm, RISC-V

Multithreading 多线程

1
2
3
4


pthread_t threads[N];
ThreadData thread_data[N];
pthread_create(&threads[i], nullptr, func, &thread_data[i]);
pthread_join(threads[i], nullptr);

OpenMP

编译器指令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


omp_set_num_threads(4);

#pragma omp parallel for
for(int i = 0; i < N; i ++) {
 for(int j = 0; j < N; j ++) {
 for(int k = 0; k < N; k ++) {
 C[i][j] += A[i][k] * B[k][j];
 }
 }
}

CUDA

MMA 矩阵累加

Inference Optimization

Image to Column (Im2col) convolution

In-place depth-wise convolution

NHWC for point-wise convolution, NCHW for depth-wise convolution

Winograd convolution

Lec12 Transfomer & LLM

Transformer 基础

…

Transfomer Design Variants 变体

Encoder-Decoder (T5)

Encoder-only (BERT, Bidirectional Encoder Representations from Transformers)

Masked Language Model (MLM)
Next Sentence Prediction (NSP)

Decoder-only (GPT, Generative Pre-trained Transformer)

Next word prediction

Absolute/Relative Positional Encoding

绝对位置编码

嵌入输入中

贯穿整个Transfomer过程
相对位置编码

只在注意力机制的部分

能处理更长的上下文，train short, test long
1. ALiBi (Attention with Linear Biases)
2. RoPE (Rotary Positional Embedding)
  
  LLaMa
  
  把长的嵌入转为二维的形式，(d1, d2)
  
  interpolating 插值，当 m 翻倍，为了保持还能正常表示，theta / 2

KV cache optimization

需要 KV，才能在 Q 的时候，算出对应的注意力

新token进来，没有 KV cache，则需要重算 KV？？？

Multi-Head Attention (MHA)

n heads for query, n heads for key/value

KV cache 大小会乘以 n_kv，太大

Multi-Query Attention (MQA)

n heads for query, 1 head for key/value

会大大削弱模型能力

Grouped-Query Attention (GQA)

折中

n heads for query, G heads for key/value (typically G = N/8)

在大模型下，准确率和 MHA 差不多

FFN => SwiGLU (Gated Linear Units)

LLM

LLaMa
1. LLaMa
  
  Decoder-only, Pre-norm,SwiGLU(swish,gatedlinearunits), rotary positional embedding (RoPE)
  
  7B model_d 4096, 32 heads
  
  65B model_d 8192, 64 heads
2. LLaMa 2
  
  上下文更长 2k => 4k
  
  GQA 分组询问注意力
3. LLaMa 3
  
  多语言 token
Mistral-7B

滑动窗口注意力机制，扩展上下文

数据和模型参数一起变大。

Lec13 LLM Deployment Techniques

Quantization

Weight-Activation Quantization: SmoothQuant

前面提到的哪些朴素的量化方法对LLM，其实效果不好

原因：outliers 异常值，某些激活值很大，破坏精度

激活值，个别异常高的channel，蓝色部分将被舍入零；

权重值，一般都比较小，ez。

取舍，smooth bond：

考虑到权重和激活值是线性矩阵运算，所以，比如激活值乘 0.1，权重乘 10，结果不变。

Calibration Stage

找到激活值 col_max，找到权重 row_max，相除得到缩放因子 s = \sqrt(col_max / row_max)
Smoothing Stage

应用缩放因子
Inference (deployed model) 部署

没有再缩放，编译的时候处理了（fuse 到前一层）

为什么单节点比分布式好，communication overhead

Weight-Only Quantization: AWQ and TinyChat

W4A16 for Single-batch single user server

单用户，就是 batchsize 是 1，计算瓶颈是 weight

weight在边缘设备的LLM推理中的影响

上下文与生成阶段，生成阶段是瓶颈
生成阶段受限于内存通讯
weight的占用内存的大小，比activation大多了

AWQ: Activation-aware Weight Quantization

传统 RTN（Round To Nearest）FP16 => INT3，clip()，降低很多。

？？？

只要保留一行，即1%channel，的关键权重，幻觉显著下降！

怎么找出这 1% 呢？

在量化权重的过程中，不关注权重的情况，而是关注激活值的情况！

因为下一层的激活值，是由权重与上一层的激活值相乘得出，所以，激活值大的，保留，

也是前面说的少量的异常值outlier

但是同个张量中出现fp16 和 int8，很难实现，会引入混合精度的计算，变得麻烦。

其实是不必要引入的，借用前面SmoothQuant中用到的方法，把权重的敏感性转给我们保持不变的激活值

相当于增加一位的精度

不需要反向传播，不需要基于回归的方法，只需要 calibration 校准数据集。

（Perplexity 困惑度是衡量语言模型质量的一个指标，和真是输出的比较，越小越好）

TinyChat: LLM Inference Engine on Edge

Hardware-aware packing

怎么解决 4bit 和 1字节对不齐的问题？

改变存储方式，为了更好地解码，交错存储

Kernel Fusion

Kernel call 很贵，做融合，BMM，批量矩阵乘法

QServe (W4A8KV4)

背景-融合两者的优点

SmoothAttention

类似与SmoothQuant，Q 是平滑的，K 会有某些通道有outlier异常值

反量化，由于溢出可能要调整计算方式

改变位数之后，负数的话，乘一个数，可能下溢出了，所以可以先乘再加减

先缩放还是先加减。

Pruning & Sparsity

Weight Sparsity: Wanda

传统：看权重本身magnitude

Wanda：关注最终激活值小的，对应的权重

Contextual Sparsity

DejaVu (input dependednt sparsity)

？

MoE (Mixture-of-Experts)

提高总参数，不提高推理代价

router路由器分配workload工作

路由机制

token选择expert

expert选择token

全局expert分配

Attention Sparsity

SpAtten (token pruning & head pruning)

Q-K，K列的attention sum，大 = 重要

H2O: token pruning in KV cache

LLM Serving Systems

Important Metrics 指标 for LLM Serving

Time To First Token (TTFT)，响应速度，实时互动
Time Per Output Token (TPOT)，每个token所需时间 100 ms/token, 10 token/s
Latency = (TTFT) + (TPOT * number of token to be generated)，总延迟
Throughput，对所有请求的每秒产生的 token 数

优化目标

最小 TTFT，最大 throughput，减小 TPOT，后两个需要 tradeoff，常矛盾

常用启发式：输出长度，输入长度，模型大小

Paged Attention (vLLM)

KV Cache 的资源浪费

Internal fragmentation：内部碎片化，由于不知道输出长度，过度分配空间
Reservation：预留碎片化，现在步骤没用，未来会用
External fragmentation：多个request，不知道sequence长度，要空出位置

解决 / PagedAttention的好处

由 OS 操作系统的 virtual memory and paging 虚拟内存和分页机制启发

交替使用 KV blocks

解决 KV-cache 内存碎片化，支持多访问 requests
动态块映射使得能够 共享 Prompt

FlashAttention

生成attention注意力矩阵时，NxN 很大

tiling + kernel fusion

Speculative Decoding 推测性解码

小模型 Draft model，生成

大模型 Target model，验证

小模型自回归生成，大模型并行验证（因为大模型运行比较贵）

纠正，重新生成

Batching

增加吞吐量

no batching，不做批处理
static batching，静态批处理，固定批次大小
dynamic batching，动态批处理，批次大小到了，或者时间到了
continuous batch (in-flight batch)，连续批处理，token级别

Lec 14 LLM Post-Training

LLM Fine-Tuning 微调

Supervised Fine-Tuning (SFT) 监督微调

对齐人类价值观/偏好，比如说话更加友好，更加善解人意

helpfulness & safety

Reinforcement Learning from Human Feedback (RLHF) 基于人类反馈的强化学习

BLEU、ROUGE的测试，客观答案，RLHF 更加主观，人类定义的创造性、可信的、有用的

朴素的

奖励模型训练──数据生成结果，人类对不同结果排序，比较函数，排序前的大大大于后的

两方面

调整后的模型，不会过拟合奖励模型，和原始模型的内容不能偏差过多
奖励模型下的结果不错，符合人类偏好

三个模型，两个损失值

Direct Preference Optimization (DPO) 直接偏好优化

简化流程，转化为单流程的 SFT 任务

Parameter Efficient Fine-Tuning (PEFT)

BitFit (Fine-tune only the bias terms) 只微调偏置项

微调权重需要存储激活值，但微调偏置项不需要存储激活值

TinyTL: Lite Residual Learning

在主干网络计算量较大的基础上，添加轻量级的侧分支，只更新侧分支，学习残差

下采样 group conv, 1x1 conv，上采样，激活规模小

Adapter 插入适配器层

Adapter Layer：残差，下采样激活上采样，bottleneck

对每个任务，只添加一些可训练的参数

会增加模型深度，增加计算开销，延迟增加

不改变模型？

Prompt Tuning

可以训练连续的prompt，学习prompt

Prefix-Tuning

Prompt-Tuning 只对第一层有提示 => 对每一层有提示

增加输入损失，KV cache 使用变大，延迟变大

不引入额外推理延迟？

LoRA

同样训练侧分支

从 d 维 => 低秩 r 维（高斯分布初始化），低秩 r 维 => d 维（零初始化）

最初添加，不会有影响

h = x @ W + x @ A @ B = x @ (W + A @ B) = x @ W'

没有非线性激活，所以可以fuse到原本的矩阵乘法

QLoRA

同样 LoRA 的设计原则，加上对骨架模型的量化

引入 NormalFloat (NF4)，centroid 不是学到的，是固定的
双重量化 Double quantization，缩放因子也被量化

CPU卸载功能的分页优化器，优化状态不用时，存放在CPU，节省内存

Bit-Delta

Your Fine-Tune May Only Be Worth One Bit

出发点是，模型已经学得很好了，微调只需要加一点点参数就好

能不能就微调 1 位，把增量量化至一位，还有一个缩放因子

二值化delta，sin(delta) > 0 => 1 else -1

Multi-model LLMs

Cross-Attention Based: Flamingo

将视觉信息注入inject到语言模型

LLM 参数固定，加入cross-attention layers

视觉信息 KV，文本信息 Q

Visual Tokens as Input: PaLM-E, VILA

全部都 tokenize，视觉信息tokens

解冻LLM参数；

交错使用图文，而不是图文对，否则LLM性能下降严重；

混合数据，还是需要纯文本数据

分辨率重要

高分辨率的处理，分块多少，看任务，OCR 分块多好；知识推理不一定

QKV，把低分辨率作为 Q，高分辨率作为 KV

Enabling Visual Outputs: VILA-U

统一图像和文字理解

Prompt Engineering

In-Context Learning (ICL)

zero-shot few-shot

Chain-of-Thought (CoT)

let’s think step by step

ReTrieval Augmented Generation (RAG)

Lec15 Long-Context LLM

Context Extension

PoPE

增加频率，扩展上下文，然后还需要去微调 Fine-tune

LongLoRA

性能瓶颈：注意力机制。二次增长

偏移稀疏注意力，不同模式，作为一个注意力头

怎么Fine-Tune embedding 和 normalization 层的？

两个模式都用，比单用一个模式好。

Evaluation of Long-Context LLMs 长上下文大模型的评估标准

The Lost-in-the-Middle Phenomenon 中间丢失现象

当相关信息在开头和结尾时，准确率高，中间准确率低。

**生成一段流畅的长上下文回复，不意味着模型真正记住了里面的内容，**所以只用困惑度是不够的。

Long-Context Benchmarks 长上下文的基准测试: NIAH, LongBench

NIAH (Needle In A Haystack) 大海捞针

aa在bb干了cc。做询问

随着上下文的变长，询问在文章xx%的位置的内容needle，检索Retrival准确率。

人为设计的合成基准测试

LongBench

多种任务，发现上下文压缩等技术不如位置编码。

现实世界的测试

Efficient Attention Mechanisms，KV cache 过大的问题

KV Cache

BS * layers * kv-heads * n_emd * length * 2 * type，每个token

StreamingLLM and Attention Sinks

保持恒定内存，Window Attention 的问题，第一个token被移出时，PPL上升

Dense Attention 的问题，在token长度超过预训练长度时，PPL上升 perplex

滑动窗口 + Re-computation 重计算

Attention Sink 注意力汇聚现象

对第一个token的注意力会高。

用了softmax，注意力得分和为1，就算有些不需要关注，而自回归模型中，首个token是全局可见的，所以把这些冗余的注意力得分给它。

是因为semantic 语义，还是position 位置？是位置。

保留来一个可训练的注意力汇聚点 / 四个注意力汇聚点。

（实验得出四个是 sweet point）

ViT 的注意力汇聚点出现在语义信息比较少的区域。

Bert 在句子末尾的分隔符标记

streamingLLM不等同于长上下文，查询早期的是查不到的，在kv cache中淘汰了。

(DuoAttention 是来解决这个问题)

DuoAttention: Retrieval Heads and Streaming Heads

Duo = Two，同样不能无限长，但是能够减缓。

retrieval head 和 streaming head

retrieval head，最初的 dense attention

streaming head，只关注 recent token & reduced tokens

每个注意力头都需要训alpha

因为是要用更少的内存，所以，我们对这个注意力结果做蒸馏distill，使得和最终的差值最小。

需要训练多少个alpha？

layers x heads

训练材料？

类似于NIAH，设置一系列 passkey。

推理的时候怎么办？

设置阈值threshold，大于dense，小于streaming。

decoding

两种 kv cache 一个是全部，一个是sink point + 最近几个token

计算是正常的多头。

prefilling

分块注意力

time complexity $O(L^2) \to O(LK)$

memory complexity $O(L) \to O(K)$

希望 streaming head 越多，节省的越多。

实验中，有一半可以作为streaming head。

实际上是对attention的剪枝、稀疏化。

Quest: Query-Aware Sparsity

Dense Attention
Query-Agnostic Sparsity 查询无关，要是在前一个token除移除了kv，后面的不会再有这个toekn
Query-Aware Sparsity，查询感知，前一个移除了，不影响后面还是可以有；基于正在解码的新词元。

因为确实会有某个token对前一个来说不重要，但对下一个很重要的情况，所以我们要全都存下来kv cache，因此没有节省内存，只是节省移动的内存开销，只抓取重要的 kv cache，其他的留在内存中。

同样的对 attention page 求和/求平均，只抓取重要的page，其余的留在内存

Beyond Transformers

State-Space Models (SSMs): Mamba

注意力机制两大任务，不同之间，单个内部。 还是不懂#

Mamba，加基础上引入 Selective State Spafe)

固定的kv cache，不线性增长。

Hybrid Models: Jamba

混合模型。

Lec16 ViT

Basics of Vision Transformer (ViT)

Patch（CNN, patch_size, 3, hidden_dim），Position Encoding，然后就和语言模型一样了

对比CNN，数据量小的时候，CNN好，大的时候，ViT好。

Efficient ViT & accerleration techniques

超分辨率，有实时应用场景；

高分辨率，对自动驾驶重要。

高分辨率，对比CNN，ViT 的计算量提升很快，是二次方的提升，分辨率也是二次方，所以就是四次方。

Segment Anything

Windows attention

注意力机制只在窗口window内发生，固定token大小，计算复杂度的是线性的。

但这样一来，注意力就在局部流通，全局没有了？

Swin Transformer 引入 shift window，shift operation，让下一层的窗口移动，使得能注意到相邻窗口的内容。

Sparse Windows attention

并不是所有的windows都是有用的。

FlatFormer，相比于等窗口组合，用等大小组合，可以更加硬件友好，更好地并行，不多等待。

Linear attention

替换。

然后发现效果差很多，注意力不突出了。

擅长捕捉全局上下文信息，但局部信息不行。

想到CNN是提取局部信息的好工具，在原先的基础上，加上CNN

结果提升。（分析新的注意力分布与原本的注意力分布特征的区别，得出的解决方案）

Sparse attention

SparseViT，用 L2 激活值来确定窗口的重要程度。

分出不同的重要程度，可以在不同层使用不同的稀疏度。

Self-supervised learning for ViT

怎么利用unlabeled data

Contrastive learning

拿同一张图片的不同 crop，去做同一的、拉近的 loss，不同的图片做拉远的 loss。

在小数据集上训的时候，SL，更大的模型可能得不到更好的结果，但是用了对比学习自监督self-SL（CL）会更好

多模态对比学习 CLIP

Masked image modeling

类似与bert的重建遮挡，Mask Language Models, MLM。

Heavy encoder只编码未遮的图片，lite会编码所有。

mask 70~75% sweet spot

作为对比，bert 比率是 15%，图片冗余大。

ViT & Autoregressive Image Generation

Autoregressive AR。

Hybrid Autoregressive Transformer (HART)

和新目标是减少迭代次数来加速。

有三种不同的生成方式。

文字生成和图像生成的不同，语言有词汇表，离散的，而图像是连续的。

要用一种AR架构把这两种模态统一起来，就需要一种离散的图像标记，就可以使用同样的loss了。

具体的，加入vector quantized, VQ encoder/decoder和 codebook，一个像素的vector量化是一个标量（量化）。

经验法则：一次性生成更多的标记token。

Visual Autoregressive，VAR，引入新的标记生成方法。

先为一张图像生成一个token，和分成2x2…，多个粒度。

他的 attention mask，也有变化（没特别理解

不过效果没那么好。

Hybrid Image Tokenization，HART

小的duffusion model，residual duffusion残差扩散，来学习离散token和连续token的区别（因为离散token自己学细粒度的很困难）

训练时候采样50% 50%，让两者在 decoder 中处于同一空间

Lec17 GAN, Video, Point Cloud

Efficient GAN

显然为了加速推理，压缩 generator

un/conditional GAN

提供条件（class, segmentation map, strokes/随机噪声

GAN 比识别的模型贵

GAN Compression

重建reconstruction loss，蒸馏（中间特征图）distillation loss，cGAN loss（真实图片和生成图片）

AnyCost GAN

StyleGAN2只采样最高分辨率，MSG-GAN采样所有分辨率，随机采样

不同通道数量，增加蒸馏损失，可以使得删去通道后的图片样式类似

同样的判别器对于不同的分辨率效果不一定都好

Differentiable Augmentation for Data-Efficient GANs

需要收集很多数据，贵

图片增强

只对真实图片增强，颜色改变，图片位置shift，部分cutout，会导致生成的图片也长这样，所以不好

（训练D的时候）在生成后都应用，判别器对转换后的图片的判别率高，对原图片 G，效果不好

在训练（G和D的时候）都判别前运用图片转换

Efficient Video Understanding

temporal modeling 时间建模

2D CNN

采样图片，再aggregate，average max

双流网络 spatial + temporal，optical flow

2D CNN + Post-fusion(e.g. LSTM) ，low level 是独立处理的

好处，计算高效，重复利用图片识别2D CNN

坏处，时间信息，光流计算量大，late fusion 无法建模 low level

3D CNN

C3D，参数量变大

I3D，用2D CNN来初始化3D CNN，inflation，就重复

好处，时空信息一起，各个级别的信息都可以建模

坏处，模型大小，计算量都变大

TSM (Temporal Shift module)

不用计算量、参数来为时间建模

offline，bi-direction 可以做双向

online，uni-direction 做单向

shift 的比例，不能太多也不能太少

Efficient Point Cloud Understanding

稀疏，非规整；应用场景算力限制

PVCNN / SPVCNN

Point-Voxel，Point local，Voxel global（稀疏掉0，让 point 去做高粒度）

3D NAS SPV

BEVFusion (Bird’s-Eye View)

Dense 摄像头，Sparse 雷达，产生BEV + 3D 对象检查

Lec18 Diffusion Model

Basics of diffusion model

Denoising diffusion models

训练算法

采样算法

Conditional diffusion models

Scalar condition

Class ID，encode，embedding，加到特征图上（或者embedding scale 和 bias更加复杂）

Text condition

Cross Attention

图像和文本并不对称，图片 Q，文本 K V

Joint Attention

文本和图像对称

Single Self Attention

Early fusion

Pixel-wise condition

Control Net

关于多样性和质量，增加 c 的分类器，强度

classifier-free guidance

Latent diffusion models

较少计算量

预训练 VAE，编码到潜空间 diffusion，最后再解码

学习目标是一样的，预测噪音

采样也是类似

分辨率压缩的越多，运行的越快

Deep Compression Autoencoder (DC-AE) f64

压缩 64 倍，考虑 Attention 平方，减少的计算有 4k 倍

具体地，通过显式 space-to-channel / channel-to-space，残差自编码，使得更加稳定

因为自编码器要的计算量变大，为了减少计算量，使用分层稀疏调优的方式，减少计算量

还有 Linear Attention，使用小 LLM 作为文本编码器，kernel fusion，flow based PPM 求解器

Image editing

Stroke-Base Editing

通过增加噪声，使得草图和图像接近，然后解出来（具体训练是怎么样的？）

SDEdit

Model personalization

人物一致性

DreamBooth，通过 finetune，用特别的标识符来代表这个类别

但是，只能对每一个新的类别都需要去finetune，costly

后续也有 training-free 的技术

Fast sampling techniques

能否增大步幅，减少步骤

Denoising diffusion implicit models

之前的马尔可夫Markovian 只依赖前一个步骤，增加和 x0 的关系

Distillation

渐进蒸馏，教师模型一步一步，学生模型从教师模型的两步里面蒸馏学习成一步，然后渐进蒸馏，就可以减少步数

Acceleration techniques

Sparsity

编辑只编辑了一些，但需要对所有像素进行运算

SDEdit，只重新计算改变的部分，别的部分复用

Sparse Incremental Generative Engine (SIGE)

Image Inpainting，类似，同时可以实现交互式

Quantization

SVDQuant

和 LLM 不同，Diffusion Model 是compute-bound，所以 weight-only quantization 没办法加速扩散模型

使用类似 SmoothQuant 的方式，把激活值的 outlier 转移到权重上，然后权重使用 side (low rank) branch 去全精度保持精度损失，经过 SVD，异常值减少W4A4

同时，如果使用 LoRA funetuning，就不需要重新量化，在原本的全精度上追加秩就行了

简单实现，会带来不小的其他开销，kernel fusion 把旁支的 kernel 合在原本的 kernel 中，由于他们共享输入/输出

Parallelism

DistriFusion，相邻时间戳的输入实际上很相似，可以通过通信旧的激活值，来 overlap 通信与计算

同时，在更高的分辨率下，加速比更高，因为通信开销更大。

Lec19 Distributed Training 1

Background and motivation

模型大，对于单 GPU 来说训练时间太长，需要多 GPU 协同训练

Parallelization methods for distributed trainging

Data parallelism

拆分数据，多个 GPU 上的模型权重是共享的

partition data, sharing model
Pipeline Parallelism

拆分模型，一份数据。

按 layer-dimension 划分
Tensor Parallelism

拆分模型，一份数据。

按激活值来划分
Sequence Parallelism

data parallelism 是 batch，sequence parallelism 是 token

Communication primitives

One-to-One: Send and Recv
One-to-Many and Many-to-One: Scatter and Gather
Many-to-One and One-to-Many: Reduce and Broadcast

Reduce 可以看作是 Gather + Reduce 归约操作

Broadcast 是把张量的全部都分发给所有节点，Scatter 是把不同部分分发给不同节点
Many-to-Many: All-Reduce and All-Gather

All-Reduce 对所有 workers 做 Reduce

All-Gather 对所有 workers 做 Gather

Data Parallelism

Parameter Server

中心化

Workers pull model from Server
Workers push & sum to Server gradient
Server update model using gradient
Workers replicate / pull the updated model to update local copy

去中心化的方法

Naive All-Reduce, Sequential
Better All-Reduce, Ring
Naive All-Reduce, Parallel Reduce
Recursive Halving All Reduce (Butterfly All Reduce)

Reducing memory in data parallelism: Zero-1/2/3 and FSDP

Pipeline parallelism

Tensor parallelism

从 d_dim 维度切，垂直切，再水平切

Scatter and All-Reduce

broadcast activation

Sequence parallelism

处理长下文

比如把一本书的不同章节分别做，但是注意力不能互相计算，只是局部的话，会缺失上下文。

DeepSpeed Ulysses (Solution 1: Re-partition data in Attention layers)

All-to-All 全对全通信开销大，节点之间通信成本高；

最大并行度？会受到模型的多头注意力的头的个数

Ring Attention(Solution 2: Ring Attention)

交换 KV1 KV2 KV3

并行度不再受 head_num 限制

Longvilla，结合这两种方法，在一个节点中，用 Ulysses，节点之间用 Ring Attention。

（节点内部通信高）

Lec20 Distributed Training 2

Hybrid (mixed) parallelism and how to auto-parallelize

2D Parallelism

Outer: DP

Inner: PP
Outer: PP

Inner: TP
Intra-node: all-to-all repartition

Inter-node: ring attention

3D Parallelism

PP + TP + DP

How to Auto Parallelize

模型太大，不能放单机；PP

模型层太大，不能方单机；TP

Alpa: A Unified Compiler for Distributed Training

搜索空间大，分层搜索空间 Hierarchical Space。

Inter-op Parallelism

Intra-op Parallelism

Cost，计算成本、通信成本、数据重分布成本

（那还有说法吗？这个设计）

Understand the bandwidth and latency bottleneck of distributed training

通信很重要。

估算延迟

Gradient compression: overcome the bandwidth bottleneck

Gradient Prunning

Sparse Communication 稀疏通信

结合局部梯度累积的梯度剪枝

只 send top-k 梯度 by magnitude
保持未 send（没有到 top-k 的）作为 error feedback (residual)

保留残差，直到累积到阈值（梯度裁切）

导致性能下降。

Momentum 动量机制

直接累积梯度，会导致优化方向的偏移

应该累积速度，而非梯度

Deep Gradient Compression

warm up training

在训练早期，权重改变大；warm up learning rate

累积梯度会加剧问题；warm up sparsity

指数逐渐增大，保持稳定。

梯度压缩比可以到很高，99.9%，没有1000x？索引开销、bias 偏置没有剪枝，偏置对残差训练很重要。

PowerSGD: Low-Rank Gradient Compression

问题：稀疏梯度，在 all-reduce 环节会变得越来密集

采用固定稀疏模式，粗粒度稀疏。

用低秩分解，来固定稀疏模式，粗粒度稀疏。

Gradient Quantization

1-Bit SGD

把梯度量化为 1 bit，零阈值，同时保留 delta 值作为残差，缓解误差（累积到阈值，直接加回）。

每一列都增加一个 fp32 的缩放因子

Threshold Quantization

设置 tau，大于 tau 为 tau，小于 -tau 为 -tau，之间为 0

需要经验选择 tau 值，同样有累积误差的机制

TernGrad

量化 g_i / max(g) 为 0, 1, -1 ，以概率来随机量化，期望一致，不需要累积误差。

Delayed gradient update: overcome the latency bottleneck

Bandwidth vs. Latency

带宽容易提升，剪枝量化、硬件提升；

延迟由物理限制，被光速限制

延迟高，同步延迟会变高。

Delayed Gradient Averaging

超过太多步是不行的。

最新的减去当前的来补偿延迟，avg_g 已经有了自己节点的梯度。

Lec21 On-Device Training and Transfer Learning

Federated learning 联邦学习

FedAvg algorithm，只传送权重/梯度

Membership Inference，指出可以用梯度判断某个记录是否在批次中使用
Property Inference，指出可以用梯度判断有特定属性的样本是否在批次中

Deep Leakage Attack

一张图片ok，一个批次多个图片，也是可以的，顺序可能不确定，但是内容可以

防御策略

增加 Gaussian / laplacian noise，过小没有用，过大破坏模型
梯度压缩，剪枝比例到 70% 基本不泄露，保持性能

只有很少的梯度泄露，复原不出来。

Memory bottleneck of on-device training

训练的内存占用大，因为批次大、需要存储中间激活值

（checkpoint 来计算换空间）

Last 只微调最后一层？准确率下降很多
BN + Last

代价很大，效果不好

Tiny tansfer learning (TinyTL)

反向传播更新权重需要激活值，bias偏置不需要激活值

只微调偏置，Bias + Last

引入轻量分支

比剪枝激活值更有效

Sparse back-propagation (SparseBP)

从生物学出发的方法。

只更新一部分层（深度深的高级特征）

只更新一层中的一部分参数

怎么选择？

起始分辨率高，后面通道数多

contribution analysis 贡献分析

自动求解器，类似敏感度分析

只更新前面的层，acc 甚至变差。

发现重复的起伏，peak是点卷积，curve是深度卷积

更新比例。

用进化算法搜索。

SparseBP 的输出会更长？待研究。

Quantized training with quantization aware scaling (QAS)

在 int8 下，梯度值过小

修正缩放因子

PockEngine: system support for sparse back-propagation

多种芯片，编译中，运行轻，训练优化。

Lec22 Quantum Machine Learning 1

解码量子纠错代码

Noisy Intermediate-Scale Quantum (NISQ)

Single qubit state and gates

Single qubit state

basic component => Quantum Bit (Qubit)

state => statevector

Bra-ket notation 狄拉克符号

Measurement

Bloch Sphere 布洛赫球

用布洛赫球去表示任意量子比特的状态

Single Qubit Gates

所有 Quantum gates 量子门都是 reversible 可逆的（保证能量是一致的）

最简单的量子门是恒等映射

可逆门可用矩阵、布洛赫球的旋转

Pauli Gates

X Gate (Not Gate)
Y Gate
Z Gate，0 => 0, 1 => -1, 全局相位 phase，常规无法测量，所以也认为一致

Hadamard Gate

创建叠加态

Other Gates

Phase Gate
S Gate
S dagger Gate

U Gate

可以表示所有，通用门

Multiple-qubit state and gates

Multiple-qubit state

Multiple-qubit gates

CNOT Gate
…

quantum circuit

数据编码/上传代价是现在的主要瓶颈。

the NISQ era and compilation problems

Single-qubit X error rate => 1.718e-3

CNOT error rate => 6.973e-2

不同量子比特的性能可能不同，误差率。

Sabre Qubit Mapping

看交换后能执行的门，启发式交换

QuantumNAS

the example workflow and compiler on neutral atom quantum computer

最大 k 割去优化编译

Lec23 Quantum Machine Learning 2

Lec23-Quantum-ML-II.pdf

TBD.

Parameterized Quantum Circuit (PQC)

硬件效率

PQC Training

Quantum Classifiers

Noise Aware On-Chip Training (QOC) of PQC

TorchQuantum Library for QML

Robust Quantum Architecture Search

梦的算竞止语

Wed, 23 Apr 2025 04:17:05 +0800

明明早知道要写了吧，却迟迟不知道写什么，就这么让日历上的数字往后数着。

晚上看到队友的退役文，心情就是要写了吧。

细节处多是省略了。

初识

第一次算是接触相关内容其实是在初三的寒假，某高中的冬令营中吧，里面唯二的收获，一个是生病，另一个是接触到了算竞，或者因为知识过于基础，称为编程吧。哈哈。

驻足回看，第二个收获大约的确也是「生病」吗？

让我自己选择路径，多了点任性，多了个，偶然让自己能产生别样喜悦的、大抵是不擅长的、就是愚蠢瞎走路去追寻的事物。

这对我来说，本该是普通的三分钟热度，只是它持续的好久，也不知道是什么寄于它上，让我就是会选择它，在几个十字路口偏向了它。

亏欠

升入高中，很弱的我，自然不去看那些四大学科竞赛，偏向了它。

不知道大家都觉得这个是不是离高考太远，或者是它是场「病」，只是他们的身上没有那个「生病」的诱因呢？

总之，到高二时候，同届算是在玩的也就共三个吧，当然，高一学也纯兴趣班样地学，后面才鬼使神差地就让我觉得「可能」可能是可以发生了。

算是运气好呢，还是命运定下的「病症」加重的药剂，让我在初赛运气不错，然后倒在复赛，共两三次，当然要么就是假努力了，要么就是方向错误的假努力了。

「病症」加重的现象是高二到高三。又去了杭州集训这种我之前显然不愿意去的东西，认识了后面几年里交流的最频繁的学长；在校，疑似在校每天都要往机房跑，不知道在寻求什么，哈哈，但也可能是我第一个作出的不太能被理解的任性的时候吧，真好。

高中就这样草草三个省二奖项收场。

满溢

由于没得到自己觉得应该能获得的奖项，总会去想着要所谓证明自己，暑假一边复健，一边决定了要打ACM的吧。

本来的目标，是加油两年打个银牌，嗯，就了结了吧。

很常规的OIer开学前就找人组队，但很不理解的匹配到比我强很多的队友，这可能就是组队资源受限吧；又恰逢有区域赛名额多出，梦一般，可能也就梦一般地决定好它是破碎的结局。

结果就是开学一个多月，省赛rk3，学校亚军杯，迷糊了。

随后的沈阳，打铁，大概是各个方面都没那么熟悉的原因，感觉三人红温三四个小时。

再后面的南京，打金，线上赛的封锁加留校的感觉，让这份不真实更加不真实，好像获得了什么，但更生了一场「慢性病」。

神奇。

这学期打完，恰逢线下赛回归，仿佛像是雨过天晴了，似乎在往好的、不得了的什么方向发展着。

上海EC铜，第一次线下赛，还没开比热身赛就发烧倒闭了，说起来第一次线下赛就有人能面基还是很好啊。

CCPC Final 铜首，第二次线下赛，要到和jiangly的合影。

深知这满溢，我并不满意，还是花了不少经历学东西，只是再后半程总是要在抑郁情绪中度过，由于一些愚蠢的事情吧，这样的自我思考，那样的自我剖析。

徘徊

秦皇岛，打银。D还是M，早过了一车，但想复杂，导致很晚才过掉。

西安，打铜。凹包场，n3/w场，不过如果多懂点科技，或者早点抢机时来打表还是能有ag的。

深圳，打银。哈希场，一个偏结论的猜晚了，一个是明明很可做的哈希没有开出来。第一次有机会和高中同学面基上了，弱校是这样的。

合肥，打金。测评机倒闭场。测评延迟对我们队来说影响没那么大，罚时不多，卡入金线。

上海EC，打铜。期末周前的比赛时间非常呃呃，题目难度在这个层级，也总是难出来。

线下赛总是还是继续新奇的，就是好像就在这样徘徊了，不像上年只有两场区域赛，且时隔近两个月，四场，上场比赛刚输完，又要准备下一场，再夹杂更多些破事，该说有些麻吗，不知道。

幻梦

CCPC Final，银首rk13。不知道命运是不是就是这么喜欢给人以奇怪的希望，然后又摔碎它。打之前的期望是有铜就是胜利，结果是这样的结果，各种意义上的五味杂陈。过程也没有什么特别的，就那么做过来了。

西安邀请赛，无杯金首rk4。和队友分析出一道题正解，但确认十几分钟写不完，搬出我觉得精度满足题意的暴力，让队友上机实现，通过绝杀了。赛后才知道，这题暴力过的只有我们队的样子。或者「可能」有个可能吗，这次。

梦去

有取得上两次梦幻的成绩，但有种越来越明显的无力感，不知道如何才能形容的好。可能早该退出，本该不在，却似乎没有能产生改变的人能来或要来。

哈尔滨，重庆，沈阳，三打银。可能从这个时候就感觉到香港站，所谓幻梦又散去了，该说悬着的心终究还是死了吗。香港站，银。西安EC，铜。

香港站，只留下最后我们有三道题在想，呼之欲出但终究是没有出来的画面。从结果看过掉一题是占金尾，不过这显然和开始的希望相去甚远，这场是金是银，区别没有那么大，只是哪个收场可能更体面点吧。

西安EC，考试周中间夹了个EC，也就没再啥准备了，所以更偏向香港是收尾了。写半天的大模拟，一直没检查到的某个corner case，最后具象成一串通过后的一个错误的测试点。单看这个题通过与否并不会影响什么了，但就是AC OR WA，WIN OR LOSE，是输了，就算是一个测试点也是输了。

止语

敏感自卑自闭的性格真是烂透，生完「病」才越让我看到而已。也并不是因为它才产生的，本来就是有「病」吧，只是恰好吧，只是偏向吧。

总之感谢它，感谢所有人，感谢所有的友好，祝你们RP++。

备忘录中写着写着的流水账，最后好像又是写成是自我剖析文了，哈哈，再逼迫自己再活一段时间吧，当然与它无关，止语。

ssh 远控 Windows

Tue, 25 Mar 2025 05:35:39 +0000

背景

在外上学，家里的台式机本来是要用到的话，使用小米智能插座+台式机通电启动+远程控制软件ToDesk~~来逃课~~，完全不涉及更深的技术，满足轻度外出调用电脑的需求。

最近又想折腾下ssh连接，一方面，ToDesk白嫖，有时候还是会卡几下，另一方面的话，可能就是随性想要搞一下了。

Windows 开启 ssh

安装 OpenSSH

先到下载OpenSSH ，选择自己对应的版本，我是64位，就选了圈出来的zip。

下载好后，解压在C:\OpenSSH，以管理员身份打开终端（PowerShell 和 CMD 应该都行）运行install-sshd.ps1，若已经手动把OpenSSH的路径添加到环境变量中的话，可以直接运行，否则请先移动到OpenSSH或用绝对路径运行install-sshd.ps1。

如果是msi 文件的话，应该也是类似的安装流程。

启动 ssh 并自动生成初始配置文件

在终端启动服务Start-Service sshd。

注意，在此之前不要在C:\ProgramData\ssh\下去创建修改sshd_config，否则，初始配置文件不会覆盖你创建的文件。

1
2
3
4


启动服务：Start-Service sshd
查看状态：Get-Service sshd
关闭服务：Stop-Service sshd
重启服务：Restart-Service sshd

防火墙开放 ssh 所用的端口

开放防火墙指定端口，比如默认的 22

具体参数，可按自己的需求配置

1
2


# 以`管理员身份`打开`终端`
netsh advfirewall firewall add rule name="sshport" dir=in protocol=tcp localport=22 action=allow

ssh 服务自启动设置

进入Windows的服务页面，找到OpenSSH SSH Server，可按需要设置启动类型。

配置 ssh_config

密码登录

在C:\ProgramData\ssh\sshd_config，我们可以看到自动生成的初始配置文件。

1
2


# 支持密码登录，把对应注释去掉，没有的话或者新添一行
PasswordAuthentication yes

免密登录

但是，我的电脑账户是没有密码的，所以这里也介绍一下免密登录的设置。

我们先约定电脑 B 是我们想要 ssh 到的服务端电脑，电脑 A 是想要 ssh 到电脑 B 的本地客户端电脑。

在电脑 A 先生成密钥（同样要先安装OpenSSH）

1

ssh-keygen -t rsa

生成密钥后，我们到C:\Users\[your_userName]\.ssh 下，找到公钥id_rsa.pub。

复制里面的内容，到电脑 B 的C:\Users\[your_userName]\.ssh创建authorized_keys（无后缀），并把前面复制的公钥内容，粘贴到里面。

再修改文件C:\ProgramData\ssh\sshd_config

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 下面这三行没有被注释
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
# 若想要没有公钥，输入密码也可以访问的效果，可以设为 yes
PasswordAuthentication no

# 注释掉，不过看评论区，遇到相关问题的解决方案
# 可以把刚刚authorized_keys的内容，放到C:\ProgramData\ssh的administrators_authorized_keys里
# （同样新建文件，无文件后缀）
# 此时应该下面量化就不用注释了
#Match Group administrators
# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

重启服务配置生效

每次修改完配置后，记得重启服务，使得配置生效，Restart-Service sshd。

其他

如过ssh时遇到Permission denied (publickey,keyboard-interactive)，可以尝试在authorized_keys文件的属性的安全中取消继承并只保留system与administrator。

测试登录

1
2
3
4


# your_userName是登录在电脑 B的用户名
ssh your_userName@your_IP_Address
# 如果不指定用户名，默认是电脑 A登录的用户的用户名，若没有增加其他配置，不能登录
ssh your_IP_Address

路由器端口转发

因为我的电脑 B 是连接路由器上网的，所以要访问到电脑 B 的话，只能发送给路由器。

以小米路由器为例，在路由器的高级设置中的端口转发，添加规则，内外端口映射根据自己需要修改，协议应该TCP就行（？），我偷懒直接都选了，内部 IP 地址，可以通过路由器的连接状况等方式查看。

设置完后，我们就向路由器的 IP 的对应端口发起 ssh 就行了。

总结

一股脑做完之后，想想还是有点用的，虽然因为没有静态 IP，需要先用ToDesk查看下现在的IP（当然，搞个自动化的启动后把路由器 IP 发送给我也不是不行，且确实有个类似的项目，~~但是咕咕~~），不过，后面的使用就是直接对应着的了，稳定性高一点。

包括，其实顺便做了个挺抽象的事情，ssh到电脑 B 后，调用 wsl，逃课双系统（x

参考文献

多台WIN10之间的SSH免密登录 - 余生

windows配置openssh server 支持Ipv4 Ipv6 - cddchina

喜闻乐见的软硬件问题大赏

Sun, 09 Mar 2025 07:35:00 +0000

喜闻乐见的软硬件问题大赏

Chrome 谷歌浏览器，在 Bilibili 视频页面，鼠标滚轮滚动延迟、果冻效应等

关闭谷歌浏览器「平滑滚动」。

打开 Chrome 谷歌浏览器，在地址栏中执行如下指令： Chrome://flags/#enable-smooth-scrolling
找到「平滑滚动」选项，smooth-scrolling 选项，选择「关闭」，Disabled。

鼠标滚轮停顿、延迟、回滚、乱跳等

知乎比较全面的回答

滚轮编码器脏了，使用WD-40，或者换个新的滚轮编码器。

拆开鼠标，往滚轮和编码器处喷些 WD-40 即可，注意量不用太多。

Windows 系统对文件路径的最长长度限制导致的问题

如安装 Python 的 vLLM 库时，遇到 error: could not create 'build\bdist.win-amd64\wheel\.\vllm\model_executor\layers\quantization\utils\configs\N=1536,K=1536,device_name=AMD_Instinct_MI300X,dtype=fp8_w8a8,block_shape=[128,128].json': No such file or directory错误。

这实际是由安装过程中需要创建的某个文件的完整路径超过长度限制导致的。

虽然安装 Python 时好像是会提示是否禁用文件名长度限制，但是在 conda 环境安装 Python 时是没有的。

这里只介绍一种方法，修改注册表。

打开注册表编辑器
- 按下 Win + R 键打开“运行”对话框。
- 输入 regedit 然后按回车键。
导航到指定路径
- 在注册表编辑器的地址栏中，复制并粘贴以下路径，然后按回车键：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem。
修改键值
- 在右侧的窗口中，找到一个名为 LongPathsEnabled 的值。
- 如果找不到，可以右键点击空白处，选择 “新建” -> “DWORD (32 位) 值”，并将其命名为 LongPathsEnabled。
- 双击 LongPathsEnabled，将它的“数值数据”从 0 修改为 1。
重启电脑
- 确保设置生效。

Windows 系统 C 盘拯救计划（文件软链接搬迁）

笔者苦 C 盘「红温」久矣，故找寻到此方法，因为软链接在一些操作中仍有所不同，不保证方法的安全性，若瞎搬瞎删文件，导致的任何损失，概不负责。

简单来讲就是建立文件软链接，尽量避免对软链接文件进行打包等操作，同时，建议只搬迁用户级的文件，而非系统级的文件，以防出现问题。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# windows
# 把 src 文件（夹）链接给 dest，会自动创建 dest 路径的文件（夹）
mklink /d [dest] [src]
# 示例
mklink /d C:\aaa E:\aaa
# 删除链接，不要用 del，否则疑似会删除原文件
rmdir [dest]

# linux
ln –s [src] [dest]
rm -rf [dest]

VSC (Visual Studio Code) 打开新文件覆盖 / 不覆盖设置

笔者之前一直很讨厌 VSC 在打开新文件时，覆盖掉我没用编辑的当前文件，觉得非常不方便。

而可能是 VSC 更新后，这个设置默认值可能倒过来了。

打开都是不覆盖，导致我什么文件都看一眼，就有十几个文件窗口要关掉了。

遂设置回来，意外之喜是发现可以通过点两下新文件设置成固定的。

千言万语化为下面这张图。

可以通过双击左侧「资源管理器」栏的文件 / 处于预览状态下的上方的文件窗口，固定住文件！

『白色相簿2』个人游玩实况录

Tue, 28 Jan 2025 17:46:59 +0800

集中游玩时间 Dec 3 0:37:16 2024 - Jan 28 17:46:59 2025

很多评价都是非常即兴的想法，有些和我最后、现在的想法可能会有所出入，同时快速推进时，可能也有少记录感想，总之是一篇我和『白色相簿2』这部作品的回忆。 建议在未完整游玩的情况下，不要阅读，建议推的路径的话，已经有不少大佬整理，那就不多赘述，只是一定要看补充材料的， ~~虽然我after story等一些就没看了，逃~~

自己主要内容通完后，应该萌娘百科啊什么的，再理一理感觉

ic的简析——ic真的有看上去那么简单吗（白色相簿2 序章 WHITE ALBUM2 -introductory chapter-）攻略

北原春希Kitahara Haruki 冬馬かずさTouma Kazusa 小木曽雪菜Ogiso Setsuna

IC

北原春希这种能够把各种事情同时都理得很顺的状态，大概是要内心也很顺而不是一团麻才会有的吧。

之前也有过一件件事情但是都在心中有个掌握感的感觉吧，不过有段时间没有了。

（也有人看作，这是春希「超我」，即「本我」被压抑的状态）

面对别人自己拿定决心要说的一些话，那就顺着听下去吧。

「结果，在那之后为了保护这个形象，就只能不断地打肿脸充胖子」

这第一次和雪菜的深入对话中，是就可以看出春希一些自卑的点的。

雪菜这第一次深入交流的下午场和深夜场，坦白局真的是「无与伦比的攻势」吧，一种怎么样好像都不太能辜负她的坦白的样子，「高岭之花」也不再是了。

雪菜是喜欢春希的，情侣上的或是想要成为朋友上的，且敏锐地察觉到和纱和春希互相喜欢，后面（？）。也是和第一次 white album 的先后注意力的转移对上了吗？

冬马两次想要和春希进一步说被打断，依绪、雪菜，当然本质是雪菜两次。

确实，冬马和北原都是不太坦率、不彻底的类型，我也是。

在雪菜家吃饭，也是把她的家庭观念抛了出来。

合宿，雪菜发现春希和和纱先合宿了，有种被隐瞒，也有喜欢的人要被夺走的感觉么（？），或者是自我暗示想要放弃。

从后面的电话看，还是偏向于相信雪菜说的怕被朋友们排斥。

到现在还很好的是中立的人，这大概也对应了北原的中立、一视同仁吧。

所以，其实可以得出，雪菜喜欢春希，也是希望一直有冬马这个朋友，三人的友情。发现被隐瞒，一方面有喜欢的春希要被「夺走」（从对春希说在她说绝交前，绝对还是她的朋友觉得略微失望可以看出），一方面好不容易有两个了解比较深的朋友也要失去的感觉。

没办法，春希有些行为还是能难做到啊，对我来说，就算知道是很对吧。

不过，也是做出过一些类似的有点「无理取闹」的事情，哈哈。

冬马也是有些小心机的哈哈哈，注意到手机没电不提醒，享受啊。（

哇，学园祭后面的事情因为事先知道了，所以看到春希到和纱家，然后一波完全没有察言观色的嗯嗯啊啊，真是把人气得够呛啊，如果不知道那个事实，可能会觉得冬马在单方面吃醋吧，就又谜语人又吃醋。

但也还是能看出冬马依旧小心翼翼的，全程吧。

nmd，春希这里的操作真的啊啊啊了。说着不会撒谎，却又是把雪菜的表白说成自己的表白，真是干净啊。

那句「我就是『那个』小木曾雪菜的男朋友，吗」，我不知道怎么去理解了，只能说我在这种情绪下，我觉得他有在享受。。虽然后面紧接表示他对冬马的喜欢，所以就要这么迟钝、这么去伤害别人吗。（当然都是马后炮了，我又能说什么呢，可能这就是谜语人之间的有点扰动后的大概率结局吗。）

诶，后面和纱与雪菜在天台的会面，完美的信息差，竟然造就这样的温馨局面吗？丸户史明老贼，真有你的啊。而且，两边都是正常理解，所以，北原，你真是罪大恶极啊。

（当然这边的吐槽大概都是源自我对冬马的喜欢，和对冬马被伤心的难过）

武也观察真的细啊，当然，他是知道春希对冬马的感情的；而依绪站在雪菜角度，可能是考虑到雪菜和冬马的友情么？

后面，冬马大概也是想要放下了，可能是逃离吗或者，回到钢琴的世界。真就是对春希的选择的尊重吧，很决绝。

然而在新的一年里，雪菜似乎也察觉到，北原好像开始不自觉地隐瞒自己的想法，可能他自己也没意识到的情况，不知道或者不想面对原因。这一时期的春希已经频繁且熟练的用雪菜相关的事情来提及冬马，掩饰自己的出发点，大概也是越来越发现离不开冬马了么。

又是信息差，春希出于自己的内心的混乱，想要就两个人好好聊聊，想要下定决心爱着雪菜；雪菜觉得春希要求越来越强烈，是对关系想要进一步发展，或者说，其他的渴望，同时还想维护住三人呢，还是其实有再次意识到春希对冬马的情感、行为后，让春希更离不开自己，不会抛下自己，变成一个人这样呢。不知道。

春希倒也是逼迫自己做决定，做切割，在前面表现得老好人后（跟和纱撒谎），想要不让雪菜受不是全心的自己么。

然而，雪菜对冬马的所谓三人迁就的态度，又给了春希一个去寻找的理由。潜意识里就认可了，去了。真是戏剧性啊，想要两人，却说三人，把犹豫两人的春希推了出去，一个发泄的可能。

而他，终于也是抑制不住内心的情感，去做了可能这辈子没做过的「最差劲」的选择。

春希真的没有察觉到冬马对他的感情吗？？？我觉得是他糊涂了吗。他真的认为对冬马只是自己的一厢情愿，雪菜给他了安定感吗。

第三次打断，是H的时候，这次和纱终于也是没有让打断成为打断，继续了下去；会很难受吧，怎么到这个时候才能说出来，不到这种时候又怎样说出来。

诶，wa2 的音乐真的拉满了啊。

「伪善，即使能够拯救大家，但是那肯定不是真的拯救。那不是真正的幸福。」

都是认为自己的行为有错，但是怎么会去怪对方呢，不可能的吧。

「雪，将一切埋藏起来。然而，雪毕竟只是雪。一旦雪融化了，那被埋藏起来的事实，那被忘却的回忆，又会重现在白日之下。就如同乌黑肮脏，被踩得不堪入目的烂泥一般。」

雪が解け、そして雪が降るまで

「蓦然雪化，且静候飞雪再临之时」

IC 前冬马和春希的故事。

ps. 这边由于typora挂了一次，导致这一篇与 IC 二周目的相关只能凭靠回忆来再写一遍了。

补充了冬马的视角，和纱家里的关系，和纱心里的变化，和纱与春希一点点靠近的过程与羁绊。

武也真兄弟吧，「第一循规蹈矩」和「第一轻浮」的链接，也算是给和纱、春希了个小助攻了。

和纱真的是深情吧，不论是对春希做得付出，对他虽然实际未曾表露的关心，但一点点都很珍惜。

什么为了去教他，练十个小时，导致三十个小时多没睡觉，这种前后小伏笔对照，丸户老贼真的也是会用啊。

等春希说的一会儿，等好多个小时，最后又因为只差十分钟而错过，对自己懊恼。

是那种有点傲娇，但其实也是好好察觉，在做好准备后，也会表达出自己的那种。

通过也反映出，春希的情况，几次想要更进一步的时候，春希又总是被自己烂好人的身份打断，自己没有给自己的事情的重要性排序，显得有点没主见么，或者说。

希望有多表达、做，且有察觉力呢。

对雪菜对这美好的打破，更恨了（bushi）

雪菜姫の受難と大臣の悪巧み

「雪菜公主的受难和大臣的奸计」

雪菜在第二次选举时候的过程，算是交代了下雪菜对春希的初始感情的来源之类的。

IC 二周目

七八段新增情节。

表白的事实，冬马对春希的喜欢更是要控制不住了，但其实还在顾虑着三人关系，没有明说。

而雪菜发现了这点，可能为了自己和春希，也有可能是因为怕三人因此自己被疏远，就赶快占得先机了。

三人温泉，就算那两人是确定了关系，还是会有点控制不住吧，车上想要偷吻的动作，后面又对自己背叛行为的痛苦。（我觉得由于春希对冬马的欺骗，说自己表白的，也对这份痛苦增上几度）

在从冬马家里的交流，看出冬马对北原的实际看法、感情，而在后面由于春希为了不背叛雪菜而做出的刻意地无视等，让和纱最后选择离开吧，留学吧，是不是好一点；总之最后做出和纱离开的助力。

雪菜和依绪的对话，其实反映出她其实有把自己做的事情说出来的勇气，也觉得自己做得不对，总之是哪里发展上出了问题，我这里觉得雪菜心里三人 > 两人的，应该还是出于对三人关系的维护，再感觉自己不说，可能自己就又是被孤立的那个了。

「我低估了春希和和纱彼此对感情的强度，他们对这份感情认真到悲伤。」

后续生日会想和春希单独的事情，是想至少这样还能维护住三人的羁绊吧，至少我是这样认为的，至少两人其实就还代表可能有的三人。

因此想到和纱可能由于认为是春希向雪菜表白这件事，多好几度痛苦，就是很啊啊。

彼の神様、あいつの救世主

「他的神明大人，那家伙的救世主」

在正式认识之前，两位女主之间的对互相的想法。

其实有些早早就作为对手的样子呢，一个想要一起，一个想要避开，也体现了两人的期望吧。

届かない恋、届いた

「无法传达的爱恋，传达到了」

「届不到的爱恋」的创作故事。

以三个人的视角各自说明了和这首歌相关的故事。

怎么会呢，和纱怎么会也没有看出春希写的是她呢，哈哈。可能觉得自己没有他会喜欢的地方么，算是某种自卑么。

雪菜果然是会比和纱敏锐吧，在这种事情上，确定就是写的冬马，可能这就是当局者迷吧。

甚至印象里 IC 春希为了说服雪菜还说，为了更贴合雪菜的改了相关用词什么的话（当然，不确定是不是临时想的措辞呢），我的傻和纱呀，你说，不是具体写给谁的，怎么又会改呢，这实习委员能写给谁呢。

也就是其实春希和和纱两者蒙蒙胧胧的发展过程吧。

我只能苦笑啊。哈哈。

祭りの前〜ふたりの24時間〜！！！

「庆典之前，两人的24小时」

广播剧。

感觉可以反复细品！

这是，这是，我对雪菜的态度转变最大的一个补充了，这下说得通了，这下说得通了……

「也许你没有自觉，不，如果真是那样的话，那就更过分了」

这句台词就是让我，最近的我，感同身受了，很难过，很痛苦，很过分，吧。

可以在这里看高质量自制

补充了冬马上飞机前的一些对话心理活动。

届不到的爱恋的排练，1v1过程，我现在开始怀疑和纱真的意识到是写她的了吗，果然还是会认为和纱应该还是认识到了，不然也不会这么辛苦的赶出曲子来，特别是结合「挑衅和游刃有余」，感觉是的吧。

emm，不过自己又去看了具体的歌词，前半不可能是雪菜，后半那个「身影」「出声相唤」与「第一次回眸之时」说实话我个人偏向雪菜（再结合后面做了修改这点来看）

她到底懂不懂啊啊啊，但是她真的说得好认真，笨蛋冬马啊。

这下在我视角里雪菜没那么罪恶了吧，没那么觉得所谓「抢跑」的事情了，雪菜已经说得不能再明了。

其实两个女主都是从「故作孤独」中过来的吧，对真挚的友谊、感情反而更加珍惜，一个在小心翼翼维护的同时，仍作自卑，害怕结果，更「退」一点；而另一个，小心翼翼维护的同时，想让大家彼此坦诚，没有秘密，就算是这样，也是好的吧，更「进」一点而已。

更加认为还是没那么知道的，至少在那个时候，然后，对自己对春希的感情不确定，对雪菜的友谊也不确定，两者还是相关，更加不确定，她害怕，她自卑，她担心……

说实话，我是可以代入雪菜和冬马1v1的情景的，怎么就是这么重垣叠锁呢？为什么呢？然后，怎么到了晚上又要去表达心意了，你怎么可以这样呢？（从这里开始我其实还没有特别找到个我的角度的雪菜的想法）又要变成一个人了吗，又要被隐瞒了吗？

就心疼的雪菜的点是，她是最清楚一切的，她当然也不是想要独自清楚，她想让和纱也承认、认清一切大家一起面对，但就是最后，诶。

我还是写不明白。

看到油管评论

「表面：春希寫的詞，冬馬譜的曲，雪菜唱的歌

實際：春希寄託對冬馬感情的詞，冬馬錯把春希的感情當作是對雪菜而譜的曲，雪菜把一切都看得明明白白而唱的歌」

祭りの後～雪菜の三十分～！！！

「庆典之后，雪菜的30分钟」

广播剧。

这上下两个广播剧，真的对玩完 IC 后重新思考雪菜，甚至重新思考每个角色的出发点，行为逻辑，三人关系等问题有重要的地位！

「你为什么会这么焦急呢？」

雪菜一边痛苦的三十分钟，自我纠结，最后做出自己觉得讨厌的决定。

这两个广播剧的补充内容，带来的情感波动，和熟练街前的对话的冲击是一样一样的，甚至更多。

祭りの日〜舞台の下の物語〜

「庆典之日，舞台下的故事」

广播剧，完成 CC 千晶 NE 后玩 IC 三周目先接。

千晶的演剧部。

冬马曜子的描写。

那个后期执行委员早坂与冬马的对话，这个执行委员也是更成熟了呢。

后面和纱的发现有人在关注着自己的错愕，嗯，唉，「和我这种人」，不要说这种话啊，和纱。

武也伟大，无须多言。

依绪和武也能不能修成正果啊，真的是。

冬马离开后，来到舞台，为三人的美好而寻求实感吧。

真的少见呢，能和刚见面的陌生人聊起来。

唉，真的是奇怪的关注点呢，或者说，其实和纱一直在想着怎么样跟上曜子的脚步的吧。

唉，在这里再次弹起，唱起，届恋。

你怎么会才明白呢，我的笨蛋冬马啊。

好啊，结果第二天开幕雷击啊。

IC 三周目

千晶，出现了，老戏骨了吗。

犹豫着不知道该被哪边所吸引的神情。

草，怪不得武也说在哪里见过呢。

明明也是附属的同校的啊。

别笑啊……

到底是出于什么。

*Twinkle Snow ～夢想～（IC IF线）

雪菜没有提前表白的故事。

呃呃，都是对话，没有提示人称，看起来有点痛苦，待看清单吧先。

歌を忘れた偶像

「忘记如何唱歌的偶像」

IC 与 CC 篇的过渡小说。

IC 的补充材料导致逐渐意识到为结构性悲剧，可能想要理清出感觉的话，就推不下去了吧，所以，继续推着吧。

有武也、依绪两个伙伴能一直说话，还是很幸运了吧。

雪菜还是在获得「三人」和失去「三人」的起伏中，对那件事情自责，她成熟地知道当时自己做了什么决定，在事后再回归传统、冷静的视角思考自己的行为。

真的「届不到的爱恋」了，对「三人」与「三人」外的人群，都不能传达到的真挚的情感。

对啊，雪菜开始对家人「说谎」了，她深陷那天后的痛苦中，众人之中，孤身一人，再加上对更深的对自身的厌恶。

对她人的察觉还是依旧敏锐。

高中学园祭的细节尽数溜出，一年之间。

两人默契地不谈及「三人」的话题，久违的快乐，不过总还是会感慨这半年来的落寞，总还是会没藏住那些情感。那份感情还是占据了主导，主导了结尾的走向。

雪菜还是放不下和纱，她的装饰下的刀痕又灼热起来，她还是没法跨出那一步。

春希竟然会拒绝人了，而且还是猛烈的拒绝了，不禁想到到底是受那件事的影响么。

确实的啊，和纱可以抛弃一切，或者说，她一开始就没有什么所谓「一切」，早就抛弃掉了吧。

真是「可怜」啊，友近君，不过真的有种春希零号机的感觉了，哈哈。

雪菜被自己的感性与理性撕扯着，掩饰着。

如果事实真的如友近君说的一样简单的话就好了，但是他不知道「三人」的故事，他是没有机会的，而雪菜也只会感觉，友近也了解不了自己的全部，也可能不会有把这一层的事情给他讲述的事情了。

果然是春希撮合的吗？不然怎么会得知「背叛」什么之类的事情呢？

是吗？或是只是谈及了吧，友近自己做出的判断，缓和两人痛苦的判断？

可以否决掉了，是友近自己做的判断，以春希想要分手的前提下。

雪菜终于把这犹如隔开的决绝带来的情感，倾泻了出去。

春希被内心的内疚，雪菜被这个事实的痛苦。

痛苦的恶性循环。

雪，把一切都掩盖住了。

两个人的隔阂，太重了。

他还是老样子，总是被搬来救活动的场，一如既往的可靠。

雪菜现在只能不停地用言语去欺骗自己，她讨厌春希，亦如和纱似的。

北原春希这种程度的人，真的是啊，作为有这样的朋友真的会很安心。

友近的对话又把她拉回现实，只会埋怨他人的是她，给他人带来麻烦的是她，是她；而北原春希，一点都没有变。

嗯，北原春希的变化，在帮助完友近后，和他绝交的事情，他也会用他习惯的方式，做完，表达自己的感情了。

哈哈，这回是雪菜在躲避，在对自己的情感不坦诚。

她在「自私」的道路上走的远了点（不是贬义），她对春希为了她而做出的错误的事情，从中挖掘出的，春希对她尚存的感情，而快乐。

她可能在这之前，一直觉得春希心中可能还是和纱重一点吧，终于有让他为自己「踏入歧途」的情节了。

在这里可能也可以帮助理解和纱之前「背叛」的感受吧，这种为她而做的自私。

这让小木曾又找回了前面的状态吧，她又会想去跑起来，唱着去表达了。前面学园祭，突然的暂停，应该是冬马的缘故，还是体验到北原是真的有那种程度嘛。

CC

和泉千晶，矢田美穗子（春希真的拒绝的干脆得以至于有点残忍的说），风冈麻理，杉浦小春

北原还是在意着那时候三人的歌的，关掉了。

生活节奏还是之前半个学期前的状态啊，哈哈。

千晶，可爱天真大学生；

麻理，成熟工作狂女上司；

小春，小春希，哈哈，认真，不变通，不给他人退路的多管闲事。

说中了，北原在用工作麻痹自己，当然，像他这样的家境要什么这么多兼职呢。

不过，好像也是在增加北原的家庭描述和他的理由描写了。

雪，已经变成「三人」共同的意象了。

从北原的角度看小木曾的关于转部的说法，明明说的理解、关心对方的话，心里却越来越痛苦。

北原想用超负荷的「现在」的事物充斥他是身心，不要想着过往。

和小春的对话，也发现了，春希有了不想让他人知道的事情，那些无关的他人。

也是表露了，北原春希对自己那段时间的一系列操作的。。

武也真的也是在看到北原其实还在一直把这件事情放在心里的，还在小木曾这里为他说话。

开樱Graph，你说得对，但是杂志是我北原春希编辑的，没想到吧（bushi）

选项，顺着北原一直都不理的情况看，其实我觉得还是会是回短信吧。

不过，两个选项都没有说自己实际在开樱打工，就，就事论事罢了。

不过，从见面都不打招呼，到电话这么热情的对话，确实一种恍惚感油然而生。

果然还是要在「三人」的话题下才好吗。

这里也可以看出，北原和小木曾对三人的态度吧，北原知道了但是不去和小木曾分享，而小木曾知道了第一时间就来分享。

肯定不是不想分享，就是可以看出两者在同一事情的不同态度吧。当然，春希自己对和纱的感情也是了，反正是可以看出，雪菜对三人的感情的。另一个，当然也是雪菜对能和春希说上话的最好的方法了。

我会觉得，先拒绝吧。从前面他对那段记忆的感觉。

草呀，千晶说的话，果然是有问题的吧！哈哈哈。

小春有点可爱了，那种诚实，那种认真。

草草草，在小春视角越来越扭了。

和泉尽管看起来大大咧咧的，高中也是那样专注过一些事情上过的，表现出的细心程度也是超越北原不知道多少倍了。一下就察觉了北原的现状。

emm，我觉得千晶接电话这点，我目前还是更愿意用好的角度揣测，单纯睡迷糊了。

又让雪菜产生芥蒂了啊，同样的时间，因为在这个点，春希才会休息啊。

这种级别的误会，为什么不去澄清啊。我不理解。

千晶有点类似武也、依绪、雪菜结合的感觉吧，大概。

对吧，春希比之前多了份犹豫。

北原春希，在那件事情没有打电话回去的事情上，真的太差劲了吧。

「就是那种，对于别人的事情就想方设法地去干涉，自己的事情却不愿意被人触及的态度」

怎么说呢，春希、小春这种多管闲事到这种程度的，确实很难遇到吧，至少我是没有的，不知道呢，就和别的女主不一样的感觉，一种很奇妙的感觉，就是这个人可以完全信任的、认真的感觉。

所以，依绪和武也什么时候cp上（

挚友程度的，真的是挚友程度啊，主角团。

他还是在为在附属的时候的抉择而后悔，选择的最坏的选择，我并不能够对他进行多大程度的指摘，只是觉得，如果不是这样是不是会好一点，但是「三人」可能本质上就是个「结构性悲剧」吧，而若没有「三人」可能也就是两人的无疾而终的模模糊糊的感情，仍然。。

虽然说，小春是小春希，但是感觉小春还是会在一些事情上比春希处理得柔和点吧，当然，可能已经不属于公事公办的范畴了吧。

确实啊，春希只对冬马会有那种顶嘴。

不是，为什么为什么，诶，和冬马那段狂轰滥炸一样的感受吧，但明明就要说出口了，或者说，为什么不给我选项啊？

我其实有意识到的，冬马这个身影其实越来越远，离我的生活，或者说，越来越深了。

现在能在意的，只有雪菜了。除了部长和她没有链接上关系，其他两位都链接上了。

埋住的DVD，届不到的爱恋，终于要压到 CC 才能出来吗。

怎么说呢，如果是我的话，可能还是不会太想把这样的记忆写出来吗？emm。

不知道，我不知道这对三人是什么影响，所以。

不过，确实就是美好的回忆吧。

怎么说呢，麻理的询问，我还是会觉得北原春希应该还是会搪塞过去吧，这种事情除非是别人已经偶然发现了，不然。

小春和春希一样呢，会说明做的事情，但不会说明原因，只上早班的原因，哈哈。

千晶其实确实是心思细腻的吧。

「周三 27 点，周四凌晨 3 点」。

唉，雪菜的伪装，很开心呢。

唉，小春这里也有了迷你版的三角么。

感觉，千晶多少和冬马有些关系的？

千晶反常态地叫北原出来，真就是简单聊聊吗，我怎么感觉是发生了什么事情。。

春希还是会对那段事情隐藏呢。

「过去变成回忆」吗。

哼，终于有我去分享冬马的事情的选项了呢！

我草你啊，丸户史明，怎么她tm有事啊。

唉，大学的事情，但是还是在围绕那半个学期的事情在发展，怎么可能会放得下呢。

怎么突然闪回千晶，武也和依绪到底是错付了，结果是小春吗，意想不到啊。

呜，心疼钱（

果然不能选择去叫千晶的吧，不然太诡异了。

已经买了，那是说明已经知道了么。

草呀，和生日会吗，对照。果然那件事让雪菜很痛苦啊。她讨厌雪啊。

生病也在强撑啊。

有必要么，怎么和雪菜一起就要和冬马和纱狠狠切割了？

em，好吧，感觉其实只是为了提起三人的话题吧。

还是在掩盖和纱的。。

还在逃避吗？你想出来的解决方案是这样子的？北原春希？

这样当然就变成两个人的故事了。

我不觉得雪菜没有看出来。

或者，他发现了这个「结构性悲剧」，想要换种方式跳出来。

哇，喜欢牛是吧，互相牛是吧，上一次是电话，这一次是杂志，无敌了呀？

你tm还在哭，能不能找个别的解法啊，我的春希大神，唉。。

tmd，为什么这次牛的更多啊，呜呜，我的和纱。

唉，都在哭。

打得好啊，雪菜！

北原春希，你tm忘了什么，什么消失了？

『冰之刃』响起。

说着坏话，像是说自己的事一样。

对吧，这分明是份情书吧。

你可能没想这么做，但是潜意识就是这样子了。

就是谎言啊，你在说谎啊。

「从和纱那里得到了，放弃和纱的勇气了吧？」

一模一样，诸葛雪菜。

还在说谎，心疼雪菜。

那样的记忆怎么可能忘记呢。

雪菜……好绝望……她终究无法接受，无法接受不是三人。

或者说，她无法接受春希内心还有和纱的存在，但是为了雪菜又要欺骗自己，强行忘记和纱的存在。

来自雪菜的，我无法对和纱说谎。

对不起，对这个既定悲剧的故事，我给不出解法，但你，北原春希，这么优秀的人，怎么也想不出解法？你给我想出来啊。

明明不是对别人的想法心思很清楚吗？怎么到自己相关就宕机了？你给我支楞起来啊？

唉。。

如果对方不是雪菜的话。

对啊，对方是雪菜的话，怎么可能会忘怀和纱呢。

对这一结构，也只能顺着时间，看他究竟会有什么转机了吧。

滑雪线

cc 一周目以滑雪线（BE）收场。

不过这也是我作为我理解的春希所会做出的选择吧，其实就是说，在我视角里的他，三人的份量在心中是很重的。

千晶线 NE

对吧，北原春希会是在某些事情上犹豫，结果什么也不做就结束的人。

不一样，北原春希没有和三人的故事彻底分开，所以我还是会认为，他会念记这三人的事情，若是三人各分，那可能是会这么个样子吧。

怎么说呢，稀里糊涂地就依靠上了，两人就这样的度过上了。

我心里还存在千晶的出发点等问题。

果然更想知道千晶藏着的秘密吧，好好奇。

恐怕三女都是要三人的记忆打过之后，才能结束上吧，毕竟意难平吧。

所以，春希是觉得，三年了，雪菜终于是会去和春希与冬马的事情而原谅那么简单么。

只是觉得没原谅那个背叛自己，背叛三人的自己吗。

不过，千晶并不说什么，只是告诉北原春希，她可以做他的港湾，可以全部接受。

从三人中逃脱出来，不失为一种解法吧，一种时间在隔开点的，我的解法。

不过后面说来，还是没有完全走出吧，但总是缓解的。

不是真正的和纱，是理想中的和纱。

所以，她到底怎么知道这么多的呢？

终归是能说出来了吧。

emm，NE 的缘故么，到此为止了么。

总感觉，千晶是又察觉了春希的什么感情吧。

不懂，反正是只看到这里的话，有点消失的莫名其妙的感觉。。

千晶线 TE

和小春对话的细节，emm，千晶她在演之前三人中的雪菜吗？嘶，这，把既是事实，又不是事实的事情说出来，很奇妙。

不过确实可以看出千晶其实对春希异常了解。

也是说明了帮助春希走出来的方式，就是让他勇敢面对三年前的事情，勇于说出来。

她竟然也出现在医学部的聚会的那家店周围，应该是保护雪菜或进一步观察吧。

「长濑晶子」

套话话术绝了，什么我也是刚分手，学到了（bushi）

两边都旁敲侧击啊，被她看透的感觉。

也是雪菜对春希的期望的说明，希望多一份偏爱。

也说明了雪菜对后悔抢先告白的事，之后对三人的理想期望。

很自然的让雪菜说出来了，千晶神。

车站的对话，也可以理解成，千晶话疗后，雪菜的尝试，但毫厘之间。

她当然是要先期待二者关系的修复的。

所以也是在为了演出和纱与雪菜，然后更加好的体验是吧。

依绪发现有人住过春希家。

千晶和父母到底什么关系呢。

草，差点爆了，雪菜和千晶，哈哈哈。

我当时还以为她遭遇什么事情了，结果是和雪菜吃饭吗。

然后，这段时间也是雪菜和春希在短信交流，升温的一段时间。

果然是演出来的有问题啊！被看透了。

所以在问高中学校的时候，已经露出破绽了，疑问的回答地名。

确实，感觉春希对千晶有女人、妈妈的感情。

演出结束就离开，又让我觉得有一些无情了，这就是 NE 的奇怪的地方，无情的地方。

因此在要结束的时候，也继续在帮春希解开心结吧。

所以，依绪在后面才能问出，春希和别的女人同居了。

一巴掌。

不过他最终没有逃避，挨了一巴掌，春希应该也是直面了自己对千晶的感情。

三年前一样……

依绪，一直站雪菜那里啊；武也，还是会多点对春希的袒护。

两巴掌。

武也，真的很会去理解春希的，他知道春希的。

三巴掌。

武也甚至可以把自己喜欢的本命，依绪放春希之后。

水泽依绪

说实话，觉得千晶怎么会在做那些事情后，还会去甚至找雪菜出来的，呼。

还是说想让雪菜彻底断开，大家都步入正轨吗？

从千晶发现雪菜还是在自责的诧异，感觉可以猜测。

被依绪找到春希交往的对象的时候，武也也是春希怎么没隐藏的好一点。

诶，是玩了 JoJo 梗吗

知道讨厌说谎，但是自己不自觉地一直一直地说谎了啊，小木曾雪菜。

这样，也还是……深情啊、勇气啊、坚强啊。

不能小看人的坚强啊。

但其实也有种承受不起的感觉。

诶！有白色相簿1的美咲学姐彩蛋。

濑能千晶吗？啊，我感觉越来越气了。

不会吧，不……会吧。

千晶很好，很好，但是我真的对这种不是真诚的事情，不太接受，我只觉得被愚弄。

濑之内晶吗？又。

偷走你的感情，拿走你们的故事，我不知道怎么描述这一行为，我。

说实话，受不了，受不了，受不了，受不了啊！

我大概知道我这样强烈的原因，因为三人的故事，我不容许它被这样子，并不是自私，就是，过分啊，千晶。。。

真是个「过分的」角色。

一个是出发点，一个是对感情的玩弄，虽然不是单纯的玩弄，但就是那个类似的意思。

过分，过分，过分。

「至今为止我所知道的这家伙的表情，到底占她整体的几成呢？」

转部吗，命运的齿轮。

北原的苦笑。

我完全理解，北原的感受，只是，如果是我的话，应该早该一巴掌过去了。

你的完美演出吗。

要录像带，也是。。

这样的感情。

是矛盾的吗？但是不能是这种程度吧，能是那段记忆吗，反正我不接受这种方式。

雪菜，雪菜。

这样一对比，我对雪菜感情起来了，我只能说。

谢谢你，小木曾，如果是让千晶先来，如果让我看到北原的再次沉溺，我会真的捏不住拳头。

谢谢你，雪菜。

你，你这么坚强吗，小木曾。

原谅是最大的惩罚，小木曾，三年都在经历这个痛苦。

坚强又温柔的小木曾。

北原终于说出来了吗，也终于说出来了吗。

但是，是选择她的吗，我唯一理解的点，只会是北原等这样的人，等太久了，等了三年。

但其实只解决了和雪菜的感情，可能北原觉得这样才是解脱吧，对自己、对小木曾。

他可能还是没有那份面对和纱的感情的勇气。

可能那时候真的太崩溃了吧。

2.14， 2.14，2.14。

真有病吧，丸户史明，你无敌了。

无敌了，小木曾雪菜这里的对话，绝杀，绝杀，来自三人的绝杀。

「那个时候，我还是以自己的身份……」

「你自己……？

那是，指谁呢？」

「……」

绝杀，绝杀，绝杀！

英勇无比的小木曾雪菜。

这样的腹黑，对了，对了。

对的，对的，是不可能由和纱以外的人颠覆的！

这个，事实，这个绝对绝对的事实！

只能由小木曾雪菜说出的事实。

这里从北原春希转回小木曾雪菜，完成对千晶的绝杀！

ps. 上面这一段确实应该是千晶的脑补，对她不能理解三人中和纱的存在的解释，对雪菜的恶意化吧，她演不下去。

怎么说呢，但是这段也是因为我当时就开始逐渐对千晶不爽，所以看着很爽。。

「结果，作为演员取得了巨大的成长，

然而作为人类却止步不前了」

「但是，即使时间是无止尽的，

但无论绕了多远路却有走完的时候。」

「明明能够理解他人的悲伤和痛苦，但是『那又如何？』」

春天，演出后就会抛弃一切吗。

但，不会结束吧，因为她已经发现不一样的地方了。

你tm不是知道吗，不是很清楚吗，北原春希，为什么才能够说出来呢。

因为没有直面吧。

「心灵不相通的肉体关系……

只是黏膜摩擦的重复运动罢了。

舒服什么的，怎么可能啊」

明明不还是在在意着三人吗，不是还是在抗拒着千晶吗，所以。

「……不是演技，的话？」

克里特悖论。

和泉千晶说和泉千晶是骗子。

真好啊，反而现在雪菜和春希的关系。

哈哈，饰品店的助攻。

台上，台下；

幻想，现实。

写的剧本可以看出千晶对三人关系、性格的猜测，但其实雪菜没有那么所谓心机。

把故事想得太简单了，三人的羁绊。

对，只有春希，只有北原春希，是一样的。

如果没有看见的话。

对的吧，千晶的认识还是有偏颇的，她认为，雪菜的忌妒、恐惧占主导。

千晶先后，春希、雪菜的变化是什么呢？

NE 和 TE 应该还是区别于春希对千晶的感情吧。

少一点就还是之前的状态，回到之前的状态，没有救赎。

多一点，就会更想着千晶。

总之还是不能面对和纱。

从对三人感兴趣，到发现自己的理解有偏差（若没发现NE，发现TE），而和北原春希更加接近，逐渐体会到北原春希，但最后发现还是不能自圆其说。。。

不懂。

在表演最后抱胸了啊。

GAL 的多周目的明暗线是精华。

小春线

小春，呜，小春。

抛开交集其实没那么多等等的因素，她，真的温暖了。

她，甚至考虑到春希很多朋友都是和雪菜共同的，选立场的问题。

由于心急而说出来的自己一下子不能察觉的怪话，哈哈

三年的初理解是，雪菜对春希的报复么，我只能考虑从她已经不自觉站在春希的角度看问题的方式去理解了。

或者说，因为小春亦或是春希，骨子里的感情就是直接的，不喜欢了就走掉这样，只是春希是这场漩涡的一员。

「那到底要怎样才能变成有关系啊？！」

心疼的春希雪菜的互相了解与默契，嗯，时间魔法。

小春这边和美穗子的刀，呼，真的，爱就是自私的吧。对于除开爱之外的人来说。

很快啊，学会了不坦诚，或者说，不直接。

称谓的变化，嗯，很喜欢搞这样的含蓄。

从逐渐变化，但不自知，到承认。

嗯，承认借口。

绝望、窒息啊。

嗯，小春的事情，你省略来看结果确实是这样的，不过，不过。

嗯，事情的过程、结果似乎其实不是那么重要，还是在人的想法。。

有种，春希选择冬马TE一样的感觉（当然，我还没推到）

小春，也被拉入痛苦漩涡之中。

真的很心疼啊。。

三女线都有额外的矛盾点，剧本上，且合理。

小春的发展方向，emmm

从可怜到哀叹。。

这条线把春希和小春实际隔得很开。

欲扬先抑吧，后半段终于看着正常了。

小木曾雪菜对杉浦小春的『answer』，嗯，何尝不是呢。

雪菜越是平淡放手，越是推一把小春，越是心疼雪菜。

果然一个月速通清泉大学还是失败了（

感觉相比千晶线多些真实感，比较千晶大魔王不是常人能理解的存在啊（（

麻理线

果然我对麻理没什么感觉，所以，这个线推起来就。。

音乐会真是好近的一次。

我还是偏向于北原的麻痹自我的自暴自弃

诸葛雪菜的雷达

三年前的对话重演，冲击力十足；却还在闪回和纱

雪菜真的真的每次最后的最后都会去体面。

雪菜的哭声。

无敌了，春哥，赶不上起飞，赶降落。

不过确实吧，麻理线，春希只有最后是支棱的，一直都很废。

春哥的冬马雷达（x

过程中的记录更少了，因此找补点总体的感觉，麻理线中，春希自暴自弃一点，投在工作中，逃避中，无法鼓起勇气和雪菜说清楚，被雪菜一直拖住了，最后的最后才做了选择。

剧情上总体是三年前冬马出国的复刻，北原做了不一样的选择，在这条线他的变化没有这么大，但有能力也更有决心去追出去。

雪菜和麻理的对比是明显的，一个是就算是替代品也可以，一个是不能接受。

雪菜线

最后的最后了。

传奇2-16，哈哈哈，观察细致啊，千晶大魔王

千晶的注视，结束了，因为春希对雪菜的坚持。

开始走入滑雪线还是对一个选项误判了，不然第一次应该就是雪菜线了（（

确实，北原总算是去找美穗子了吧，我早就觉得他该找说清楚了的，这才是我认识的北原春希吧。

雪菜线的小春真是落得我认为的HE吧。

嗯，就是下定决心要解决和雪菜的事，在此之前不可能再去提起冬马，所以是不会去音乐会的。

cc中依绪少有的站在了春希的角度，因为发现雪菜还是没有完全能释然，在春希好不容易要进一步的时候，她退了一步，扇了回去。

武也反而在为雪菜找补，是这样的吧。

也就是依绪没有理解到雪菜对三人这个整体的情谊。

觉得雪菜好像不是她理解的这样，有点前后矛盾。

支棱起来了，北原春希。

分手之后再恋爱。

来拒去留的诸葛雪菜。

反而是因为春希的突然的主动、直白，让雪菜要花更多时间才能说服自己。

在春天；在冬天，结束的时候

过去的我，对现在的我来说，太过耀眼。

柳原朋，嗯。

坚定的北原春希。

真是有手段的，柳原朋，这种手段，哈哈哈哈，也是太有分寸了。

在说直接说到三人的事情的时候，小木曾语气就坚定起来了。

真的真的坚强住了，冷静住了，像三年前一样。

雪菜妈妈也是感觉前面段时间，雪菜把自己藏起来了。

「不能吗，在xxx的时候，我想xxx，也不行吗」

学到了（不是

春希这个样子，真让人安心啊，幸福下去吧。

死去的敌人是无论如何都赢不了的呢，死去的白月光的力量，哈哈哈哈

后面的主线应该就是让雪菜能够直面这些事情，伴随着她与春希创造出来的二人回忆一起面对。

现在春希就是小心前进的等待，坚持。

她到底是要打助攻还是要。。

又要刀我，因为想要继续喜欢你，所以讨厌唱歌。

所以，春希说明了，我所喜欢的是过去那个还能敞开心扉的你。

不知道怎么说，这样下定决心的北原春希，让我有种释然的感觉，就是，嗯，就这样发展下去吧。

他真的在好好的重新追求着。

我更加偏向于这样终于，小木曾雪菜接受了北原春希的全部，而不是像之前一样，藏起来，藏起来。

孝宏这边也很好扭（x

这条线的千晶真的小上帝视角吧，除了她确实对三人的理解有点歧义吧。

在舞台上的小木曾雪菜，还是那么大方呢，一点没有台下的样子。

我还是会想，北原春希他究竟是什么心情呢。

关于和纱，关于。。

可能他觉得和纱其实也远去掉了吗。

也是二人创造出了，他们二人的故事，而不是停滞在只有三人吧

朋可能也是看出三人的故事了吧。

在过程中，春希对那些事情也是完全坦诚的呢。

北原春希的这句「因为，这是只有我才能做到的事情」，让我感觉，他是担起了带给雪菜温暖的「责任」，emm，也有可能是翻译的问题（？），不过也还是当作正常的情话呢。

时之魔法，在三年后的生日派对终于送上了。

雪，就是 answer 吧。

总的来说，这条线中，春希在三女的治疗下，下定要追回雪菜的决心，创作出两个人的故事，然后就是雪菜慢慢下定决心，慢慢脱下外壳，最终拥抱在了一起。

雪菜的听到出差地方是法国的坐立不安，怎么看也还是是因为冬马啊（bushi

要换真真真戒指了啊，求婚戒指。

知道有coda篇，这里的感觉确实会少一些平和啊。

完啦，「至于语言沟通上的问题，你大可不必担心。因为对方也精通日语」

「毕竟你的采访对象」后，就是冬马和纱的「Haruki」

不过还是会叹息一下，毕竟是和雪菜走过来了啊。

「这里是法国东北部的城市，斯特拉斯堡。

从巴黎坐特快列车到这里，大概需要两个半小时。」

「然后……

从维也纳到这里，坐直达的东方特快……」

这样的概率。

Kazu……sa?

CODA

最后的最后的最后了。

看到雪菜能说出自己的不满什么的，久违了啊。

不过，对于冬马和纱的事情，仍旧是小心翼翼放在心里，会担心啊。

但，春希也默契的察觉担心，并且不明说出来，说明自己要去的地点没有那个地方。

也是心意相通吧。

不过确实在这种地步下，我已经无法去选择和纱了吧qwq

但，让我重新试试吧。

依绪对武也又是怎么样的呢。

在撮合春雪二人的时候又是怎么样的心情呢，雪菜的真心没被回应（？），觉得春希是自己这方给对方带来痛苦那一方吗。

真的要问了，这声「春希」，是，是在开玩笑吗。

时机，明明，明明是想要给雪菜的时机。

和纱 => 冬马，呜。

后面总算关心的时候，感觉又回到了五年前。

怎么感觉春希还是被色诱了（（

我到底，要对雪菜隐瞒吗。

但是，北原春希已经做出自己的选择了吧？「那个人」。

他已经替我做出选择了吧，明明和纱也说了，所以，选择权在你啊，北原春希。

心疼雪菜。

如同北原的心理活动，如果是真的完完全全放下的祝福的话，早就提出要见一面了吧。

但是，还是想要这时间。

北原也在这信息差中，知道了冬马的想法。

又蒙上了一层纱布，已经不对了，已经盖上了。

哈哈哈，和纱和曜子的斗嘴。

采访结果是在「吵架」了啊，哈哈哈

对冬马性格的认识真的是啊，和她说了闭嘴，那要解除一下的幼稚，哈哈

在冷静下来的时候，又是可以和曜子说明自己的过去与未来的安排的。

又是富余的时间吗。

不再考虑事情的前后，荒谬的前后，而只是把握那一个小小的时机，真的对吗。

果然是因为春希最后说想要听和纱的钢琴，然后决定要来日本演奏的吧。

ensemble的主编，多次都是找北原春希还是可以理解的，毕竟都完成的不错，而且认识。

这样也遇到了吗，草，这就是fate。

冬马斗鸡眼立绘还是太草了啊。

「对不起」这个词，很让人在意啊，特别是和雪菜的对话中，两方都是。

小木曾雪菜和柳原朋流露的真实；柳原朋确实会在某些时刻逼他人一把。

曜子也是在推动和纱自己独自生活的能力进步。

又在回到五年前的纠结中了啊

没有你，和纱要怎么办啊？

我真的会这样想的。

太让人在意了啊，这家伙。

曜子这里的对话，真的像是在语重心长地交代后事。

直接住隔壁，草啊，那要是这一个月里，有雪菜在这边，画面太美我不敢想。

春希的言语又隐藏试探，下意识吧，真的就仿佛是他们五年前，在遇到雪菜之前，但又有交流的那段时间。

这剧本里多少还是有些不合理的地方，开始对冬马的独家采访后，老贼有意无意的把所有的内容都放在冬马上了，其实还有工作事物的描写或雪菜那边的描写，但是全都略过去了。

但其实对我来说，在没有选项时，北原春希做出的选择，作为最初的理由已经让我选择了冬马和纱。

她逐渐地不那么任性了，虽然内心不爽，但也在配合着。

不想靠近，是因为想要抑制住对春希的情感，对雪菜。。

为了自己感兴趣的事情，多少还是会去交流的呀。

怎么说呢，感觉多少也是让冬马在正确道路上进步了，不过到底是多伤心呢。

冬马也是能够假装坚强的那种，言语上，也立马能够成熟。

哈哈哈，少有的冬马说着开心、兴奋的语气。

柴田太太真好哇。

微笑的泪水，应该就是所谓的幸福的泪水吧。

和曜子的担心一样，到现在的发展都很好，冬马开始独立起来了，但未来的收场到底会是怎么样呢。

东野和美吗，哈哈。

所以，冬马至少不是一直认为是春希先去表的白。

所以，你，你别笑啊。

所有的第一次都是我啊。

「是我，是我先……

明明都是我先来的」

「接吻也好，拥抱也好。

……还是喜欢上那家伙也好」

在这里，沉寂了这么就的情感，终于迸发出来的时候，自然。

也并不是什么做作的语气，或是歇斯底里。

就是这样，说明着。

快说，你是开玩笑，是在捉弄我，是在报复我，快说是啊

「因为如此悲伤。

我那，向前推进了的时间，

与和纱她，停滞不前的时间之间，

产生如此决定性的错位吧。

那错位……直到现在」

「你觉得……我是在开玩笑？

到现在为止我所说的，你都能当作玩笑而笑出来吗？春希」

「我怎么可能笑的出来呢……

所以求你了，换你来笑我啊」

「你要是不笑的话，

我，会不知道自己该怎么办才好啊……」

这段，文本。。

好好好，喜欢ntr元素，这时候短信提示。

诸葛雪菜的timing

永别了，永别了，说了好多会，骗不过自己。

最后一次的免罪符。

对着雪菜的短信还能说什么呢。。

你无敌了啊，北原春希怎么是这个时候去找小木曾雪菜的温柔乡的？？！

不愿面对和纱说出的现实吗？也不想这就是最后一次吗？

你不是在骗自己吗？北原春希？？

因为他还没有做好准备，就是逃避着，不想把现在的自己给和纱看。

觉得自己配不上和纱，让和纱对自己彻底失望，走掉吧。

就算这不是自己的本心、真心。

所以，让冬马和纱这么伤心。

你都在做什么啊。。

在录音机里制造的，另一个决定性的时间差。

不过，如果，真的去了，真的又会是最后一次吗？

事与愿违了吗？想要逃离而背叛、彻底决断，至少表面上，然而让她无法彻底忘掉。

所以呢，你前面到底做了什么选择啊？北原春希。

雪菜NE

发现「我无法对和纱说谎」是灰色后，便发现是前面迷惑性极强（甚至不能说是迷惑性了，就是不懂的）第二个选项错了，然后直接NE Flag。。

不懂，不懂。

虽然说这个结局的内容，我其实个人是可以接受的，甚至觉得发生在自己身上大概率就是雪菜NE，但是我不懂这个选项为什么会引导至这个。

别的涉及好感度的全对不过也只有4分，呜。

看了看分析吧，大概就是，见过和纱了是会被发现的，另外的选项只是敷衍一时，没有担当，就不能走向TE。

把隐瞒不住的说出来，反而显得有些担当吗。

确实，我还是IC的样子。。

确实，至少要做好什么程度的是可以坦白的。

嗯，可以理解了。

总的来说，如果春希在冬马受伤那一段正常离开的话，我是不会对冬马有继续的想法的，但是他给了我继续的理由，那我便会坚持到底。。

所以可能可以看出我是怎么样的。

放在现实，自己的话，大概就是稍微照顾一下，然后跟雪菜说这件事情，总之不会继续。

为了担当啊。

但是这个选项后续，北原春希讲的内容我又怎么知道呢！

只先讲了采访的公事，太有话术了，学习一下（（

冬马TE

提到半年前，春希挽回雪菜的事情，也是通过雪菜家人。。

大do特do后，雪菜当然知道春希是为了逃离对和纱的思念而来。

然而，雪菜，就像IC的时候，只要最后的最后是我的话，就接受了。

回到了那种状态。

不过相比之下，因为有二人新的回忆，她并不是就像IC时那么放弃。

好坚定，这是一定要不会伤害到任何人的恋爱，已经不可能了，必须做出，一定要伤害谁的决定了。

就是这样，两个人也都是冷静下来了，冷静的评估了这个选项，也确定了春希对和纱的情感。

多坚持一天，原来是对自己说的吗。

完全就是小孩子的任性啊，不过没办法生气呢。

忠犬，哈哈

曜子这个炸弹，真的是啊。

若不是这个的话，我觉得是和纱跟着曜子逐渐独立，春希与雪菜继续幸福，二人加一人的共同幸福吧，虽然这边的雪菜，应该也是NE吧。

把普通人人生破坏掉的力量吗。

不过，确实，确实，很理智了，但是无法想象独自一人的冬马和纱啊。

这里的和纱，真的是可爱吧。

没想到之前和纱说的瘦了，曜子这么在意

会去转移话题，会去自己担当。

太，太刀了，没有人有错，庆祝他们订婚的事情。。

在这里，日本已经对应的两位友人的地方了。

唉，好痛苦。

cc三女的鼓励再次出现，因为这次的选择，依旧甚至更加困难。

冬马和纱只有钢琴，钢琴里的世界，那个世界里的人们。

只能依靠我的你。

我会给你开辟出道路。

这，北原春希，真的是超人了，真的。

被机场情节骗了，以为插叙飞回去的画面。。

到这个高度了的话，我只能仰望了。

每一句话，所有认识的人，发的每一句话，不管是什么内容，都会像利剑一般插入他北原春希的心脏。

然后，丸户史明，现在确定了要毁灭掉小世界的美好之后，开始增加雪菜的戏份。

北原春希对冬马的选择，已经不只是对真爱的选择了，还有其他复杂的情感。

让他选择冬马的原因并不存在，他爱她，胜过一切。

蚂蚁与蟋蟀。

有雪菜的地方容不下二人吗？是无法一起支撑吧。

武也，依旧在他的范围内为春希找补。

在依绪、武也还不清楚情况的时候，为北原春希的辩护，更是让北原春希痛苦。

他们想要听到不可能。

但是，北原春希，已经走上了一条无法回头的路。

不是简单的执着，不是简单的喜欢了。

依绪对这件事本身的不认可，直接上升至对这件事、两个人的指摘，让春希产生痛苦；

武也，打断了这一切，他不希望她们是要通过对北原春希不断的贬低，换来北原春希的认错。

他们都知道，要是把真正的原因说出来，雪菜大概率会一起背负吧。

但是，三个人一起背负，在现在这个时间点，三个人是两人加一人，这不是对和纱选择，这至少事情的解决。

因为，北原春希，已经回到最最最幼稚的选项。

武也，在北原春希另一层面上，最重要的人。

雪菜家人，不在雪菜的意愿下，也掺入了这次是事件。

雪菜，也做了最后的心理准备，三人的事情，让北原春希做最后选择。

北原春希，没有对任何情况隐瞒自己这不合时宜、不合正道的选择，正面迎接雨点。

没有人会相信，北原春希会做出这样的选择，就算是看到他心路历程的我们，也不太能相信。

确实吧，一个个对北原春希降下惩罚，反而让北原春希终于对与和纱一起而要承受的痛苦有了实感，使得更能这样做了吧，小木曾雪菜的意思就是这个意思吧，把他们分得越远。

那两人的三人确实不一样啊。

一个是大世界，一个是小世界。

我不会再抢了，不会再抢属于和纱的春希了。

这里的春希，已经完全的知道和纱要的是什么，雪菜要的是什么，是不能相融的。

冬马和纱，也要赌上自己的一切了。

脱离开雪菜的社交圈的同事也是正式要再见了，也已经是朋友了。

雪菜，不动声色地说出杀伤力很大的话，她的真实，和纱的梦境。

在描述上，说出春希和她经历后的改变的不同。

因为，雪菜知道了，只有让自己受伤，让他们知道，如果离开春希自己也是活不下去的。

雪菜尝试抛下一切，但果然，还是不行呢。

车祸了，在前一天晚上。

这是，小木曾雪菜最后的尝试，但是她发现，她果然。

嗯，酣畅淋漓的冬T，战神北原春希与冬马和纱。

小木曾雪菜，能还在唱歌，真的，太好了啊。。

最后都以为那个雪菜的日子，会是什么不好的事，毕竟能支撑北原春希开始这样的，是雪菜能自己幸福吧。

在这里我小小思考剧情的合理性，就是北原春希后期的坚定与开始的时候，我还是会觉得有些违和。

就是最开始斯特拉斯堡的时候，他能这么自然的就选择陪冬马，而推后自己的求婚，这件事情，我觉得无法理解。

所以，这个开端，让我觉得，应该是浮气线才是TE（？），不过还没推。

雪菜TE

这前面的各种汇报的举动，让我舒适，心里舒适，那种符合正道的舒适。

但是，让我好伤心啊，这样的冬马。在把眼睛移开这里。

音乐会晚的一巴掌，才会让春希安心点吧，这才是小木曾雪菜吧。

因为，就算春希是诚实了，但是也一样是在最后的时候，为了逃离和纱，才过来了。

因为相信，所以无法相信。

在春希坚定走雪菜TE的时候，和纱其实也没有那么偏执，她会时不时让春希回到雪菜那里去之类的。

这其实也是由春希的不同而不同的。

那某种程度上说，夜里给雪菜发短信这些小细节，大概是被和纱察觉到了。

同时，瞒住一个人的行为，当然总是会让被瞒住的人伤心。

冬马其实确实还是很心理敏感的，虽说迟钝，但有时候又会很敏感。

冬T是冬马约雪菜出来，雪T是雪菜去见冬马。

真的太重了，冬T中所背负的，让我在这边春希向雪菜求助时，大大的缓了口气，终于是有人能求助的，有人能说出去的。

北原春希的特刊与小木曾雪菜的特CD，给冬马和纱。

面对毁灭的世界，二人的态度是不一样的，冬马是觉得自己被切断了，而小木曾则是要从与他人的联系中寻找慰藉。

冬马先打的雪菜，然后雪菜又打了冬马。

然后，后面每说一句话，每打一下（

她觉得雪菜已经什么都得到了。

春希还有给柴田太太票这种招数，给冬马台阶下

雪T是雪菜超人吧，治疗着冬马。

时之魔法，效果拔群。

说实话，看到这样坚强起来的冬马，嗯，我还是很高兴的。

草，合宿。

这么前后呼应。

这帅气的冬马。

收到专辑里，这下这首歌又属于，属于冬马和纱了啊。

同事的反哺关系也是。

时之魔法，原来，哈哈哈，哈哈哈。

是雪菜的时之魔法吧。

依绪和武也，冬马，真的开始构建起来她的新世界了吧。

恶作剧的冬马和纱，哈哈哈，把雪菜搞这么惨。

录制结束后的三人变化，emm，让我有点过载。

一条条回信，其实就在那里。

为什么雪菜还是在强调怕被讨厌、怕不被依靠等呢。

那份爱的自私吗？

觉得自己还没有完全被北原春希所认知到吗？

无法原谅，是无法背负，这一点我可能还是需要花时间消化。

对的吧，北原春希和冬马和纱，都是可以只爱另一个人的那种。

但，小木曾雪菜，是会爱自己的。

（无任何褒贬义）

维系的小木曾雪菜。

不经过这么麻烦手续，就无法回应你的、复杂麻烦的小木曾雪菜。

这段后，其实不太愿意看HS的。

浮气线

第一次音乐会的选择，没有去听音乐会的选择想想还是很难过的。

浮气线，HS心理活动都是北原春希自己的逃避、懦弱，对之后的后果其实知道，但是陷入了。

开始很明显的找借口支开雪菜。

『坂本纯生』

嗯，真的偷感啊。

自己也很折磨。

浮气线的北原春希真的差到极致了。

三人，与三年前的最后的不坦诚，一样。

心理活动里，也表明了，这条事件线的北原春希没有和冬马一直走下去的决心。

两个人都在逃避，都在尽力沉醉在这一个月的桃源里。

白色和黑色都没有选择，选择了灰色。

北原春希一堕到底，和纱只要自己想要的结局，同时不要另外两人，只要不被发现，只要春希愿意

听到春希说说服雪菜父亲的相关，雪菜从不安中稍微好一点了吧，最后应该也是知道是什么情况了吧，不过，也就觉得这样吧。

可能她也还没有鼓起什么样的勇气。

而柳原朋的提议也就绝非偶然，是她故意的。

和五年前一样的逃避，去和纱了。

确实很重啊。

由于渴求的虚假的满足，所以需要远超正常的虚幻才能满足。

北原春希坏掉了，我只能这么说，做出了他绝对不会做的事情。

当然，如果说是在当时对雪菜做的事情，又对别人做了，那确实是这样的

甚至连冬马都觉得不对了。

真的罪孽深重吧，疯狂闪回雪菜，自己和雪菜表白的画面。

我不得不承认，我之前时不时逃避想象的就是这种，什么杂事，除了自己渴望的事情，都不需要，不想要。

只要什么什么样，我就不会害怕，什么的，都只是说给自己听的，我没事，真的没事吗？

不是的。

太差劲了啊，并且假定和纱就不在意，也这样没事。

这样说着大话，明明没有这样的决心了，却还在说着自己以往说着的，怎么样我都做出来给你看，嗯。

怎么说呢，春希变得更像和纱了，甚至更甚吧。

我觉得还是需要的，希望她不用过多的考虑，那就自己把她的那份也考虑进去啊，真的考虑对了，自己下定决心了，再，再继续吧。。

不同的便当，学到了（bushi

但，感觉也是对这个情况的说明吧，两个人，一味地互相贴合是不是。。

至少，他们事实上是这样的。

就是说，也就是变成fw了啊，春希君。

这样的，放弃效率什么的，倒怪和我现在的心理状态类似么，拜托。。

多少也是会更加有分寸吧。。

能够被依靠。

HS里所表达的就是这条线的东西了吧，和纱痛苦着，让北原春希选择他想要的方式，因为这样她也就舒服够了。。

在温泉地方，也明确说了，他内心不知道要是真的这样选择，他要怎么回应，但只是逃避，继续逃避。

想让和纱，逃入春希的小世界，这样的选择，总是会有裂痕的。

「北原和纱」

真正看不到未来的承诺，是对感情的极度亵渎。

至少我，我不想看到这样的未来发生在我身上。

游戏中，把这样的矛盾，其实是扩大了的，扩大成一个大世界与一个小世界的融合。

现实中，就算一个小世界和另一个小世界的融合，其实也是这样吧。

我也不知道，曜子生病的消息，和纱在这个时候又有得知吗？

大概是没有的。

真的不敢相信，这样之后，然后这样怯懦的北原春希，怎么陪伴呢。

和纱当然是一直清楚，如果把春希一起到国外，他要承受的，曜子和她也说过，让普通人的世界破坏掉的说法。

最后的最后，因为对春希的爱，她，她还是会为了不那样的春希的自我，而放弃春希。

这样的爱。

和纱并不是只是爱着自己，爱着有春希的自己，更是，有春希的冬马和纱与有和纱的北原春希的幸福的两个人。

这样的北原春希为什么是不幸福的呢？

因为，他真的能不逃避吗？

真的能去切断那一切吗？

真的能在未来的某个夜晚，某个梦境，不被这样那样的事情而又害怕得要逃跑吗？

就这样，逃避到和纱的怀中？

他，能幸福吗？

本来我是希望，我是能让你幸福的那一个人。

不过，冬马和纱是天才，她还是拿下了她的音乐会。。

不然的话，呼。

那个只能在演奏会时让他听的落寞，大约是这两个世界的差集吧。

他握不住。

所以，第一次音乐会，若是听到了的话，嗯。

听音乐会也是一个象征了吧。

如果CC听了的话，大概也就是这样了吧，就算把选项灰掉了。

两个世界的差集，写着三个字──「不可能」。

「只凭感情、还是有办不到的东西的。

我没有为此，在一直以来的人生中去努力奋斗过。

没有切实的掌握那些」

是啊，否则，只有不安，只有逃避，何谓幸福呢。

再回看冬T，第二次音乐会，不需要去的时候，北原春希已经加入冬马和纱的大世界了。

追随而去了。

雪菜那个时候也就知道了，决心已下，两个人要共同奔赴了。

雪菜当然清楚一切了，但她是能够接受就这样糊涂下去的。

表现的，可以是幸福的。

但，不是雪T中的真正的小木曾雪菜。

但，最后的表达还是像个人吧，罪责感，让自己背负。

但是这条线中，和纱真的不知道母亲的情况。

后面又会怎么样呢。。

放弃了你，但是不会放弃爱你。

曜子的话，也说明了，要是她也离开了，和纱真的还能坚强吗？

和和纱预想的一样吧，媒体只是抓住特殊，只是一阵热潮。

雪菜，也在继续唱歌了吗。

她在用歌声，就像是和纱用钢琴一样吧。

在北原春希没有做出自己的坚实的选择后，不共戴天的仇敌……吗？

虽然，北原春希和小木曾雪菜在音乐会上做了分别，但，这份决绝，后面慢慢品味时，可不会这样快的消逝。

雪，掩盖住了；

掩盖几年间所有；

会，再次化开。

这次的届不到的爱恋，是北原春希吧。

这次要是有曜子的病症压在这上面，又会怎么样呢？

可能真的会出现，春希BE吧。

多周目追加剧情

这个丢最后，然后每次看到点，加进来吧qwq

采访说明

火车上，其实可以看出来并不是巧合，是冬马曜子安排的。

只不过人员嘛，可能确实巧合。

车站前冬马视角

呜。

和纱和曜子说明脚伤

呜。

接受日本巡演

冬马日本巡演的决定过程，并且说明的冬马开始的目的，至少在冷静的时候，不是夺走，而是祝福。

选择春希独家采访的原因，短期的猛药

冬马没睡，曜子一开始也是清楚冬马是要来结束的，给上祝福的，不过她应该确实有事情，所以让北原春希来照料是最好的。

睡不着的冬马

思乡，其实思的是温柔乡，不过冬马回答的是这个已经不属于她了。

最完美的冬马和纱

不让他现在看到弹琴。

早知道如此快乐

早上散步，快乐，但又要克制。

雪菜的live

柳原朋是希望雪菜不要埋没掉自己的好心思（不过cc就知道了）

朋发现了冬马的伪装。

雪菜得知冬马

所以，雪菜就会知道，然后心存芥蒂。

清除的短信

雪菜未发出的讯息里，还有对冬马的发现。

冬马对春希睡梦中说话

未睡着的冬马和纱。

和纱的毫无防备，也有对春希本性的信任，这里也大概能反映出浮气线的缘由。

不要紧不是说给自己听的

春希内心的纠结。

如何用codeforces的polygon平台进行出题

Wed, 05 Jul 2023 00:00:00 +0800

旧文

背景

前几天刚刚完成人生第一次出题~~（其实就是魔改题面，重造数据）~~。

虽然，能略微找到相关博文，但好像还是不太够，所以还是写一下。

本文就按照出题的顺序好了。

ps. 本文指涉及传统题目的过程，不涉及交互题等方式。

同时推一下看到的挺全的文章codeforces的polygon平台使用指北。

注册

找到polygon 的网站，要重新注册一个号，这个和codeforces主站不是同一个账号系统。

建立题目

点击上方的New Problem。

填写题目名字。

自动跳转到View Problems界面，找到刚刚创建的文件，点击Start。

General info

由于要出的是传统题，根据要求改Time limit和Memory limit即可。

方便的话，在Tags一栏加上题目涉及的知识点，或是否隐藏评测的提示（由于我没用，就不讨论这个）。

Statement

题面。

选择好语言，然后填写题面，具体的效果可以用In HTML等预览，多语言就Create New即可。

具体每一栏要写成什么样子，可以参考codeforces官方比赛或已存在的题目的题面。

Files

可以在直接一次把我们写好的标程std.cpp，数据生成的程序gen.cpp和生成的数据是否合法的程序vaild.cpp，答案检验的程序checker.cpp传上来。（vaild.cpp和checker.cpp不必须）

这里的名称不一定一致，只是代表它的作用。

这些程序怎么写我这里不展开，可以自己去看codeforces自己写的关于testlib.h库的使用。

Checker

答案（格式等）的检验器。

上面虽然说checker.cpp不必须，但是这里是要选的，不然后面Tests生成的时候会出错。

一般选忽略空格lcmp.cpp或不忽略空格fcmp.cpp，如果要special judge就需要自己写checker.cpp了。

具体效果可以使用下面的Checker tests来看。

自己设置输入、输出、答案和是否合法，然后看实际评判结果。

Validator

生成数据是否合法的检验器。

感觉一般还是用于后面hack阶段的造数据的合法性。

所以，其实也可以没有，但是会在提示有warning。

还是建议写一下，写法也是看codeforces的官方教程。

同样也可以在下面进行测试是否达到自己预期。

建议在Files上传，在那边是可以直接编辑的。

Tests

数据生成的设置参数的地方。

有两种方式设置数据。

第一种是中间的Add Test ，本地生成后，手动输入。

第二种是推荐的写法，需要用到之前上传的gen.cpp，在Script输入框内输入脚本命令。

具体脚本使用方式，右边比较清楚。

1

[你的数据生成文件名（不带后缀）] 参数1 参数2 ... > [输出到的地方，这里为数字，或者直接 $ 自动识别]

写好保存，中间就会出现一条条命令。

点击Preview Tests就可以生成数据了，如果已经在Solution files中设置好了标程，是可以直接也显示对应答案的。

Stress

在线对拍。

大概是选择其他上传来的程序，然后和main correct solution标程对拍。

我的出题中没有用到。

Solution files

解决文件。

这里是上传标程、正解等程序的地方，当然还有用来Stress对拍的程序。

注意main correct solution是标程，且必须要有，别的有没有都无所谓。

Invocations

用生成的数据来测程序的地方。

相当于custom test。

可以帮助知道在OJ上跑大概是什么速度，会不会有什么环境不同导致的不一样等等。

Issues

团队交流的地方。

我的过程没有用到。

Packages

打包题目的地方。

根据自己需要选Standard或者Full，方便搬到本地或者别的OJ。

Manage access

管理题目权限的地方。

一方面是加出题团队成员。

另一方面是把题目放到codeforces上，要点击Add User，添加codeforces为管理，后面复制右边的url填入codeforces的mashup里，就可以实现题目导入了。

Verification

在右半边框里。

点击可以查看题目有什么显性的问题。

2023年XDU-ACM校赛个人题解（部分）

Fri, 19 May 2023 00:00:00 +0800

旧文

题面PDF

补题链接

D - 燃起来了！

期望题。

因为我做期望题很少，赛时直接跳了，后面推推感觉还行，大概设计好，有终结状态的状态信息一个就行（？）

$$ 令 \space p = a/b, \space d = x/y, \space r = x\%y, E_i 为经过i次连续失败后，第i+1成功的时间长度的期望\\ E_0 = y + p \cdot E_0 + (1-p) \cdot E_1 \\ E_1 = y + p \cdot E_0 + (1-p) \cdot E_2 \\ E_2 = y + p \cdot E_0 + (1-p) \cdot E_3 \\ ... \\ E_{d-1} = y + p \cdot E_0 + (1-p) \cdot E_d \\ E_d = r \\ \Rightarrow E_0 = r + y \cdot \sum_{i=1}^{d}{(\frac{1}{1-p})^i} \\ \Rightarrow E_0 = r + y \cdot \frac{(1-p)^d-1}{(1-p)^d \cdot (-p)} $$

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

const int MO = 1e9+7;

int qpm(int a, int b, const int &c = MO) { // int/LL
 int ans = 1 % c;
 while(b) {
 if(b & 1) ans = 1LL*ans*a % c;
 a = 1LL*a*a % c;
 b >>= 1;
 }
 return ans;
}

void solve() {
 int a, b, x, y;
 cin >> a >> b >> x >> y;
 if(a == b && y <= x) {
 cout << "forever\n";
 return;
 }
 int p = 1LL*a*qpm(b, MO-2) % MO, d = x/y, r = x%y;
 // cerr << y << ' ' << p << ' ' << d << ' ' << r << '\n';
 int ans = (1LL*y * (qpm(1-p, d) - 1)%MO * qpm(1LL*qpm(1-p, d) * (-p)%MO, MO-2) + r)% MO;
 ans = (ans + MO) % MO;
 cout << ans << '\n';
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("i.txt", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

E - 全自动窗口调度算法

好像大家，把序列存下来纯模拟的多，我是维护每个窗口的最早空闲时间，然后更新就行。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62


#include <bits/stdc++.h>

#define fi first
#define se second
#define all(a) (a).begin(), (a).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;
typedef pair<LL, int> PLI;

void solve() {
 int n, m;
 cin >> n >> m;
 vector<LL> a(n), v(m), belong(n), cnt(m), t(m);
 for(auto &x : v) cin >> x;
 for(auto &x : a) cin >> x;
 sort(all(a));
 set<PII> st; // cnt, id
 set<PLI> done; // time, id
 for(int i = 0; i < m; i ++)
 st.insert({0, i});
 for(int i = 0; i < n; i ++) {
 while(done.size() && done.begin()->fi <= a[i]) {
 int gid = belong[done.begin()->se];
 done.erase(done.begin());
 st.erase(st.find({cnt[gid], gid}));
 cnt[gid] --;
 st.insert({cnt[gid], gid});
 }
 auto [nn, gid] = *st.begin();
// cout << nn << ' ' << gid << '\n';
 st.erase(st.begin());
 cnt[gid] ++;
 st.insert({cnt[gid], gid});
 done.insert({max(a[i], t[gid])+v[gid], i});
 belong[i] = gid;
// cout << t[gid] << '\n';

 t[gid] = max(t[gid], a[i])+v[gid];
 }
 cout << (done.rbegin()->fi) << '\n';
}

int main() {
 ios::sync_with_stdio(0);
 cin.tie(0);
 cout << fixed;

 int Tcase = 1;
// cin >> Tcase;
 while(Tcase --)
 solve();

 return 0;
}
/*
3 1
100
1 10 301
*/

F - Z-O 平衡

做法1 - $O(n)$

~~大概骚扰luoyue一段时间后，明白了~~

考虑数字从左到右一个一个加入序列，每次加入，考虑新加入的数对前面所有序列和自己的总贡献。

由于奇偶的作用不一致，很自然地可以考虑一个序列的奇数个数-偶数个数不同时它对答案的贡献，即需要几次操作，会得到以下序列：

1
2


odd - even -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6
 3 3 2 2 1 1 0 2 1 3 2 4 3

可以找到，序列奇 - 偶为正数/负数，奇数/偶数，增加/减少时的影响，通过一个数组+偏移量，维护整个序列。

base-delta永远是0的位置。

upd. 有些佬表示好像还是不太明白变量含义，我这里统一解释下：

在当前偏移情况下，考虑所有连续子序列，negE 是奇数-偶数的个数是负数且偶数的个数，negO 是奇数-偶数的个数是负数且奇数的个数，pos就是正的奇数/偶数。zero就是奇数-偶数 = 0的个数，因为在发现的规律里，0是特殊的，需要额外记录。

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

const int base = 2e5;

int delta;
LL ans, res;
int rec[base<<1];

void solve() {
 LL n, negE = 0, negO = 0, posE = 0, posO = 0, zero = 0;
 cin >> n;
 while(n --) {
 LL x;
 cin >> x;
 if(x & 1) {
 delta ++;
 res = res - negO + posE*2 - posO + 2*zero + 2;
 rec[base-delta+1] ++;
 swap(posO, posE);
 posO += zero;
 posO ++;
 swap(negO, negE);
 zero = rec[base-delta];
 negE -= zero;
 }
 else {
 delta --;
 res = res + negE + posE - 2*posO + zero + 1;
 rec[base-delta-1] ++;
 swap(posO, posE);
 swap(negO, negE);
 negO += zero;
 negO ++;
 zero = rec[base-delta];
 posE -= zero;
 }
 // cerr << posO << ' ' << posE << ' ' << negO << ' ' << negE << '\n';
 ans += res;
 }
 cout << ans << '\n';
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("i.txt", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}
/*
odd - even -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6
 3 3 2 2 1 1 0 2 1 3 2 4 3
*/

做法2 - $O(nlogn)$

~~口糊一下好了，因为先看的O(n)做法~~

和第二种一样做偏移，用两个树状数组记录下前面序列的各个奇数 - 偶数的个数，一个记录结果为奇数的各个长度的个数，一个记录结果为偶数的各个长度的个数，树状数组来维护正负的个数的信息，然后强行把第一种$O(1)$维护的东西变成$O(logn)$维护的东西（（逃

G - 最强平行组合

因为选课没有限制选课相同，可以用背包最大化同个学分下的经验。

再用枚举二进制状态的做法，把每个学分的合法子集的最大值归为自己的值。

这种做法理论复杂度极高，但是出题人放过了（

~~求教std做法~~

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

void solve() {
 int n, k;
 cin >> n >> k;
 vector<int> a(n), b(n), f(2e5+1, -1), g(2e5+1, -1);
 for(auto &x : a) cin >> x;
 for(auto &x : b) cin >> x;
 f[0] = 0;
 for(int i = 0; i < n; i ++) {
 for(int j = 2e5; j >= a[i]; j --) {
 if(f[j-a[i]] != -1) {
 f[j] = max(f[j], f[j-a[i]] + b[i]);
 }
 }
 }
 for(int S = 1; S <= 2e5; S ++) {
 for(int T = S; T; T = (T-1) & S) {
 if(T < k) continue;
 g[S] = max(g[S], f[T]);
 }
 }
 int ans = -1;
 for(int i = 1; i <= 2e5; i ++) {
 if(g[i] != -1 && (i^((1<<18)-1)) <= 2e5 && g[i^((1<<18)-1)] != -1) {
 ans = max(ans, g[i] + g[i^((1<<18)-1)]);
 }
 }
 cout << ans << '\n';
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("i.txt", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

I - 你相信光吗

网络流板子题。

几个注意点，题目是有向图，加容量和恢复容量有些细节。

~~因为其实是赛时的代码再赛后略修一下，现在已经忘得差不多了~~

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101


#include <bits/stdc++.h>

#define fi first
#define se second
#define all(a) (a).begin(), (a).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

const int N = 310, M = 16000;
const LL INF = 1e18;

int idx, h[N], ne[M], ver[M];
LL e[M], rec[M];
int n, m, S, T, C;
int d[N], cur[N];

void add(int a, int b, LL c) {
 ver[idx] = b, e[idx] = c, ne[idx] = h[a], h[a] = idx ++;
}
bool bfs() {
 queue<int> q;
 memset(d, -1, sizeof d);
 q.push(S);
 d[S] = 0, cur[S] = h[S];
 while(q.size()) {
 int t = q.front(); q.pop();
 for(int i = h[t]; ~i; i = ne[i]) {
 int v = ver[i];
 if(d[v] == -1 && e[i]) {
 d[v] = d[t]+1;
 cur[v] = h[v];
 if(v == T) {
 return true;
 }
 q.push(v);
 }
 }
 }
 return false;
}
LL update(int u, LL limit) {
 if(u == T) return limit;
 LL flow = 0;
 for(int i = cur[u]; ~i && flow < limit; i = ne[i]) {
 cur[u] = i;
 int v = ver[i];
 if(d[v] == d[u]+1 && e[i]) {
 LL t = update(v, min(e[i], limit-flow));
 if(!t) d[v] = -1;
 flow += t;
 e[i] -= t;
 e[i^1] += t;
 }
 }
 return flow;
}
LL dinic() {
 LL res = 0, flow;
 while(bfs())
 while(flow = update(S, INF))
 res += flow;
 return res;
}

int main() {
 ios::sync_with_stdio(0);
 cin.tie(0);
 cout << fixed;
 memset(h, -1, sizeof h);
 cin >> n >> m >> C;
 S = 0, T = n;
 while(m --) {
 int a, b, c;
 cin >> a >> b >> c;
 rec[idx] = c;
 add(a, b, c), add(b, a, 0);
 }
 LL res = dinic(), r1 = 0, r2 = 0;
 vector<PII> vvv;
 for(int i = 0; i < idx; i += 2)
 if(e[i] == 0)
 vvv.emplace_back(ver[i^1], ver[i]);
 for(auto [x, y] : vvv) {
 int tx = h[x], ty = h[y];
 for(int z = 0; z < idx; z += 2)
 e[z] += e[z^1], e[z^1] = 0;
 add(x, y, C), add(y, x, 0);
 LL tres = dinic();
 idx -= 2;
 h[x] = tx, h[y] = ty;
 if(tres > res) {
 res = tres;
 r1 = x, r2 = y;
 }
 }
 cout << r1 << ' ' << r2 << ' ' << res << '\n';
 return 0;
}

J - bzy 的出行

xorzj说，Cow Relays G 是原题，需要的前置知识有，矩阵快速幂、floyd。

因为floyd和矩阵乘法的类似性（是可以这么说的么），用类似矩阵快速幂的形式预处理出g[k, i, j]，代表经过$2^k$条边，i 到 j 的最短路径长度。

不做预处理时间复杂度是$O(T \cdot n^3 \cdot log(1e9))$，会被卡飞。

然后有一个优化的点是，每次只有一个起点，所以求答案的那个数组可以用一维的，把时间复杂度降下来。

~~下方码风较凌乱~~

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

const int N = 210;
const LL INF = 0x3f3f3f3f3f3f3f3f;

LL g[31][N][N], f[N], ff[N], ans[N][N];

void solve() {
 int n, m;
 cin >> n >> m;
 memset(g, 0x3f, sizeof g);
 while(m --) {
 int a, b, c;
 cin >> a >> b >> c;
 g[0][a][b] = c;
 }
 int T;
 cin >> T;
 auto floyd = [&](LL a[N][N], LL b[N][N]) {
 memset(ans, 0x3f, sizeof ans);
 for(int k = 1; k <= n; k ++)
 for(int i = 1; i <= n; i ++)
 for(int j = 1; j <= n; j ++)
 ans[i][j] = min(ans[i][j], a[i][k] + b[k][j]);
 memcpy(a, ans, sizeof ans);
 return;
 };
 for(int i = 1; i < 31; i ++) {
 memcpy(g[i], g[i-1], sizeof g[i-1]);
 floyd(g[i], g[i-1]);
 }
 auto floyd1 = [&](LL a[N], LL b[N][N]) {
 memset(ff, 0x3f, sizeof ff);
 for(int k = 1; k <= n; k ++)
 for(int i = 1; i <= n; i ++)
 ff[i] = min(ff[i], a[k] + b[k][i]);
 memcpy(a, ff, sizeof ff);
 return;
 };
 int s, k;
 auto qpm = [&](int k) {
 memset(f, 0x3f, sizeof f);
 f[s] = 0;
 int kk = 0;
 while(k) {
 if(k & 1) floyd1(f, g[kk]);
 k >>= 1;
 kk ++;
 }
 return;
 };
 while(T --) {
 cin >> s >> k;
 qpm(k);
 for(int i = 1; i <= n; i ++) {
 cout << (f[i] == INF ? -1 : f[i]) << " \n"[i == n];
 }
 }
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("i.txt", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

分块入门九题

Tue, 16 May 2023 00:00:00 +0800

本篇文章为旧文

分块入门九题

code by Livinfly

原文连接：「分块」数列分块入门1 – 9 by hzwer - 分块 - hzwer.com

开始前，先%%hzwer大佬

主要是贴我的代码，和发现的一些问题，主要思路的讲解hzwer学长已经讲得非常深入浅出了！

关于一些块的大小的取法，数列分块总结——题目总版（hzwer分块九题及其他题目）（分块） - Flash_Hu - 博客园 (cnblogs.com) 有提到一些，我这里就全方便起见取$\sqrt{n}$了。

分块入门九题的题目：题库 - LibreOJ (loj.ac)

我在LOJ上提交都有记录，用户名为Livinfly，如有需要也可以去LOJ查看通过记录。

分块1

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

int n, bSize, bNum;
vector<int> a, belong, addTag;

void Add(int l, int r, int c) {
 int bl = belong[l], br = belong[r];
 if(bl == br) {
 for(int i = l; i <= r; i ++)
 a[i] += c;
 }
 else {
 for(int i = bl+1; i < br; i ++) {
 addTag[i] += c;
 }
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 a[i] += c;
 }
 for(int i = r; i > 0 && belong[i] == br; i --) {
 a[i] += c;
 }
 }
}
void solve() {
 cin >> n;
 bSize = sqrt(n), bNum = (n-1)/bSize+1;
 a.resize(n+1), belong.resize(n+1), addTag.resize(bNum+1);
 for(int i = 1; i <= n; i ++) {
 cin >> a[i];
 }
 while(n --) {
 int op, l, r, c;
 cin >> op >> l >> r >> c;
 if(op == 0) {
 Add(l, r, c);
 }
 else {
 cout << a[r] + addTag[belong[r]] << '\n';
 }
 }
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("i.txt", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

分块2

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

int n, bSize, bNum;
vector<int> a, belong, addTag;
vector<vector<int>> va;

void Resort(int x) {
 va[x].clear();
 for(int i = (x-1)*bSize+1; i <= n && belong[i] == x; i ++) {
 va[x].push_back(a[i]);
 }
 sort(all(va[x]));
}
void Add(int l, int r, int c) {
 int bl = belong[l], br = belong[r];
 if(bl == br) {
 for(int i = l; i <= r; i ++) {
 a[i] += c;
 }
 Resort(bl);
 }
 else {
 for(int i = bl+1; i < br; i ++) {
 addTag[i] += c;
 }
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 a[i] += c;
 }
 Resort(bl);
 for(int i = r; i > 0 && belong[i] == br; i --) {
 a[i] += c;
 }
 Resort(br);
 }
}
int Query(int l, int r, int c) {
 int bl = belong[l], br = belong[r];
 int ret = 0;
 if(bl == br) {
 for(int i = l; i <= r; i ++) {
 if(a[i]+addTag[bl] < c) {
 ret ++;
 }
 }
 }
 else {
 for(int i = bl+1; i < br; i ++) {
 int t = c-addTag[i];
 ret += (lower_bound(all(va[i]), t) - va[i].begin());
 }
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 if(a[i]+addTag[bl] < c) {
 ret ++;
 }
 }
 for(int i = r; i > 0 && belong[i] == br; i --) {
 if(a[i]+addTag[br] < c) {
 ret ++;
 }
 }
 }
 return ret;
}
void solve() {
 cin >> n;
 bSize = sqrt(n), bNum = (n-1)/bSize+1;
 a.resize(n+1), va.resize(bNum+1), belong.resize(n+1), addTag.resize(bNum+1);
 for(int i = 1; i <= n; i ++) {
 cin >> a[i];
 belong[i] = (i-1)/bSize+1;
 va[belong[i]].push_back(a[i]);
 }
 for(int i = 1; i <= bNum; i ++)
 sort(all(va[i]));
 for(int i = 0; i < n; i ++) {
 int op, l, r, c;
 cin >> op >> l >> r >> c;
 if(op == 0) {
 Add(l, r, c);
 }
 else {
 cout << Query(l, r, c*c) << '\n';
 }
 }
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("a2.in", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

分块3

这道题数据稍微弱了点，~~然后hzwer学长的std也假了，但是还是%%~~

std用set的erase会一次把所有的值删掉，但我们其实只删一个。

考虑用multiset，注意不要直接erase，这样也是全部一次删完，要find出来，删指针，才能删一个！

然后，时间复杂度做法1比假的set做法后面的点每个平均快100ms，multiset的时间更不忍直视（（

没有特别想清楚为什么qwq

~~留坑，如果有人知道的，可以email or qq教教我~~

做法1，同分块2的自己sort保证有序的性质

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

int n, bSize, bNum;
vector<int> a, belong, addTag;
vector<vector<int>> va;

void Resort(int x) {
 va[x].clear();
 for(int i = (x-1)*bSize+1; i <= n && belong[i] == x; i ++) {
 va[x].push_back(a[i]);
 }
 sort(all(va[x]));
}
void Add(int l, int r, int c) {
 int bl = belong[l], br = belong[r];
 if(bl == br) {
 for(int i = l; i <= r; i ++) {
 a[i] += c;
 }
 Resort(bl);
 }
 else {
 for(int i = bl+1; i < br; i ++) {
 addTag[i] += c;
 }
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 a[i] += c;
 }
 Resort(bl);
 for(int i = r; i > 0 && belong[i] == br; i --) {
 a[i] += c;
 }
 Resort(br);
 }
}
int Query(int l, int r, int c) {
 int bl = belong[l], br = belong[r];
 int ret = -1;
 if(bl == br) {
 for(int i = l; i <= r; i ++) {
 if(a[i]+addTag[bl] < c) {
 ret = max(ret, a[i]+addTag[bl]);
 }
 }
 }
 else {
 for(int i = bl+1; i < br; i ++) {
 int t = c-addTag[i];
 auto iter = lower_bound(all(va[i]), t);
 if(iter != va[i].begin()) {
 // + addTag[i]
 ret = max(ret, *(-- iter) + addTag[i]);
 }
 }
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 if(a[i]+addTag[bl] < c) {
 ret = max(ret, a[i]+addTag[bl]);
 }
 }
 for(int i = r; i > 0 && belong[i] == br; i --) {
 if(a[i]+addTag[br] < c) {
 ret = max(ret, a[i]+addTag[br]);
 }
 }
 }
 return ret;
}
void solve() {
 cin >> n;
 bSize = sqrt(n), bNum = (n-1)/bSize+1;
 a.resize(n+1), va.resize(bNum+1), belong.resize(n+1), addTag.resize(bNum+1);
 for(int i = 1; i <= n; i ++) {
 cin >> a[i];
 belong[i] = (i-1)/bSize+1;
 va[belong[i]].push_back(a[i]);
 }
 for(int i = 1; i <= bNum; i ++)
 sort(all(va[i]));
 for(int i = 0; i < n; i ++) {
 int op, l, r, c;
 cin >> op >> l >> r >> c;
 if(op == 0) {
 Add(l, r, c);
 }
 else {
 cout << Query(l, r, c) << '\n';
 }
 }
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("a2.in", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

做法2，multiset

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

int n, bSize, bNum;
vector<int> a, belong, addTag;
vector<multiset<int>> va;

void Add(int l, int r, int c) {
 int bl = belong[l], br = belong[r];
 if(bl == br) {
 for(int i = l; i <= r; i ++) {
 va[bl].erase(va[bl].find(a[i]));
 a[i] += c;
 va[bl].insert(a[i]);
 }
 }
 else {
 for(int i = bl+1; i < br; i ++) {
 addTag[i] += c;
 }
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 va[bl].erase(va[bl].find(a[i]));
 a[i] += c;
 va[bl].insert(a[i]);
 }
 for(int i = r; i > 0 && belong[i] == br; i --) {
 va[br].erase(va[br].find(a[i]));
 a[i] += c;
 va[br].insert(a[i]);
 }
 }
}
int Query(int l, int r, int c) {
 int bl = belong[l], br = belong[r];
 int ret = -1;
 if(bl == br) {
 for(int i = l; i <= r; i ++) {
 if(a[i]+addTag[bl] < c) {
 ret = max(ret, a[i]+addTag[bl]);
 }
 }
 }
 else {
 for(int i = bl+1; i < br; i ++) {
 int t = c-addTag[i];
 auto iter = va[i].lower_bound(t);
 if(iter != va[i].begin()) {
 // + addTag[i]
 ret = max(ret, *(-- iter) + addTag[i]);
 }
 }
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 if(a[i]+addTag[bl] < c) {
 ret = max(ret, a[i]+addTag[bl]);
 }
 }
 for(int i = r; i > 0 && belong[i] == br; i --) {
 if(a[i]+addTag[br] < c) {
 ret = max(ret, a[i]+addTag[br]);
 }
 }
 }
 return ret;
}
void solve() {
 cin >> n;
 bSize = sqrt(n), bNum = (n-1)/bSize+1;
 a.resize(n+1), va.resize(bNum+1), belong.resize(n+1), addTag.resize(bNum+1);
 for(int i = 1; i <= n; i ++) {
 cin >> a[i];
 belong[i] = (i-1)/bSize+1;
 va[(i-1)/bSize+1].insert(a[i]);
 }
 for(int i = 0; i < n; i ++) {
 int op, l, r, c;
 cin >> op >> l >> r >> c;
 if(op == 0) {
 Add(l, r, c);
 }
 else {
 cout << Query(l, r, c) << '\n';
 }
 }
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("a2.in", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

分块4

注意开long long吧，我是直接过程转化了，看起来可能比较难看（逃

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

int n, bSize, bNum;
vector<int> a, belong, addTag, sum;

void Add(int l, int r, int c) {
 int bl = belong[l], br = belong[r];
 if(bl == br) {
 for(int i = l; i <= r; i ++) {
 a[i] += c;
 sum[bl] += c;
 }
 }
 else {
 for(int i = bl+1; i < br; i ++) {
 addTag[i] += c;
 }
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 a[i] += c;
 sum[bl] += c;
 }
 for(int i = r; i > 0 && belong[i] == br; i --) {
 a[i] += c;
 sum[br] += c;
 }
 }
}
int Query(int l, int r, const int &MO) {
 int bl = belong[l], br = belong[r];
 int ret = 0;
 if(bl == br) {
 for(int i = l; i <= r; i ++) {
 int x = (1LL*a[i] + addTag[bl]) % MO;
 ret = (1LL*ret + x) % MO;
 }
 }
 else {
 for(int i = bl+1; i < br; i ++) {
 int x = (1LL*sum[i] + 1LL*addTag[i]*bSize%MO) % MO;
 ret = (1LL*ret + x) % MO;
 }
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 int x = (1LL*a[i] + addTag[bl]) % MO;
 ret = (1LL*ret + x) % MO;
 }
 for(int i = r; i > 0 && belong[i] == br; i --) {
 int x = (1LL*a[i] + addTag[br]) % MO;
 ret = (1LL*ret + x) % MO;
 }
 }
 return ret;
}
void solve() {
 cin >> n;
 bSize = sqrt(n), bNum = (n-1)/bSize + 1;
 a.resize(n+1), belong.resize(n+1), addTag.resize(bNum+1), sum.resize(bNum+1);
 for(int i = 1; i <= n; i ++) {
 cin >> a[i];
 belong[i] = (i-1)/bSize + 1;
 sum[belong[i]] += a[i];
 }
 for(int i = 0; i < n; i ++) {
 int op, l, r, c;
 cin >> op >> l >> r >> c;
 if(op == 0) {
 Add(l, r, c);
 }
 else {
 int MO = c+1;
 cout << (Query(l, r, c+1)%MO+MO) % MO << '\n';
 }
 }
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("i.txt", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

分块5

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

int n, bSize, bNum;
vector<int> a, belong, sum;
vector<bool> done;

void Modify(int l, int r) {
 int bl = belong[l], br = belong[r];
 if(bl == br) {
 for(int i = l; i <= r; i ++) {
 sum[bl] -= a[i];
 a[i] = sqrt(a[i]);
 sum[bl] += a[i];
 }
 }
 else {
 for(int i = bl+1; i < br; i ++) {
 if(done[i]) continue;
 done[i] = true;
 // 和n要取较小的值，循环里面i和j不要想错了qwq
 for(int j = (i-1)*bSize + 1; j <= min(i*bSize, n); j ++) {
 sum[i] -= a[j];
 a[j] = sqrt(a[j]);
 sum[i] += a[j];
 if(a[j] > 1) done[i] = false;
 }
 }
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 sum[bl] -= a[i];
 a[i] = sqrt(a[i]);
 sum[bl] += a[i];
 }
 for(int i = r; i > 0 && belong[i] == br; i --) {
 sum[br] -= a[i];
 a[i] = sqrt(a[i]);
 sum[br] += a[i];
 }
 }
}
int Query(int l, int r) {
 int bl = belong[l], br = belong[r];
 int ret = 0;
 if(bl == br) {
 for(int i = l; i <= r; i ++) {
 ret += a[i];
 }
 }
 else {
 for(int i = bl+1; i < br; i ++) {
 ret += sum[i];
 }
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 ret += a[i];
 }
 for(int i = r; i > 0 && belong[i] == br; i --) {
 ret += a[i];
 }
 }
 return ret;
}
void solve() {
 cin >> n;
 bSize = sqrt(n), bNum = (n-1)/bSize + 1;
 a.resize(n+1), belong.resize(n+1), done.resize(bNum+1), sum.resize(bNum+1);
 for(int i = 1; i <= n; i ++) {
 cin >> a[i];
 belong[i] = (i-1)/bSize + 1;
 sum[belong[i]] += a[i];
 }
 for(int i = 0; i < n; i ++) {
 int op, l, r, c;
 cin >> op >> l >> r >> c;
 if(op == 0) {
 Modify(l, r);
 }
 else {
 cout << Query(l, r) << '\n';
 }
 }
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("i.txt", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

分块6

因为是随机数据，重新分块（重构）的代码注释掉也是可以过的。

不重新分块625ms，hzwer学长提到的每$\sqrt{n}$次重构一次，是391ms，std里的看起来挺玄学的重构条件是196ms，~~分块真是玄学（逃~~

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

int n, bSize, bNum;
vector<int> a, belong;
vector<vector<int>> va;

PII Find(int x) {
 int ret = 1;
 while(x > va[ret].size()) {
 x -= va[ret].size();
 ret ++;
 }
 return {ret, x-1};
}
void Rebuild() {
 a.assign(1, 0);
 for(int i = 1; i <= bNum; i ++) {
 a.insert(a.end(), va[i].begin(), va[i].end());
 va[i].clear();
 }
 n = a.size()-1;
 bSize = sqrt(n), bNum = (n-1)/bSize + 1;
 // 理论上只要更新bSize和va，但为了一致性，这里还是都更新了
 belong.resize(n+1), va.resize(bNum+1);
 for(int i = 1; i <= n; i ++) {
 belong[i] = (i-1)/bSize + 1;
 va[belong[i]].push_back(a[i]);
 }
}
void Insert(int x, int c) {
 auto [i, b] = Find(x);
 va[i].insert(va[i].begin() + b, c);
 // if(va[i].size() > 20*bSize) {
 // Rebuild();
 // }
}
int Query(int x) {
 auto [i, b] = Find(x);
 return va[i][b];
}
void solve() {
 cin >> n;
 bSize = sqrt(n), bNum = (n-1)/bSize + 1;
 a.resize(n+1), belong.resize(n+1), va.resize(bNum+1);
 for(int i = 1; i <= n; i ++) {
 cin >> a[i];
 belong[i] = (i-1)/bSize + 1;
 va[belong[i]].push_back(a[i]);
 }
 int t = sqrt(n);
 // 由于n在重新分块时更新了，所以，这里循环询问的n要存到别的变量里面
 int nn = n;
 for(int i = 0; i < nn; i ++) {
 int op, l, r, c;
 cin >> op >> l >> r >> c;
 if(op == 0) {
 Insert(l, r);
 // if(i % t == 0) {
 // Rebuild();
 // }
 }
 else {
 cout << Query(r) << '\n';
 }
 }
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("i.txt", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

分块7

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

const int MO = 10007;

int n, bSize, bNum;
vector<int> a, belong, addTag, mulTag;

void Reset(int x) {
 for(int i = (x-1)*bSize+1; i <= min(n, x*bSize); i ++)
 a[i] = (1LL*a[i]*mulTag[x] % MO + addTag[x]) % MO;
 mulTag[x] = 1, addTag[x] = 0;
}
void Modify(int op, int l, int r, int c) {
 int bl = belong[l], br = belong[r];
 if(bl == br) {
 Reset(bl);
 for(int i = l; i <= r; i ++) {
 if(op == 0) {
 a[i] = (1LL*a[i] + c) % MO;
 }
 else {
 a[i] = 1LL*a[i]*c % MO;
 }
 }
 }
 else {
 for(int i = bl+1; i < br; i ++) {
 if(op == 0) {
 addTag[i] = (1LL*addTag[i] + c) % MO;
 }
 else {
 addTag[i] = 1LL*addTag[i] * c % MO;
 mulTag[i] = 1LL*mulTag[i] * c % MO;
 }
 }
 Reset(bl);
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 if(op == 0) {
 a[i] = (1LL*a[i] + c) % MO;
 }
 else {
 a[i] = 1LL*a[i]*c % MO;
 }
 }
 Reset(br);
 for(int i = r; i > 0 && belong[i] == br; i --) {
 if(op == 0) {
 a[i] = (1LL*a[i] + c) % MO;
 }
 else {
 a[i] = 1LL*a[i]*c % MO;
 }
 }
 }
}
int Query(int x) {
 int bx = belong[x];
 return (1LL*a[x] * mulTag[bx] % MO + addTag[bx]) % MO;
}
void solve() {
 cin >> n;
 bSize = sqrt(n), bNum = (n-1)/bSize + 1;
 a.resize(n+1), belong.resize(n+1), addTag.resize(bNum+1), mulTag.resize(bNum+1);
 for(int i = 1; i <= n; i ++) {
 cin >> a[i];
 belong[i] = (i-1)/bSize + 1;
 }
 for(int i = 1; i <= bNum; i ++) {
 mulTag[i] = 1;
 }
 for(int i = 0; i < n; i ++) {
 int op, l, r, c;
 cin >> op >> l >> r >> c;
 if(op == 2) {
 cout << Query(r) << '\n';
 }
 else {
 Modify(op, l, r, c);
 }
 }
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("i.txt", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

分块8

需要去分析分块的时间复杂度，然后大胆分块暴力。

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

int n, bSize, bNum;
vector<int> a, belong, tag;

void Reset(int x) {
 if(tag[x] == -1) return;
 for(int i = (x-1)*bSize + 1; i <= min(n, x*bSize); i ++) {
 a[i] = tag[x];
 }
 tag[x] = -1;
}
int Query(int l, int r, int c) {
 int bl = belong[l], br = belong[r], ret = 0;
 if(bl == br) {
 Reset(bl);
 for(int i = l; i <= r; i ++) {
 if(a[i] == c) {
 ret ++;
 }
 else {
 a[i] = c;
 }
 }
 }
 else {
 for(int i = bl+1; i < br; i ++) {
 if(tag[i] == c) {
 ret += bSize;
 }
 else if(tag[i] == -1) {
 // i和j分清楚。。
 for(int j = (i-1)*bSize + 1; j <= min(n, i*bSize); j ++) {
 if(a[j] == c) {
 ret ++;
 }
 }
 }
 tag[i] = c;
 }
 Reset(bl);
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 if(a[i] == c) {
 ret ++;
 }
 else {
 a[i] = c;
 }
 }
 Reset(br);
 for(int i = r; i > 0 && belong[i] == br; i --) {
 if(a[i] == c) {
 ret ++;
 }
 else {
 a[i] = c;
 }
 }
 }
 return ret;
}
void solve() {
 cin >> n;
 bSize = sqrt(n), bNum = (n-1)/bSize + 1;
 a.resize(n+1), belong.resize(n+1), tag.assign(bNum+1, -1);
 for(int i = 1; i <= n; i ++) {
 cin >> a[i];
 belong[i] = (i-1)/bSize + 1;
 }
 for(int i = 0; i < n; i ++) {
 int l, r, c;
 cin >> l >> r >> c;
 cout << Query(l, r, c) << '\n';
 }
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("i.txt", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

分块9

好多做法，都不会（

做法1 - 分块 - 预处理块区间

很容易可以判断，[L, R]的区间众数，一定是在[L, R]中一段连续的整块的众数和两边非完整块的数的并集内。

然后，我们就可以处理f[i, j]表示第 i 块到第 j 块区间的区间众数，不难发现，预处理的时间复杂度为$O(n \cdot 块数)$ ，是可以接受的，~~这实在是太神奇了！~~

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

int n, bSize, bNum;
vector<int> a, belong, cnt, val;
int nid;
map<int, int> mp;
vector<vector<int>> va, f;

void PrevCalc() {
 for(int i = 1; i <= bNum; i ++) {
 int mx = 0, res = 0;
 cnt.assign(n+1, 0);
 for(int j = (i-1)*bSize + 1; j <= n; j ++) {
 int bj = belong[j];
 cnt[a[j]] ++;
 if(cnt[a[j]] > mx || cnt[a[j]] == mx && val[a[j]] < val[res])
 mx = cnt[a[j]], res = a[j];
 f[i][bj] = res;
 }
 }
}
int Query(int l, int r, int c) {
 return (upper_bound(all(va[c]), r) - lower_bound(all(va[c]), l));
}
int Query(int l, int r) {
 int bl = belong[l], br = belong[r], ret = 0, mx = 0;
 if(bl == br) {
 for(int i = l; i <= r; i ++) {
 int t = Query(l, r, a[i]);
 if(t > mx || t == mx && val[a[i]] < val[ret]) {
 mx = t, ret = a[i];
 }
 }
 }
 else {
 ret = f[bl+1][br-1], mx = Query(l, r, ret);
 for(int i = l; i <= n && belong[i] == bl; i ++) {
 int t = Query(l, r, a[i]);
 if(t > mx || t == mx && val[a[i]] < val[ret]) {
 mx = t, ret = a[i];
 }
 }
 for(int i = r; i > 0 && belong[i] == br; i --) {
 int t = Query(l, r, a[i]);
 if(t > mx || t == mx && val[a[i]] < val[ret]) {
 mx = t, ret = a[i];
 }
 }
 }
 return val[ret];
}
void solve() {
 cin >> n;
 bSize = sqrt(n/(log(n)/log(2.0))), bNum = (n-1)/bSize + 1;
 a.resize(n+1), belong.resize(n+1), val.resize(n+1), va.resize(n+1), f.resize(bNum+1);
 for(auto &v : f)
 v.resize(bNum+1);
 for(int i = 1; i <= n; i ++) {
 cin >> a[i];
 belong[i] = (i-1)/bSize + 1;
 if(!mp.count(a[i])) {
 mp[a[i]] = ++ nid;
 val[nid] = a[i];
 }
 a[i] = mp[a[i]];
 va[a[i]].push_back(i);
 }
 PrevCalc();
 int ans = 0;
 for(int i = 0; i < n; i ++) {
 int l, r;
 cin >> l >> r;
 // l = (l+ans-1) % n + 1, r = (r+ans-1) % n + 1;;
 if(l > r) swap(l, r);
 ans = Query(l, r);
 cout << ans << '\n';
 }
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("i.txt", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

做法2 - 普通莫队 + 值域分块

数列分块入门 #9 莫队做法 - 316.2277 - 洛谷博客 (luogu.com.cn)

如果只考虑众数出现的次数，直接普通莫队维护x出现的次数和出现了x次的数有多少个就可以解决。

但现在需要输出具体的最小的数，可以用（次数）值域分块来找，用普通莫队维护$f[i, j]$，表示在第 i 个值块中恰出现 j 次的值的个数（和参考博客参数顺序不同），关于为什么是个数的话，还是为了在维护这个信息时，更加方便，其实只是为了判断是否存在恰好为 j 次的。

普通莫队维护了信息，一次查询需要$O(\sqrt{n})$

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

struct Rec {
 int l, r, qid;
};
int n, bSize, bNum, modecnt;
vector<int> a, belong, val, cnt, ccnt;
vector<vector<int>> f;
vector<Rec> query;

void add(int x) {
 x = a[x];
 int bx = belong[x], &c = cnt[x];
 ccnt[c] --;
 f[bx][c] --;
 c ++;
 if(modecnt < c) {
 modecnt = c;
 }
 ccnt[c] ++;
 f[bx][c] ++;
}
void del(int x) {
 x = a[x];
 int bx = belong[x], &c = cnt[x];
 ccnt[c] --;
 f[bx][c] --;
 if(modecnt == c && ccnt[c] == 0) {
 modecnt --;
 }
 c --;
 ccnt[c] ++;
 f[bx][c] ++;
}
int Query() {
 for(int i = 1; i <= bNum; i ++) {
 if(f[i][modecnt] > 0) {
 for(int j = (i-1)*bSize + 1; j <= min(i*bSize, n); j ++) {
 if(cnt[j] == modecnt) {
 return val[j];
 }
 }
 }
 }
 return -1;
}
void solve() {
 cin >> n;
 bSize = sqrt(n), bNum = (n-1)/bSize + 1;
 a.resize(n+1), belong.resize(n+1), val.resize(n+1), cnt.resize(n+1);
 ccnt.resize(n+1), query.resize(n), f.resize(bNum+1);
 for(auto &v : f) v.resize(n+1);
 for(int i = 1; i <= n; i ++) {
 cin >> a[i];
 belong[i] = (i-1)/bSize + 1;
 val[i] = a[i];
 }
 sort(1+all(val));
 val.resize(unique(1+all(val)) - val.begin());
 for(int i = 1; i <= n; i ++) {
 a[i] = lower_bound(1+all(val), a[i]) - val.begin();
 }
 for(int i = 0; i < n; i ++) {
 auto &[l, r, qid] = query[i];
 cin >> l >> r;
 qid = i;
 }
 sort(all(query), [&](const Rec &a, const Rec &b) {
 int abl = belong[a.l], bbl = belong[b.l];
 if(abl != bbl) {
 return abl < bbl;
 }
 else {
 if(abl & 1) return a.r < b.r;
 else return a.r > b.r;
 }
 });
 vector<int> ans(n);
 int l = 1, r = 0;
 for(int i = 0; i < n; i ++) {
 auto [ll, rr, qid] = query[i];
 while(l > ll) add(-- l);
 while(r < rr) add(++ r);
 while(l < ll) del(l ++);
 while(r > rr) del(r --);
 ans[qid] = Query();
 }
 for(auto x : ans) {
 cout << x << '\n';
 }
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("i.txt", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

做法3 - 回滚莫队

不删除莫队，状态/信息正常回滚，答案记录跳回。

 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
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109


#pragma GCC optimize(2)

#include <bits/stdc++.h>

#define fi first
#define se second
#define mkp(x, y) make_pair((x), (y))
#define all(x) (x).begin(), (x).end()

using namespace std;

typedef long long LL;
typedef pair<int, int> PII;

struct Rec {
 int l, r, qid;
};
int n, bSize, bNum, modecnt, modecntB, res, resB;
vector<int> a, belong, val, cnt, tcnt;
vector<Rec> query;

int bf(int l, int r) {
 int ret = 0, mx = 0;
 tcnt.assign(n+1, 0);
 for(int i = l; i <= r; i ++) { // tcnt
 tcnt[a[i]] ++;
 if(tcnt[a[i]] > mx || tcnt[a[i]] == mx && a[i] < ret) {
 mx = tcnt[a[i]], ret = a[i];
 }
 }
 return val[ret];
}
void add(int x) {
 x = a[x];
 cnt[x] ++;
 if(cnt[x] > modecnt || cnt[x] == modecnt && x < res) {
 modecnt = cnt[x], res = x;
 }
}
void del(int x) {
 x = a[x];
 cnt[x] --;
}
void solve() {
 cin >> n;
 bSize = sqrt(n), bNum = (n-1)/bSize + 1;
 a.resize(n+1), belong.resize(n+1), val.resize(n+1);
 cnt.resize(n+1);
 for(int i = 1; i <= n; i ++) {
 cin >> a[i];
 belong[i] = (i-1)/bSize + 1;
 val[i] = a[i];
 }
 sort(1+all(val));
 val.resize(unique(1+all(val)) - val.begin());
 for(int i = 1; i <= n; i ++) {
 a[i] = lower_bound(1+all(val), a[i]) - val.begin();
 }
 query.resize(n);
 n = 0;
 for(auto &[l, r, qid] : query) {
 cin >> l >> r;
 qid = n ++;
 }
 sort(all(query), [&](const Rec &a, const Rec &b) {
 int abl = belong[a.l], bbl = belong[b.l];
 return abl == bbl ? a.r < b.r : abl < bbl;
 });

 vector<int> ans(n);
 for(int bid = 1, id = 0; bid <= bNum; bid ++) {
 int tp = min(bid*bSize, n), l = tp+1, r = tp;
 res = modecnt = 0;
 cnt.assign(n+1, 0);
 for( ; id < n && belong[query[id].l] == bid; id ++) {
 auto [ll, rr, qid] = query[id];
 int bll = belong[ll], brr = belong[rr];
 if(bll == brr) {
 ans[qid] = bf(ll, rr);
 }
 else {
 while(r < rr) add(++ r);
 modecntB = modecnt, resB = res;
 while(l > ll) add(-- l);
 ans[qid] = val[res];
 while(l < tp+1) del(l ++);
 modecnt = modecntB, res = resB;
 }
 }
 }
 for(auto x : ans) {
 cout << x << '\n';
 }
}

int main() {
 ios::sync_with_stdio(false);
 cin.tie(nullptr);
 cout << fixed; // << setprecision(20); // double
 // freopen("i.txt", "r", stdin);
 // freopen("o.txt", "w", stdout);
 // time_t t1 = clock();
 int Tcase = 1;
 // cin >> Tcase; // scanf("%d", &Tcase);
 while (Tcase--)
 solve();
 // cout << "time: " << 1000.0 * ((clock() - t1) / CLOCKS_PER_SEC) << "ms\n";
 return 0;
}

Python多线程实现的选择与QThread的推荐实现方式

Wed, 15 Feb 2023 00:00:00 +0800

旧文

前言

因为在网络上，特别是中文互联网上，关于Pyside6多线程的写法，特别是QThread的使用提及比较少，且较多使用不太推荐的写法，这篇博客主要是存下我自己参考的博客，希望对大家也有帮助。

一、QThread or Python libs[thread, process, …]

在python中有多种实现多线程的方法，我一开始也纠结选哪种实现方式

在Stack Overflow的这篇回答中，可以大致窥得答案：QThread在Qt开发中一体性会更好，其他差别不大。

补充资料

有位大佬写的【QT】 Qt多线程的“那些事” ，虽然是Qt C++，但是也可以帮助了解Qt for Python。

二、QThread推荐实现方式 - moveToThread

在确定使用QThread后，发现QThread - Qt for Python 官方文档写得很一般，甚至给的example都不堪入目。

我在Stack Overflow的文章找到Pyqt5注释详细的实现，Pyside6的实现也就很类似，也很可以帮助理解QThread的建立过程，以及在Python多线程之threading.Thread()基本使用和QT信号和槽在哪个线程执行问题的博客中，可以进一步浅尝实现的区别。

Stack Overflow文章的原文以及给出的代码实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Take this answer updated for PyQt5, python 3.4

Use this as a pattern to start a worker that does not take data and return data as they are available to the form.

1 - Worker class is made smaller and put in its own file worker.py for easy memorization and independent software reuse.

2 - The main.py file is the file that defines the GUI Form class

3 - The thread object is not subclassed.

4 - Both thread object and the worker object belong to the Form object

5 - Steps of the procedure are within the comments.

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76


# worker.py
from PyQt5.QtCore import QThread, QObject, pyqtSignal, pyqtSlot
import time


class Worker(QObject):
 finished = pyqtSignal()
 intReady = pyqtSignal(int)


 @pyqtSlot()
 def procCounter(self): # A slot takes no params
 for i in range(1, 100):
 time.sleep(1)
 self.intReady.emit(i)

 self.finished.emit()


# main.py
from PyQt5.QtCore import QThread
from PyQt5.QtWidgets import QApplication, QLabel, QWidget, QGridLayout
import sys
import worker


class Form(QWidget):

 def __init__(self):
 super().__init__()
 self.label = QLabel("0")

 # 1 - create Worker and Thread inside the Form
 self.obj = worker.Worker() # no parent!
 self.thread = QThread() # no parent!

 # 2 - Connect Worker`s Signals to Form method slots to post data.
 self.obj.intReady.connect(self.onIntReady)

 # 3 - Move the Worker object to the Thread object
 self.obj.moveToThread(self.thread)

 # 4 - Connect Worker Signals to the Thread slots
 self.obj.finished.connect(self.thread.quit)

 # 5 - Connect Thread started signal to Worker operational slot method
 self.thread.started.connect(self.obj.procCounter)

 # * - Thread finished signal will close the app if you want!
 #self.thread.finished.connect(app.exit)

 # 6 - Start the thread
 self.thread.start()

 # 7 - Start the form
 self.initUI()


 def initUI(self):
 grid = QGridLayout()
 self.setLayout(grid)
 grid.addWidget(self.label,0,0)

 self.move(300, 150)
 self.setWindowTitle('thread test')
 self.show()

 def onIntReady(self, i):
 self.label.setText("{}".format(i))
 #print(i)

 app = QApplication(sys.argv)

 form = Form()

 sys.exit(app.exec_())

下面是我自己再写的实现

 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
26
27
28
29
30


class Worker(QObject):
 ready = Signal()
 # 貌似finished信号，Qt自己有定义(?)
 finished = Signal()
 def __init__(self):
 super().__init__()
 def DoWork(self):
 # 或者设置一个变量作为是否停止的标准，然后用某一个槽函数修改它即可
 while True:
 # print('hello, QThread')
 self.ready.emit()
 self.finished.emit()

class ...:

 def __init__(self):
 super(..., self).__init__()

 self.worker = Worker()
 self.workerThread = QThread()
 self.worker.moveToThread(self.workerThread)

 self.workerThread.started.connect(self.worker.DoWork)
 self.worker.finished.connect(self.workerThread.quit)
 self.worker.ready.connect(self.xxx)

 self.workerThread.start()

 def xxx(self):
 pass

其他小问题

中途有遇到将信号(Signal)在实例(self)上定义是不行的错误。

在关于python：’PySide.QtCore.Signal’对象没有属性’connect’ 末尾有提到，需要将信号(Signal)定义在类(class)上。

UPD - 2023.2.15

根据一些文章的对最终槽函数在哪个线程运行的分析，应该还是把要运行的槽函数定义在Worker类里的样子，关于UI的修改是要在主线程中进行。

实现简单计算器

Sun, 12 Feb 2023 00:00:00 +0800

旧文

开发环境

Python3.10, Pyside6

使用界面、源码与不同之处

abCalculator

界面没有很不一样，不同可能体现在键位上。

为了有与优秀的小键盘来计算一样的舒适，在保留原有普通键位的基础上，还增加了魔改键位（详见Github）

遇到的问题与解决方案

具体实现都见Github源码

keyboard添加热键，把快速连续按不同的热键，识别成新的热键，导致输入缓慢
- 一个热键触发后，采用keyboard.stash_state()清空
当前窗口为未活跃状态（不是系统聚焦的窗口），热键仍响应
- [创建的窗口实例/self].window().isActiveWindow()和[创建的窗口实例/self].window().isMinimized()可以判断窗口是否活跃
- 热键调用的函数用匿名函数lambda，匿名函数内再调用一个函数，加入条件判断后，再执行我们需要的函数
输出过长，导致窗口显示不下
- 把实际的内容和显示的内容分开想，我这里采用只取实际内容的后十几位作为显示内容
- 或可以采用QLineEdit，加上样式background:transparent;border-width:0;border-style:outset;
- 亦可以采用QtQuick

其他

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# PySide6-uic DemoUI.ui -o DemoUI.py
# from DemoUI import DemoUI

# self.ui.__Action__.triggered.connect(__Function__)
# Button clicked
# ComboBox currentIndexChanged
# SpinBox valueChanged
# 自定义函数.属性名.connect

# 此窗口是否活跃
# self.window().isActiveWindow()
# self.window().iMinimized()

Python实现东方Project图片爬虫

Fri, 15 Jul 2022 00:00:00 +0800

本篇文章为旧文

视频流程讲解

（咕咕咕中）

背景

当时，在乱搞网站时候，它的默认随机图比较少，心生一念，我自己爬虫爬点下来不就有了？

昨日，爬了ewt后，思绪继续随着时间线向前延伸，想起来要爬图片了！（虽然我现在发现，我大部分文章都会自己发的时候找好配图，随机图好像没大用处？？）

另外，因本人技术力有限，无法标明作者，十分抱歉。

ps.只是爬了30页，懒得爬更多了，同时也为了避免不必要的影响。

运行结果预览

贴一下爬下来的图片吧（不能保证质量哦QnQ）

小咕一手 upd. 被迫咕，度娘云链接秒挂……

运行要求

本代码编写在python3.10版本（不确定低版本会不会有问题）
requests
xpath - lxml库

代码

 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
26
27


import requests
from lxml import etree

# https://wall.alphacoders.com/by_sub_category.php?id=174892&name=%E4%B8%9C%E6%96%B9+%E5%A3%81%E7%BA%B8&filter=4K+Ultra+HD&lang=Chinese&quickload=880+&page=1

base_url = 'https://wall.alphacoders.com/by_sub_category.php?id=174892&name=%E4%B8%9C%E6%96%B9+%E5%A3%81%E7%BA%B8&filter=4K+Ultra+HD&lang=Chinese&quickload=880+&page='

index = 0

for page in range(1,31):
 print('正在爬取第'+str(page)+'页')
 url = base_url+str(page)
 # //img[@class="img-responsive big-thumb thumb-desktop"]/@src
 response = requests.get(url=url)
 content = response.text
 # print(content)
 tree = etree.HTML(content)
 img_li = tree.xpath('//img[@class="img-responsive big-thumb thumb-desktop"]/@src')
 for img_url in img_li:
 print('正在爬取第'+str(index)+'张')
 img_response = requests.get(url=img_url)
 img_content = img_response.content
 index += 1
 # print(img_url)
 extension = '.'+img_url.split('.')[-1]
 with open('.\\touhou_pic\\'+str(index)+extension,'wb')as fp:
 fp.write(img_content)

经验教训

爬虫的过程还是要输出的，不知道爬到哪里而不敢轻举妄动的感觉不好受诶。TnT

因为网站随机图加载的速度还是蛮重要的，在合理范围内应当小一点图片大小。