DeepSeek总结的使用实体-组件-系统和基于存在性处理进行Python编程31-32

31 — 不相交的写集合可自由并行化

当且仅当两个系统的写集合不重叠时，它们可以并行运行。这就是规则。它很小。这就是第 25 节的单写入者所有权为你带来的好处。

具体来说：在模拟器的滴答中，motion写入pos_x、pos_y、energy；food_spawn写入food。它们的写集合是不相交的。它们可以在两个不同的进程上运行，无需协调——无需锁、无需原子操作、无需消息传递。数据布局使并行性变得免费。

同样的形态在更细粒度上也适用。模拟器的三个应用器（apply_eat、apply_reproduce、apply_starve）都读取pending_event并写入不相交的东西——apply_eat写入food、to_remove；apply_reproduce写入to_insert；apply_starve写入to_remove。其中两个追加到同一个缓冲区。为了并行化它们，给每个进程分配自己的to_remove段（每个进程一段），然后在清理时合并。合并是np.concatenate——在合并后的总大小上是 O(N)，相对于产生它的工作来说是免费的。

不是线程。不是 asyncio。

这是 GIL 问题最终落地的章节。当一章提到“并行”时，Python 的第一反应是使用threading.Thread或asyncio。对于 CPython 中的 CPU 密集型并行工作，这两种都是错误的。

threading不能给你并行的 CPU。全局解释器锁（GIL）序列化了 Python 字节码的执行：无论你启动了多线程，一次只能有一个线程运行 Python 代码。Numpy 批量操作在其 C 级别的工作期间会释放 GIL，因此运行arr.sum()的threading.Thread可以与另一个执行相同操作的线程重叠——但仅在sum()的 C 调用期间，而不是在它周围的任何 Python 代码期间。对于主要由 numpy 操作的 Python 编排组成的工作负载，线程充其量只能带来微不足道的加速。

asyncio是一个用于 I/O 密集型工作的调度器。CPU 密集型系统没有给它任何可以重叠的东西。事件循环增加了分派开销，没有移除任何东西。

规范的替代方案是multiprocessing加上shared_memory。__main__在共享内存区域中分配世界的列。工作进程附加到该区域，获得指向相同字节的 numpy 视图，并仅写入他们的切片。没有跨进程边界的复制；字节是共享的。GIL 不再起作用，因为每个进程都有自己的 GIL，并且每个进程都在自己的分区上进行纯 C 级别的 numpy 工作。

形态（完整版本在code/measurement/parallel_motion.py中）：

# 工作进程全局变量——由 Pool 初始化器为每个工作进程设置一次。_arr=None_shm=Nonedefinit_worker(shm_name:str)->None:global_arr,_shm _shm=shared_memory.SharedMemory(name=shm_name)_arr=np.ndarray(SHAPE,dtype=DTYPE,buffer=_shm.buf)# _arr 现在与 __main__ 的数组共享相同的字节。defworker(args:tuple[int,int])->None:start,end=args# 每个工作进程仅写入其切片；写入通过 numpy 视图直接进入共享字节——无复制。_arr[0,start:end]+=_arr[1,start:end]*DT# 在 __main__ 中：shm=shared_memory.SharedMemory(create=True,size=arr.nbytes)arr=np.ndarray(SHAPE,dtype=DTYPE,buffer=shm.buf)# ... 用世界的数据填充 arr ...boundaries=[(i*chunk,(i+1)*chunk)foriinrange(n_workers)]withPool(processes=n_workers,initializer=init_worker,initargs=(shm.name,))aspool:pool.map(worker,boundaries)

形态：__main__拥有内存；工作进程通过init_worker附加并持有指向共享字节的 numpy 视图；每个工作进程仅写入其切片；没有共享写入，没有锁，没有消息传递。

它的成本和收益

根据code/measurement/parallel_motion.py，在这台机器（8 个物理核心，16 个带 SMT 的逻辑核心）上，对 10,000,000 个float32生物应用 100 次的两种工作负载：

工作负载 A——内存受限（pos += vel * dt）：每个元素访问 12 字节，2 次算术运算。内存流量占主导地位。

工作负载 B——计算受限（out += sin(x)**2 + cos(x)**2）：相同的字节访问，每元素 CPU 工作量大得多。

三种解读。

1 个工作进程与串行匹配。池的往返成本在整个运行中被摊销，因为该装置每次测量只分派一次（每个工作进程在返回之前在其分区上运行所有 100 个滴答）——每滴答分派会在其基础上增加 IPC 开销，进一步限制加速比。参见练习 6。

内存受限的加速比上限约为 4 倍。这是这台机器上的总内存带宽上限。76 MB 的工作集溢出了 L3；一旦两个核心全速读写，DRAM 总线就繁忙了。添加第三个或第四个物理核心略有帮助（一些带宽来自核心自己的 L1/L2），但超过这个数量，更多的工作进程会竞争相同的带宽。上限由内存子系统设定，而不是核心数。在具有更多内存通道的芯片上（服务器 CPU、现代四通道 DDR5 台式机），上限更高；在单通道笔记本电脑或树莓派上，上限更低。

计算受限的加速比上限约为 5.5 倍，在 8 到 16 个工作进程之间出现平台期。平台期的位置与物理核心数（这里为 8）相匹配；SMT 加倍后的 16 个逻辑核心基本没有增加任何东西，因为同一个核心上的两个线程现在争用相同的算术单元。计算密集型工作接近物理核心数进行扩展；SMT 有助于存在间隙（主要是内存停顿等待）可以由第二个线程填充的工作，而纯计算没有间隙可以填充。

这两个上限是因不同原因而呈现的不同形态。测量你的特定工作负载——两者都不是“错误的”，它们是不同的瓶颈。

这条规则为你做的三件事

无锁。锁是由被锁对象的每个读者和写者支付的税。有了单写入者所有权，锁是不必要的；由于跨进程的写集合是不相交的，它们在并行边界处仍然是不必要的。在此规模下，模拟器的内部系统有零个Lock、零个RLock、零个Semaphore。一旦架构正确，你在教程中看到的整个并发原语词汇表就不适用了。

加速比是结构性的，而不是承诺的。N 个具有不相交工作的进程会提供接近 N 倍的加速比，直到瓶颈转移。内存受限的工作首先达到带宽上限；计算受限的工作耗尽物理核心；每滴答分派达到 IPC 开销。这些上限是真实且可测量的；它们不是避免该架构的理由，只是知道你的工作负载会碰到哪个上限的理由。

无需繁琐设置的工具。Python 生态系统的标准工具——multiprocessing.Pool、concurrent.futures.ProcessPoolExecutor、multiprocessing.shared_memory——都是标准库的一部分。没有第三方 crate，没有外部服务，没有编排器。parallel_motion.py中的装置大约 150 行。为你的模拟器构建一次；到处重用。

单写入者规则（第 25 节）是先决条件。不相交的写集合是应用于多个系统的规则。两者结合，并行性就变成了调度决策，而不是设计决策。

校准说明

Python 的多进程处理并不简单。上面整洁的加速比表隐藏了真正的复杂性：进程边界处的 pickle 开销、因平台而异的 fork-vs-spawn 语义、信号处理、队列争用、当出现问题时跨 N 个进程边界推理系统的困难。本章没有说谎——该架构确实有效，加速比是真实的——但它展示了架构而没有考虑操作成本。

本章教授原则，而不是生产配方。单写入者所有权、不相交写集合、分区而非锁定、共享内存而非 pickle：这些在任何规模下都是正确的。当你的滴答舒适地高于 IPC 下限（≥ 每滴答约 16 毫秒，分区 ≥ 100K 元素）时，Python 多进程处理是这些原则的一个不错实现。当每一百分比都重要时——1 kHz 的物理引擎、实时控制循环、任何操作复杂性高于编译语言不会付出的预算的东西——它就不再合适了。

升级顺序很短：numpy → maturin → 离开 Python。Maturin（Rust + PyO3）为你提供相同的并行架构，而没有 Python 编排税——内部循环、分派和数据都在编译后的 Rust 中，通过一个薄绑定暴露给 Python。超越 maturin，答案不是添加另一个 Python 端的库；而是完全离开 Python，用 Rust 编写应用程序。Rust 标准库对于大多数并行工作来说已经足够；你不需要伸手去拿一个并行迭代 crate 来做好这件事。

从头开始，然后评估 crate 的成本（第 41 节，第 42 节）也适用于此：先在 Python 中构建它以感受架构；当预算紧张时，评估下一级能给你带来什么。本书教授架构；语言是工具决策。

练习

你需要一台多核机器。大多数台式机和笔记本电脑都符合要求。

1. 运行装置。uv run code/measurement/parallel_motion.py。阅读你的加速比列。找到曲线变平的工作进程数——那是你的带宽上限。
2. 线程方法表现不佳。使用threading.Thread而不是multiprocessing.Pool重写parallel_motion。保持相同的分区模式。对其计时。加速比是真实的，但更小（numpy 在批量操作期间释放 GIL，因此线程可以在*= dt步骤期间重叠，但不会在其他任何步骤重叠）。与多进程版本进行比较。
3. 一个失败的案例。尝试让 motion 和apply_eat系统并行运行，两者都写入energy。没有单写入者规范，两个写入同一共享内存区域的进程会产生未定义行为。构建这个案例；观察数据损坏（它可能是静默的——那就是失败模式）。
4. 每进程段。修改装置，使得不是运行 motion，而是每个工作进程运行apply_starve并产生自己的to_remove段作为单独的共享内存数组。在所有工作进程完成后，在__main__中使用np.concatenate合并这些段。验证合并后的结果与单进程运行的结果相同。
5. 找到带宽上限。在 N = 100,000（适合 L2）、N = 1,000,000（适合 L3）、N = 10,000,000（溢出到 RAM）、N = 100,000,000（深度 RAM 驻留）下运行装置。绘制内存受限的加速比与 N 的关系图。带宽上限的工作进程数随 N 变化——小 N 带宽丰富（每核心缓存），大 N 带宽受限。
6. 每滴答分派成本（IPC）。修改装置，使得每次pool.map调用每个工作进程只运行一个滴答，而不是一次调用运行全部 100 个滴答。重新运行。加速比曲线将在更低的位置达到平台期（在这台机器上，内存受限约为 3-4 倍，计算受限约为 4-5 倍），因为每个滴答现在都要支付一次 IPC 往返。教训：当访问模式允许时，进行批处理。每次调用的成本很小，但合计起来很可观。
7. 找到你的物理核心数。lscpu | grep 'Core(s) per socket'（Linux）。与os.cpu_count()进行比较。计算受限的上限接近物理核心数，而不是逻辑核心数。
8. （挑战）concurrent.futures比较。使用concurrent.futures.ProcessPoolExecutor.map重写装置。确认性能相当。两者基本上可以互换；选择你的团队更喜欢其 API 的那个。
9. （挑战）一个纯 Python 的反比较。将相同的运动系统实现为每个生物的 Python 循环（for i in range(N): pos[i] += vel[i] * dt）。串行运行它。使用 8 个线程在threading.Thread下运行它。使用 8 个工作进程在multiprocessing.Pool下运行它。注意：线程版本不比串行快（GIL），多进程版本更快，但仍然比批量 numpy 串行版本慢，因为批量 numpy 版本已经比任何纯 Python 形式快。多进程处理扩展了已经很快的工作；它不能拯救形态错误的工作。

接下来是什么

第 32 节——分区，不要锁定 采取下一步：当一个系统必须从多个进程写入单个表时，你分割表，而不是访问。

32 — 分区，不要锁定

第 31 节 说“不相交的写集合可自由并行化”。如果系统必须从许多进程写入一个表呢？1M 生物时的运动想要更新每个生物的pos_x和pos_y；表只有一个。八个进程，一个表——看起来像是需要锁的情况。

不是。解决办法是对数据进行分区，而不是锁定访问。

每个进程占用表的一个切片。进程t写入槽位t * N/8 .. (t+1) * N/8且只写这些槽位。这些切片在构造上是不相交的；没有一个进程可以在另一个进程正在写入的地方写入。在每个切片内部，单个进程是写入者——第 25 节的所有权规则仍然成立，只是在切片级别而不是表级别。Numpy 对共享内存的切片为每个工作进程提供了相同底层字节的非重叠视图。没有Lock、没有Semaphore、没有原子操作。字节在物理上被分区；写入不会冲突。

这是本章的一半。另一半是第 31 节未解决的问题：主进程首先是如何与工作进程协调的？

协处理器受 IOPS 限制

一个工作进程是一个可以工作的 CPU，但只有在主进程告诉它做什么之后。告诉一个工作进程一些事情——发送消息、释放屏障、将任务放入队列——是有成本的，而这个成本是主进程能让工作进程保持忙碌的速度的硬性上限。根据code/measurement/coordination_patterns.py，在这台机器上（8 个物理核心，7 个工作进程 + 1 个主进程，每个模式 20,000 轮 × 7 个工作进程 = 140,000 次往返）测量的三种协调模式：

三种解读。

模式 1 和 2——都基于multiprocessing.Queue——最高大约在 6万-9 万 消息/秒。这是“每次 put 一次内核调用，每次 get 一次内核调用，每条消息一次 pickle”的底线。这不是“Python 慢”；而是“任何通过内核的东西成本约为 10 微秒，并且每个任务一次往返，每个工作进程每秒获得 10 万个任务，并且 7 个工作进程不会倍增，因为主进程是瓶颈。”

在这里，每工作进程队列比单个共享队列更慢，这是本章的第一个意外。教科书中的争用论点（“通过给每个工作进程自己的队列来避免锁争用”）是真实的，但在这个工作负载规模下，主导成本是主进程的串行调用——每轮每个工作进程一次q.put()，七次内核转换，而不是七次入队到一个单一队列。争用会在更高负载或更多工作进程时变得重要；在模拟器的每滴答规模下，流水线化才是关键。

共享 numpy 数组以每秒 147 万条消息的速度运行——比单个队列快 17 倍，抖动小两个数量级（p99 为 0.6 微秒 vs 92 微秒）。没有内核参与：主进程向共享数组写入一个代次计数器，工作进程自旋读取该数组，完成工作，增加它们的确认计数器。唯一的同步是 x86 在对齐的 64 位读写上的正常缓存一致性。这是在这台机器上进行进程内 Python 协调的 IOPS 上限。

批处理由物理定律强制要求

将 IOPS 上限转换到模拟器的滴答预算。在 30 Hz 时，预算是 33 毫秒。使用共享数组模式以 150 万 消息/秒的速度，那是每秒约 50,000 个协调事件。使用基于队列的模式以约 9万 消息/秒的速度，那是每秒约 3,000 个事件。

将其与一个拥有 1,000,000 个生物、20 个系统的模拟器可能的工作形态进行比较：

前两个不在考虑范围内。第三个是模拟器实际做的事情。批处理不是一种优化；它是由 IOPS 上限强制要求的。不能告诉一个工作进程“处理这个单个生物”，然后“处理下一个单个生物”，因为告诉的速度比处理慢得多。可以告诉一个工作进程“处理你的那部分生物表”一次，然后它在主进程需要再次告诉它之前做了 100,000 个生物的工作。

一旦批处理被强制要求，分区就是自然的批处理形态。每个批次是表的一个切片。每个工作进程在多个滴答中拥有自己的切片。协调消息是“在你的切片上运行这个系统”——足够短，可以适应上述三种模式中的任何一种，即使是最慢的那种。

通风机模型

将这些部分组合在一起，就得到了“分区，不要锁定”的生产质量形式：

主进程拥有滴答时钟、I/O 队列、共享内存数组和系统 DAG。它不在每滴答分配内存；缓冲区在启动时已设定大小。

工作进程（nprocs - 1）每个都持有它们预先分配的分区（槽位[my_id * chunk, (my_id+1) * chunk)）以及指向共享内存的 numpy 视图。它们等待来自主进程的信号，在其切片上运行指示的系统，发出完成信号。工作进程也不在每滴答分配内存。

信号携带系统索引，而不是数据。一个工作进程已经知道它拥有世界的哪个切片；主进程只需要告诉它在这个阶段运行哪个系统。模拟器的二十个系统变成了二十个小整数——一个告诉工作进程“在你的分区上运行运动”，另一个告诉它“在你的分区上运行 apply_starve”，依此类推。

DAG 本身，编码为一个共享数组，变成：

阶段 1: [1] # 一个系统运行（此阶段无并行） 阶段 2: [1, 2, 3, 4, 5, 6] # 6 个系统并行 阶段 3: [1, 2, 3, 4, 5] # 一个系统的 5 个分区 阶段 4: [1, 2, 3] # 3 个分区 阶段 5: [1, 2, 3] # 3 个系统 阶段 6: [1] # 清理 阶段 7: [1] # 检查（如果设置了 --debug）

将其读作一系列阶段。在一个阶段内，条目是哪个工作进程运行此任务；阶段之间有一个屏障（主进程在增加代次计数器之前等待所有确认）。

作为线性序列的 DAG，按阶段切片

一个滴答是一个有序的原子任务序列，被分区成阶段。每个原子任务是一个（系统，分区）对。阶段边界是屏障——阶段 N 中的所有任务必须在阶段 N+1 中的任何任务开始之前完成，因为 DAG 编码了数据依赖关系（第 14 节）。

在一个阶段内部，工作是独立的，并且可以在主进程可用的任意多的工作进程上运行。

切片问题变得具体：你如何切割原子任务的线性序列，使得 DAG 被遵守（阶段边界变成屏障），并且鉴于上面表格中测量的抖动，在每个阶段内，工作尽可能平均地分布在可用工作进程上？

DAG 的结构是永久性的——哪些系统存在，哪些依赖于哪些——并在设计时固定。每个滴答变化的是每个系统产生的工作量。在一款 MMORPG 中，繁忙城市中 NPC 的数量在 AI 系统中要求更多工作；战场上要求在群体协调中更多工作。相同的 DAG 以相同的阶段运行；每个阶段内部工作的分区发生变化。

主进程的工作是观察和重新平衡：上个滴答每个阶段花了多长时间，考虑到上面测量的每工作进程抖动，这个滴答应该如何分配分区以均匀地分散工作？

在 30 Hz 下的负载均衡

30 Hz 滴答是 33 毫秒。共享数组协调往返的 p99 时间低于微秒。主进程有充足的空间——毫秒，而不是微秒——根据它上个滴答观察到的结果，在每个滴答重新分配分区。

模式：每个阶段，每个工作进程在共享数组中标记其完成时间戳（示例中的COORD_TIMESTAMP槽位）。主进程读取时间戳，计算每个工作进程的阶段墙钟时间，并为下一个滴答调整分区边界。一个提前完成的工作进程下次获得稍大的切片；一个延迟完成的工作进程获得稍小的切片。DAG 数组还可以调整有多少工作进程参与一个阶段——一个只需要三个工作进程的短阶段会释放其他四个，让它们提前开始下一个阶段。

这是对滴答预算的闭环控制。主进程观察；主进程决定；主进程在下一次滴答触发之前写入新的分区边界。分区不是一个静态决策；它是主进程维护的一个量，就像模拟器状态的其他部分一样。

选择分区的形态

在通风机模型内部，初始分区形态仍然是一个设计选择。值得命名的四种选项：

按实体范围（默认）：每个工作进程取连续的槽位范围[i*N/W, (i+1)*N/W)。简单；当访问均匀时有效。

按空间单元格（在为局部性排序之后，第 28 节）：每个工作进程占据世界的一个区域。当交互是局部时有用——仅邻居碰撞、区域行为。在边界单元格的工作进程需要一个小的同步步骤（或将一个光环区域复制到每个工作进程的输入中）。

按哈希：每个工作进程取hash(id) % n_workers与其索引匹配的 ID。当访问均匀，但希望跨滴答保持工作进程到数据的稳定映射时有用（工作进程的缓存滴答滴答地在同一分区上保持热）。

按工作负载权重（上述负载均衡形式）：每个工作进程获取的行数由每行预期工作加权。上面的 30 Hz 观察-再平衡循环动态地实现了这一点。

分区形态是设计选择；分区机制——对共享内存进行 numpy 切片——是一行代码。

校准

本章在架构层面涵盖了很广的范围。三个诚实的条件。

共享数组模式是原则，而不是配方。示例中的模式有效；它很快；在负载下调试也相当复杂。生产实现通常使用multiprocessing.shared_memory加上multiprocessing.Event进行唤醒（而不是忙循环），以便对机器上的其他进程更友好。IOPS 上限从 150 万下降到使用 Event 时的约 50 万，这仍然比队列模式快 5-10 倍。

Python 多进程处理仍然不简单。正如第 31 节的校准说明所说：这教授的是架构，而不是针对每一百分比都很重要的工作负载的生产配方。单写入者、分区而非锁定、批处理协调的架构在任何规模下都是正确的。如果你的滴答预算无法承受跨 N 个 Python 进程调试的操作复杂性，那么答案是升级到 maturin（Rust + PyO3），并在编译后的代码中应用相同的架构。

真正的 ECS 引擎在编译代码中执行此操作。Bevy、Unity DOTS、Unreal Mass Entities——它们各自在 C++ 或 Rust 中实现了通风机模型的变体。该架构确实是正确的形态；语言是工具决策。

练习

1. 运行协调示例。uv run code/measurement/coordination_patterns.py。阅读你的三个速率。为每个模式计算“每 30 Hz 滴答的协调事件数”。共享数组的数字是你用于任何每滴答编排的预算。
2. 你机器上的批处理阈值。使用你的 IOPS 数字，计算使协调成本 ≤ 分区工作成本的 10% 的最小分区大小。低于该阈值，批处理是唯一的选择。高于它，你可以负担得起每某物分派的成本。
3. 预先分配的分区。修改你的模拟器，使得每个工作进程在启动时持有其(start, end)一次，之后不再接收。它在每个阶段收到的信号是一个小整数（系统 ID）。将墙钟时间与每个阶段重新发送(start, end)的版本进行比较。差异是节省的边际 IPC。
4. 作为数组的 DAG。构建一个长度为 20 的int8numpy 数组，代表你模拟器的 DAG（每个阶段的系统 ID，阶段之间的分隔符）。让工作进程在这个数组上自旋等待。对照单进程基线确认正确性。
5. 负载均衡分区。在每个阶段后添加每工作进程时间戳（COORD_TIMESTAMP槽位模式）。在每个滴答后，按比例根据每工作进程阶段时间重新计算分区边界。运行 1000 个滴答；观察边界随着工作负载稳定而收敛。
6. 工作负载异构性。构建一个工作负载，其中 80% 的工作存在于 20% 的分区中（例如，一个 MMORPG 城市主导了一个平坦的世界）。比较固定大小的分区与练习 5 中的负载均衡分区。负载均衡版本应该收敛到大小不等的切片，这些切片都在大致相同的墙钟时间内完成。
7. 边界构建器存在于__main__中。编写一个工作进程，它从(my_id, n_workers, N)计算自己的切片。运行它。现在在滴答中间从__main__更改N并观察混乱。确认规范形式（边界在__main__中计算一次）没有这种失败模式。
8. （挑战）使用Event代替忙等待。将共享数组工作进程中的自旋循环替换为multiprocessing.Event.wait()。测量新的吞吐量。权衡：空闲时 CPU 使用率更低，每往返延迟略高。
9. （挑战）1 kHz 物理引擎问题。计算 1 kHz（1 毫秒）下的每滴答预算。计算在该预算中可以容纳多少共享数组协调事件。在什么工作进程数量下，协调开销变得无法承受？这种算术决定了你的物理引擎是留在 Python 多进程中还是升级到 maturin。

接下来是什么

第 33 节——伪共享 命名了可能使分区模式失效的硬件级陷阱：两个进程写入同一缓存行中的不同字节，尽管逻辑上独立，但会互相拖慢速度。