turbovec 在线索引变更路径性能爬山实录从 WHM x1.0273 到 x1.6441 的五个假设与验证【免费下载链接】turbovecA vector index built on TurboQuant, written in Rust with Python bindings项目地址: https://gitcode.com/GitHub_Trending/tu/turbovec导读本文完整还原 turbovec 仓库中一次针对**在线索引变更live-index mutation**路径的系统性能优化过程benchmarks/hillclimb/LOG_mutate.md记录了一次爬山式hill-climb调优战役——对批量插入bulk、追加append、单条添加single与删除remove四类操作在 ARM/x86 双架构下的加权调和均值WHM进行迭代优化。文章将逐一剖析从失败假设 H1 到被搁置的 H5 共五个假设的提出依据、实现思路、测量结果与最终裁决并结合turbovec核心源码编码管线、IdMapIndex实现、Python 绑定层讲解每个优化点背后的真实调用链。读完你将掌握这套先 smoke 后 soak、正确性不妥协的优化方法论以及 turbovec 在绑定层/内核层的热点分布与性能瓶颈的真实形态。目标与规则什么是变更路径爬山benchmarks/hillclimb/GOAL_mutate.md定义了本次优化的目标函数最大化八个单元{arm, x86}×{bulk, append, single, remove}相对基线pinned baseline加速比的加权调和均值WHM其中bulk权重 2、append权重 2、single权重 1、remove权重 2remove单元本身取swap_remove与IdMapIndex.remove两个子操作加速比的算术平均。规则极其严格任何一条不满足即判假设失败单线程不得回退每个胜利必须同时在RAYON_NUM_THREADS1下单线程ST成立ST 回退等同于假设失败而非可接受的权衡正确性绝不交易to_bytes()摘要与parity_mutate.py的搜索 top-k 必须与基线完全一致其他基准单元的回退不得超出噪声门限非目标单元须在 x0.97 内胜出门槛目标操作的 armx86 调和均值须超过 x1.01且两者都不得回退回退线 x0.99迭代纪律假设 → smoke3 分钟、双机→ 仅在 smoke 通过后 soak-confirm15 分钟每个假设无论成败都要记录测量与裁决连续 20 个无胜假设后停止任一胜利重置计数。whm_mutate.py实现了这套计分规则——REGRESS 0.99目标单元不得低于此线、NOISE 0.97非目标单元须保持在此范围内任一单元触发 flag 即以退出码 1 拒绝该候选REGRESS 0.99 # a target cell may not fall below this NOISE 0.97 # non-target cells must stay within this测试环境与工具链日志Rig一节说明了测量环境的硬约束只允许在本目标自己的机器对turbovec-bench-arm-mutatec4a-standard-8 / ARMturbovec-bench-mutatec3-standard-8 / x86上测量两台机器均位于pydocs-prod/us-central1-a由主机的启动盘镜像构建因为 ARM 主节点是 c4a / Marvell GEN_4GCP 机器镜像不支持只能走启动盘镜像路径。每次 release 构建前需清理target目录并LD_PRELOAD对应架构的 libopenblas。本次爬山中 x86 半边开局即被阻塞us-central1 的C3_CPUS配额为 24全部被其他三个目标的机器占用-persist、-search、-sync。自限性重试在第 15 次尝试获得规格内 c3-standard-8 槽位——因此 H1–H4 都在该窗口期于 ARM 上开发与 smoke每个假设再在 x86 上对各自 pin 的 x86 基线测量后才算确认。配套工具链benchmarks/hillclimb 目录bench_mutate.py——五个原始计时bulk / append / single / swap / idremoveMT 与--st两种模式N200k、dim768、4-bit每 rep 重建索引。single单元同时充当 sanity gate单条添加不走 pool 交接因此 single-ST 与 single-MT 必须吻合否则说明网格被污染、需要重跑whm_mutate.py——候选相对基线的计分器实现 WHM 加权、_st硬门限与 single-add sanity 比率检查parity_mutate.py——正确性 oracle驱动与基准相同的变更序列输出每个阶段to_bytes()的 sha256 与固定查询集的 top-k 分数/ID基线与候选的 JSON 摘要必须逐字节一致data/base_arm_all.json、data/base_x86_all.json 等——pin 的基线数据。基线头空间在哪里基线ARM15 reps核心 commitc8d7ec02 测试台如下单元MTSTbulk357.39 ms1000.47 msappend16.42 ms48.27 mssingle0.014264 ms0.010534 msswap (x10k)0.7736 ms0.7919 msidremove (x10k)4.0127 ms3.9575 ms正确性 oracle 摘要4b91af2b40558e8e9a5296460fb97af84aef681e15f796581a9fe717e7108095。这个摘要贯穿整篇日志——每个假设无论成败的候选摘要都与基线逐字节相同这是正确性从不交易的量化证据。日志由此推算出单位成本明确指出头空间所在一行 bulk 插入约1.8 µs一行 append 约1.6 µs——append 本质是纯编码encode与 bulk 共享同一瓶颈单条 add 耗时14.3 µs是其所含单行编码成本约 1.6–1.8 µs的约8 倍——该单元几乎全是固定开销swap_remove为77 ns而IdMapIndex.remove含一次性 slot 映射构建为409 ns。单条 add 的 MT/ST 比率在基线核心上为 x1.35且两次独立运行精确复现说明这是真实成本MT 单行 add 会支付一次with_pool安装而 ST 哨兵池可将其折叠而非被污染的网格。因此 sanity gate 度量的是比率相对基线自身偏移的距离候选若能缩小该差距如 H3 将其完全闭合应判为健康而非污染。H1失败把旋转融合进量化遍历——批量/追加并非带宽受限假设encode此前运行两个并行遍历——rotate_batch_into将每一行旋转后写入n * dim的 f32 缓冲区200k × 768 的一次 add 就是614 MB随后quantize_batch再流式读回。两遍的行之间相互独立旋转可以移入量化循环内部让每行直接产出到每个 worker 的dim长度、常驻 L1 的缓冲区中。每行操作相同、顺序相同因此编码字节不变。动机数据perfARMbulkquantize_batch24.5%、rotate_batch_into18.9% apply_scaled_into10.7%、par_first_invalid_coord3.7%、__pi_clear_page2.6%614 MB 缓冲区的缺页开销。相关内核在 turbovec/src/encode.rs 中均可找到对应实现rotate_batch_into约 L406、quantize_batch约 L695、fused_quantize_scale_pack约 L1009与par_first_invalid_coord约 L58。实现以RowSource枚举承载两种来源——重构路径无 float32 原始数据需从已存码重建行与fit_calibration需要完整旋转批次常驻以计算每坐标顺序统计量保持分阶段形态add 路径则完全不再分配编码 scratch随之删除了相关 retention/shrink 簿记与六个由add_2d驱动的测试retain_scratch及其单测保留给校准路径。测量与裁决正确性cargo test -p turbovec --release全绿115 个 lib 测试 全部集成二进制oracle 摘要与基线一致Smoke5 repsARMbulk 359.23 vs 357.39x0.995、append 16.90 vs 16.42x0.972——未超 x1.01 胜出门限裁决NO WIN。被消除的 1.2 GB 往返内存流量本就不在关键路径上批量在旋转与量化算术上计算受限两者合计 55% 占比被移除的流式写读早已被预取吸收。该融合买来的是内存占用614 MB RSS 及其缺页开销不是时间。对后续假设的证伪价值bulk 与 append 在该形态下并非带宽受限。要在这些单元取胜必须移除算术或提升apply_scaled_into/fused_quantize_scale_pack内部的 SIMD 效率而不是搬运数据。这一结论直接塑造了后续 H4 的方向——H4 正是发现核心编码根本不是 bulk 时间去向而转向绑定层开销。H2胜闩锁IdMapIndex.remove的slots_ready探测——目标是 remove假设对删除循环单独剖析perf -D不采样准备阶段的 add显示IdMapIndex::remove占 21.4%、hashbrowninsert占 11.0%而关键线索是pthread_mutex_lock3.3% 与__aarch64_ldadd4_rel4.5%——锁流量才是瓶颈而非核心。每次remove都在取写锁之前执行py.detach(|| lock_read(self.inner).slots_ready())即每次删除都支付一次 GIL 释放/重新获取与一次读锁只为了问一句id→slot 映射是否已构建。关键洞察这个问题的答案只会 false→true。id_to_slot是一个OnceLock只通过get_or_init初始化见 turbovec/src/id_map.rs 约 L230而 Python 侧IdMapIndex是frozen的其innerRwLock每个对象只构建一次、永不重新赋值——因此该答案对每个索引是单调的可以闩锁到一个AtomicBool。闩锁只是对探测本会返回的true的短路删除走的路径不变Relaxed内存序足够丢失竞争只会重新探测而这正是原先每次调用都在做的事。slots_ready本身在 id_map.rs 约 L834 有实现与文档注释明确说明它只经历 false → true。测量与裁决Smoke5 repsARMidremove 3.469 vs 4.013x1.157swap 持平Soak15 repsARMremove-armx1.080、remove-arm_stx1.083bulk x1.014、append x1.008、single x0.994全部_st单元上升WHMx1.0273无单元 flag正确性测试套件全绿340 个绑定测试通过裁决WIN on ARMx86 pending——目标超过 x1.01 门限且子操作均未回退。H3胜IdMapIndex.add_with_ids的单行旁路——目标是 single假设以同样方式剖析单行添加循环结论极具说服力arch_local_irq_enable18.2%、el0_svc_common15.7%、crossbeam epoch pin 11.0%、dequesteal8.0%、sched_yield4.6%、wait_until_cold3.7%——而编码本身quantize_batchrotate_batch_into只占约 6%。一次 1 行 add 的时间花在唤醒八个 rayon worker 去做一行工作上。实现TurboQuantIndex::add早已具备此旁路issue #321、#392单行编码的 rayon 桥长度为 1、在调用线程上折叠因此install毫无收益、只付出唤醒成本除非行数或输入校验扫描确实会拆分否则跳过安装。但这个门从未应用于IdMapIndex::add_with_ids——而这个单元以及任何经过 id 映射存储的增量摄取实际调用的正是该方法。H3 将门含validation_parallelizes项镜像过去id 侧工作存在性检查、表更新是串行的、不分配 rayon 任务因此不会改变门的判定。validation_parallelizes门在绑定层 turbovec-python/src/lib.rs 约 L236、L527 被调用注释明确它正是闭合 #288/#321 的那个门约 L1581。测量与裁决Smoke5 repsARMsingle 0.006357 vs 0.014264x2.244Soak15 repsARM与 H2 累积single-armx2.254、single-arm_stx1.658、remove x1.083、bulk x0.998、append x1.004所有_st单元上升WHM8 个 MT 单元x1.1136无单元 flagsanity gate 印证诊断而非触发告警single-add MT/ST 比率从 1.354 → 0.996。差距就是pool 安装移除它让 MT 与 ST 重合。该门被重写为度量离 parity 的距离——候选把比率推向 1.0 是健康方向而不是污染网格裁决WIN on ARM, x86 pending。H4胜可中断 add 包装器中的原生批量校验——目标是 bulk 与 append假设H1 已断言 bulk 计算受限相位插桩也证实了核心的表现一次 200k add 中add_with_ids_2d占 199 ms内部编码 189.6、id 校验 3.3、map 插入 5.6、slot 扩展 0.1。但该单元耗时 354 ms——缺失的 155 ms 完全在核心之上。追查出两个事实。其一Python 的一次 add 并非一次调用可中断包装器issue #216BATCH_CHUNK_SIZE 4096将其切片200k 的 add 变成 49 次 4096 行的调用。其二真正的发现切片本身不是成本——授权切片的整批预校验才是。直接旋转开关测量bulk 在默认配置下 354.4 ms关闭分块后109.1 msappend 16.43 → 7.17 ms。该预校验存在是有真实理由的——核心会拒绝的批次必须以原子方式失败而不是先提交其早期切片——但它的三项检查全都在用 numpy 能提供的最昂贵方式复述核心已做之事检查旧形式成本有限值np.all(np.abs(a) 1e16)物化与批次等大的 abs 数组和 bool 数组该形态约 1.5 GB 临时内存且即使第一个元素就坏也要读遍每个坐标无重复 idnp.unique(ids).size ids.shape[0]对整个 id 数组排序在 profile 中表现为unique_numeric无已存在 idany(int(h) in index for h in ids)Python 循环每个 id 一次 GIL 往返 一次索引锁替换方案为两个答案完全一致的原生谓词_all_finite——调用核心自己的first_invalid_coord一次并行遍历、无临时数组、短路在 turbovec-python/src/lib.rs 约 L1671 注册为模块函数IdMapIndex::batch_addable——在单次读锁下一次短路遍历同时回答两个 id 条件实现在 turbovec/src/id_map.rs 约 L489并有专门的单测覆盖重复 id、已存在 id、空批次、以及from_bytes加载后的延迟窗口行为约 L1163–L1229。原子性、fall-through 与错误路径均未改变——失败条件仍将整个批次委托给带原始数组的原始内核。用核心谓词替代 numpy 复述还消除了一个必须手工保持同步的重复实现两处对可接受的定义再也不会不一致。测量与裁决正确性oracle 摘要不变核心套件全绿全部 340 个绑定测试通过——且该套件自身运行时间从148 s 降至 19 s这正是胜利在一个完全独立的面上显现Smoke5 repsARMbulk 184.10 vs 357.39x1.941、append 8.72 vs 16.42x1.883Soak15 repsARM累积bulkx1.946、appendx1.871、single x2.180、remove x1.086ST 单元 x1.174 / x1.158 / x1.597 / x1.085WHM8 个 MT 单元x1.5921无单元 flagsanity gate 通过裁决WIN on ARM, x86 pending。刻意搁置的部分bulk 仍为 184 ms对比完全禁用分块时的 109 ms。剩余差距来自逐切片快照拷贝与 pool 交接而闭合它要么削弱 Ctrl-C 延迟用户可见属性要么在编码期间持有 GIL并发回退issue #289——两者都不是免费胜利因此都未采用。头空间不在哪里一次方法论修正H1 驳斥了核心编码的带宽叙事该结论依然成立——但它当时回答错了问题因为核心编码从来就不是 bulk 单元的时间去向。此前的每个胜利都来自同一个地方绑定层及其 Python 包装器中的逐调用开销而非内核算术。H2 与 H3 在小批量上发现它每次调用一次探测与一次 pool 安装H4 在大批量上发现同一形态整批校验用 numpy 临时数组与 Python 循环完成。swap_remove是那个从未移动的对照组全程 77 ns因为它从来没有探测、pool 交接或包装器。剩余诚实的目标是逐切片快照拷贝与编码内核本身。H5测量证实但刻意未合入把分块移入内核、批次只快照一次H4 之后 bulk 为 184 ms面对 109 ms 的天花板同一 add 完全禁用分块时的成本。差距在于拷贝包装器先在 Python 里快照整个批次保证每个切片读到一致版本issue #108随后内核再次快照每个切片因为它释放了 GIL、另一个 Python 线程可能写入源。两次完整拷贝——一次 200k × 768 add 就是 1.2 GB。直接测量np.array对该批次在 ARM 上耗时 37.1 ms逐切片拷贝的总量与它等量。方案在边界 Rust 侧、GIL 仍被持有时只做一次快照——对 Python 无法触达的内存读切片给出一致性保证但只付一份拷贝。校验移到快照上进行严格更强可证明切片编码的就是同一字节。切片循环与其信号检查移入内核KeyboardInterrupt仍在一个切片内落地且之前的切片仍已提交。测量15 repsARM累积bulkx3.006357.39 → 118.90 ms、append x2.066、single x2.274、remove x1.203ST x1.302 / x1.266 / x1.663 / x1.151WHM8 个 MT 单元x1.8736对比已合入集合的 x1.5921。阻塞原因——为什么没进 PR两个测试失败test_add_with_ids_always_chunks与test_add_with_ids_cancel_commits_completed_slices。二者都不是行为回退——它们通过__wrapped__驱动原始内核并计数逐切片调用而 H5 把该循环移进了内核它们观察的接缝不复存在。它们保护的语义批次中途取消提交已完成切片、且仅提交这些依然成立。但这不是重写它们的许可证这些基于__wrapped__的测试是分块功能确定性的、跨平台的覆盖旁边的真实 SIGINT 测试在 Windows 上跳过skip reason 中明确说明。删除接缝会让可中断功能在 Windows 上毫无覆盖、在任何地方都无确定性覆盖。替代方案需要给内核切片循环加测试专用钩子——这涉及已发布 API 表面的设计决策应当属于独立变更而不是附加在性能 PR 上。于是最重单元上进一步 x1.53 的提升卡在一个测试设计问题而非技术问题之后。该变更保留在perf/mutate-h5分支上。终局与确认状态日志开篇即给最终结论三个胜利H2、H3、H4在双架构上全部确认——x86 机器在约 1 小时重试后上线并针对各自 pin 的 x86 基线测量。八个 MT 单元的最终目标 WHM 为x1.6441全部 16 个单元MT 与 ST、双架构均有提升、无一 flag目标armx86HM(arm,x86)门限bulkx1.946x1.804x1.872x1.01appendx1.871x2.544x2.155x1.01singlex2.180x3.882x2.792x1.01removex1.086x1.017x1.051x1.01ST 单元bulk x1.174 / x1.342、append x1.158 / x1.617、single x1.597 / x2.590、remove x1.085 / x1.052——没有哪个胜利是 MT 独有的而这正是那条硬规则。两个 sanity gate 均通过且相互佐证single-add MT/ST 比率在 ARM 上 1.354 → 0.992、在 x86 上 1.554 → 1.037。双架构带有相同的 pool-install 特征且都被 H3 消除。一个诚实的保留意见swap-x86为 x0.982是唯一低于 parity 的子操作。它在噪声门限之内、没有任何变更触碰过它它从未有过探测、pool 交接或包装器且其 ARM 孪生为 x1.014——因此这读作噪声而非回退。它是remove单元的子操作而该单元在 x86 上得分 x1.017。正确性 oracle 摘要在双架构、基线与候选上均为4b91af2b…——编码字节跨架构一致且未被本日志中任何假设改变。复盘方法论要点从这篇日志可提炼出一套可复用的优化纪律先证伪再动手H1 用一次干净的反证计算受限而非带宽受限划掉了整类搬数据假设为后续指明了方向用对照隔离环境swap_remove全程 77 ns 不动证明胜利不是网格污染而是确实移除了逐调用开销性能门与正确性门分离WHM/门限管性能oracle 摘要管正确性二者互不妥协sanity gate 管测量有效性且被设计为度量相对基线偏移的漂移而非绝对 parity从而能正确地把消除 pool 安装判为健康而非污染测试接缝也是 APIH5 展示了性能收益被测试设计问题拦下的案例——确定性跨平台覆盖的接缝不能为性能删除替换它属于独立的 API 设计变更。对于想继续深入源码的读者IdMapIndex的slots_ready/batch_addable/id_to_slot实现在 turbovec/src/id_map.rs编码管线rotate_batch_into、quantize_batch、fused_quantize_scale_pack、par_first_invalid_coord在 turbovec/src/encode.rs绑定层谓词_all_finite/_batch_addable与validation_parallelizes门在 turbovec-python/src/lib.rsPython 侧可中断分块包装器BATCH_CHUNK_SIZE切片、整批快照、原生预校验在 turbovec-python/python/turbovec/_interruptible.py。每个假设在对应测试如 turbovec/tests/lazy_init.rs、turbovec-python/tests/test_interruptible.py中都有可追溯的验证。【免费下载链接】turbovecA vector index built on TurboQuant, written in Rust with Python bindings项目地址: https://gitcode.com/GitHub_Trending/tu/turbovec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
turbovec 在线索引变更路径性能爬山实录：从 WHM x1.0273 到 x1.6441 的五个假设与验证
turbovec 在线索引变更路径性能爬山实录从 WHM x1.0273 到 x1.6441 的五个假设与验证【免费下载链接】turbovecA vector index built on TurboQuant, written in Rust with Python bindings项目地址: https://gitcode.com/GitHub_Trending/tu/turbovec导读本文完整还原 turbovec 仓库中一次针对**在线索引变更live-index mutation**路径的系统性能优化过程benchmarks/hillclimb/LOG_mutate.md记录了一次爬山式hill-climb调优战役——对批量插入bulk、追加append、单条添加single与删除remove四类操作在 ARM/x86 双架构下的加权调和均值WHM进行迭代优化。文章将逐一剖析从失败假设 H1 到被搁置的 H5 共五个假设的提出依据、实现思路、测量结果与最终裁决并结合turbovec核心源码编码管线、IdMapIndex实现、Python 绑定层讲解每个优化点背后的真实调用链。读完你将掌握这套先 smoke 后 soak、正确性不妥协的优化方法论以及 turbovec 在绑定层/内核层的热点分布与性能瓶颈的真实形态。目标与规则什么是变更路径爬山benchmarks/hillclimb/GOAL_mutate.md定义了本次优化的目标函数最大化八个单元{arm, x86}×{bulk, append, single, remove}相对基线pinned baseline加速比的加权调和均值WHM其中bulk权重 2、append权重 2、single权重 1、remove权重 2remove单元本身取swap_remove与IdMapIndex.remove两个子操作加速比的算术平均。规则极其严格任何一条不满足即判假设失败单线程不得回退每个胜利必须同时在RAYON_NUM_THREADS1下单线程ST成立ST 回退等同于假设失败而非可接受的权衡正确性绝不交易to_bytes()摘要与parity_mutate.py的搜索 top-k 必须与基线完全一致其他基准单元的回退不得超出噪声门限非目标单元须在 x0.97 内胜出门槛目标操作的 armx86 调和均值须超过 x1.01且两者都不得回退回退线 x0.99迭代纪律假设 → smoke3 分钟、双机→ 仅在 smoke 通过后 soak-confirm15 分钟每个假设无论成败都要记录测量与裁决连续 20 个无胜假设后停止任一胜利重置计数。whm_mutate.py实现了这套计分规则——REGRESS 0.99目标单元不得低于此线、NOISE 0.97非目标单元须保持在此范围内任一单元触发 flag 即以退出码 1 拒绝该候选REGRESS 0.99 # a target cell may not fall below this NOISE 0.97 # non-target cells must stay within this测试环境与工具链日志Rig一节说明了测量环境的硬约束只允许在本目标自己的机器对turbovec-bench-arm-mutatec4a-standard-8 / ARMturbovec-bench-mutatec3-standard-8 / x86上测量两台机器均位于pydocs-prod/us-central1-a由主机的启动盘镜像构建因为 ARM 主节点是 c4a / Marvell GEN_4GCP 机器镜像不支持只能走启动盘镜像路径。每次 release 构建前需清理target目录并LD_PRELOAD对应架构的 libopenblas。本次爬山中 x86 半边开局即被阻塞us-central1 的C3_CPUS配额为 24全部被其他三个目标的机器占用-persist、-search、-sync。自限性重试在第 15 次尝试获得规格内 c3-standard-8 槽位——因此 H1–H4 都在该窗口期于 ARM 上开发与 smoke每个假设再在 x86 上对各自 pin 的 x86 基线测量后才算确认。配套工具链benchmarks/hillclimb 目录bench_mutate.py——五个原始计时bulk / append / single / swap / idremoveMT 与--st两种模式N200k、dim768、4-bit每 rep 重建索引。single单元同时充当 sanity gate单条添加不走 pool 交接因此 single-ST 与 single-MT 必须吻合否则说明网格被污染、需要重跑whm_mutate.py——候选相对基线的计分器实现 WHM 加权、_st硬门限与 single-add sanity 比率检查parity_mutate.py——正确性 oracle驱动与基准相同的变更序列输出每个阶段to_bytes()的 sha256 与固定查询集的 top-k 分数/ID基线与候选的 JSON 摘要必须逐字节一致data/base_arm_all.json、data/base_x86_all.json 等——pin 的基线数据。基线头空间在哪里基线ARM15 reps核心 commitc8d7ec02 测试台如下单元MTSTbulk357.39 ms1000.47 msappend16.42 ms48.27 mssingle0.014264 ms0.010534 msswap (x10k)0.7736 ms0.7919 msidremove (x10k)4.0127 ms3.9575 ms正确性 oracle 摘要4b91af2b40558e8e9a5296460fb97af84aef681e15f796581a9fe717e7108095。这个摘要贯穿整篇日志——每个假设无论成败的候选摘要都与基线逐字节相同这是正确性从不交易的量化证据。日志由此推算出单位成本明确指出头空间所在一行 bulk 插入约1.8 µs一行 append 约1.6 µs——append 本质是纯编码encode与 bulk 共享同一瓶颈单条 add 耗时14.3 µs是其所含单行编码成本约 1.6–1.8 µs的约8 倍——该单元几乎全是固定开销swap_remove为77 ns而IdMapIndex.remove含一次性 slot 映射构建为409 ns。单条 add 的 MT/ST 比率在基线核心上为 x1.35且两次独立运行精确复现说明这是真实成本MT 单行 add 会支付一次with_pool安装而 ST 哨兵池可将其折叠而非被污染的网格。因此 sanity gate 度量的是比率相对基线自身偏移的距离候选若能缩小该差距如 H3 将其完全闭合应判为健康而非污染。H1失败把旋转融合进量化遍历——批量/追加并非带宽受限假设encode此前运行两个并行遍历——rotate_batch_into将每一行旋转后写入n * dim的 f32 缓冲区200k × 768 的一次 add 就是614 MB随后quantize_batch再流式读回。两遍的行之间相互独立旋转可以移入量化循环内部让每行直接产出到每个 worker 的dim长度、常驻 L1 的缓冲区中。每行操作相同、顺序相同因此编码字节不变。动机数据perfARMbulkquantize_batch24.5%、rotate_batch_into18.9% apply_scaled_into10.7%、par_first_invalid_coord3.7%、__pi_clear_page2.6%614 MB 缓冲区的缺页开销。相关内核在 turbovec/src/encode.rs 中均可找到对应实现rotate_batch_into约 L406、quantize_batch约 L695、fused_quantize_scale_pack约 L1009与par_first_invalid_coord约 L58。实现以RowSource枚举承载两种来源——重构路径无 float32 原始数据需从已存码重建行与fit_calibration需要完整旋转批次常驻以计算每坐标顺序统计量保持分阶段形态add 路径则完全不再分配编码 scratch随之删除了相关 retention/shrink 簿记与六个由add_2d驱动的测试retain_scratch及其单测保留给校准路径。测量与裁决正确性cargo test -p turbovec --release全绿115 个 lib 测试 全部集成二进制oracle 摘要与基线一致Smoke5 repsARMbulk 359.23 vs 357.39x0.995、append 16.90 vs 16.42x0.972——未超 x1.01 胜出门限裁决NO WIN。被消除的 1.2 GB 往返内存流量本就不在关键路径上批量在旋转与量化算术上计算受限两者合计 55% 占比被移除的流式写读早已被预取吸收。该融合买来的是内存占用614 MB RSS 及其缺页开销不是时间。对后续假设的证伪价值bulk 与 append 在该形态下并非带宽受限。要在这些单元取胜必须移除算术或提升apply_scaled_into/fused_quantize_scale_pack内部的 SIMD 效率而不是搬运数据。这一结论直接塑造了后续 H4 的方向——H4 正是发现核心编码根本不是 bulk 时间去向而转向绑定层开销。H2胜闩锁IdMapIndex.remove的slots_ready探测——目标是 remove假设对删除循环单独剖析perf -D不采样准备阶段的 add显示IdMapIndex::remove占 21.4%、hashbrowninsert占 11.0%而关键线索是pthread_mutex_lock3.3% 与__aarch64_ldadd4_rel4.5%——锁流量才是瓶颈而非核心。每次remove都在取写锁之前执行py.detach(|| lock_read(self.inner).slots_ready())即每次删除都支付一次 GIL 释放/重新获取与一次读锁只为了问一句id→slot 映射是否已构建。关键洞察这个问题的答案只会 false→true。id_to_slot是一个OnceLock只通过get_or_init初始化见 turbovec/src/id_map.rs 约 L230而 Python 侧IdMapIndex是frozen的其innerRwLock每个对象只构建一次、永不重新赋值——因此该答案对每个索引是单调的可以闩锁到一个AtomicBool。闩锁只是对探测本会返回的true的短路删除走的路径不变Relaxed内存序足够丢失竞争只会重新探测而这正是原先每次调用都在做的事。slots_ready本身在 id_map.rs 约 L834 有实现与文档注释明确说明它只经历 false → true。测量与裁决Smoke5 repsARMidremove 3.469 vs 4.013x1.157swap 持平Soak15 repsARMremove-armx1.080、remove-arm_stx1.083bulk x1.014、append x1.008、single x0.994全部_st单元上升WHMx1.0273无单元 flag正确性测试套件全绿340 个绑定测试通过裁决WIN on ARMx86 pending——目标超过 x1.01 门限且子操作均未回退。H3胜IdMapIndex.add_with_ids的单行旁路——目标是 single假设以同样方式剖析单行添加循环结论极具说服力arch_local_irq_enable18.2%、el0_svc_common15.7%、crossbeam epoch pin 11.0%、dequesteal8.0%、sched_yield4.6%、wait_until_cold3.7%——而编码本身quantize_batchrotate_batch_into只占约 6%。一次 1 行 add 的时间花在唤醒八个 rayon worker 去做一行工作上。实现TurboQuantIndex::add早已具备此旁路issue #321、#392单行编码的 rayon 桥长度为 1、在调用线程上折叠因此install毫无收益、只付出唤醒成本除非行数或输入校验扫描确实会拆分否则跳过安装。但这个门从未应用于IdMapIndex::add_with_ids——而这个单元以及任何经过 id 映射存储的增量摄取实际调用的正是该方法。H3 将门含validation_parallelizes项镜像过去id 侧工作存在性检查、表更新是串行的、不分配 rayon 任务因此不会改变门的判定。validation_parallelizes门在绑定层 turbovec-python/src/lib.rs 约 L236、L527 被调用注释明确它正是闭合 #288/#321 的那个门约 L1581。测量与裁决Smoke5 repsARMsingle 0.006357 vs 0.014264x2.244Soak15 repsARM与 H2 累积single-armx2.254、single-arm_stx1.658、remove x1.083、bulk x0.998、append x1.004所有_st单元上升WHM8 个 MT 单元x1.1136无单元 flagsanity gate 印证诊断而非触发告警single-add MT/ST 比率从 1.354 → 0.996。差距就是pool 安装移除它让 MT 与 ST 重合。该门被重写为度量离 parity 的距离——候选把比率推向 1.0 是健康方向而不是污染网格裁决WIN on ARM, x86 pending。H4胜可中断 add 包装器中的原生批量校验——目标是 bulk 与 append假设H1 已断言 bulk 计算受限相位插桩也证实了核心的表现一次 200k add 中add_with_ids_2d占 199 ms内部编码 189.6、id 校验 3.3、map 插入 5.6、slot 扩展 0.1。但该单元耗时 354 ms——缺失的 155 ms 完全在核心之上。追查出两个事实。其一Python 的一次 add 并非一次调用可中断包装器issue #216BATCH_CHUNK_SIZE 4096将其切片200k 的 add 变成 49 次 4096 行的调用。其二真正的发现切片本身不是成本——授权切片的整批预校验才是。直接旋转开关测量bulk 在默认配置下 354.4 ms关闭分块后109.1 msappend 16.43 → 7.17 ms。该预校验存在是有真实理由的——核心会拒绝的批次必须以原子方式失败而不是先提交其早期切片——但它的三项检查全都在用 numpy 能提供的最昂贵方式复述核心已做之事检查旧形式成本有限值np.all(np.abs(a) 1e16)物化与批次等大的 abs 数组和 bool 数组该形态约 1.5 GB 临时内存且即使第一个元素就坏也要读遍每个坐标无重复 idnp.unique(ids).size ids.shape[0]对整个 id 数组排序在 profile 中表现为unique_numeric无已存在 idany(int(h) in index for h in ids)Python 循环每个 id 一次 GIL 往返 一次索引锁替换方案为两个答案完全一致的原生谓词_all_finite——调用核心自己的first_invalid_coord一次并行遍历、无临时数组、短路在 turbovec-python/src/lib.rs 约 L1671 注册为模块函数IdMapIndex::batch_addable——在单次读锁下一次短路遍历同时回答两个 id 条件实现在 turbovec/src/id_map.rs 约 L489并有专门的单测覆盖重复 id、已存在 id、空批次、以及from_bytes加载后的延迟窗口行为约 L1163–L1229。原子性、fall-through 与错误路径均未改变——失败条件仍将整个批次委托给带原始数组的原始内核。用核心谓词替代 numpy 复述还消除了一个必须手工保持同步的重复实现两处对可接受的定义再也不会不一致。测量与裁决正确性oracle 摘要不变核心套件全绿全部 340 个绑定测试通过——且该套件自身运行时间从148 s 降至 19 s这正是胜利在一个完全独立的面上显现Smoke5 repsARMbulk 184.10 vs 357.39x1.941、append 8.72 vs 16.42x1.883Soak15 repsARM累积bulkx1.946、appendx1.871、single x2.180、remove x1.086ST 单元 x1.174 / x1.158 / x1.597 / x1.085WHM8 个 MT 单元x1.5921无单元 flagsanity gate 通过裁决WIN on ARM, x86 pending。刻意搁置的部分bulk 仍为 184 ms对比完全禁用分块时的 109 ms。剩余差距来自逐切片快照拷贝与 pool 交接而闭合它要么削弱 Ctrl-C 延迟用户可见属性要么在编码期间持有 GIL并发回退issue #289——两者都不是免费胜利因此都未采用。头空间不在哪里一次方法论修正H1 驳斥了核心编码的带宽叙事该结论依然成立——但它当时回答错了问题因为核心编码从来就不是 bulk 单元的时间去向。此前的每个胜利都来自同一个地方绑定层及其 Python 包装器中的逐调用开销而非内核算术。H2 与 H3 在小批量上发现它每次调用一次探测与一次 pool 安装H4 在大批量上发现同一形态整批校验用 numpy 临时数组与 Python 循环完成。swap_remove是那个从未移动的对照组全程 77 ns因为它从来没有探测、pool 交接或包装器。剩余诚实的目标是逐切片快照拷贝与编码内核本身。H5测量证实但刻意未合入把分块移入内核、批次只快照一次H4 之后 bulk 为 184 ms面对 109 ms 的天花板同一 add 完全禁用分块时的成本。差距在于拷贝包装器先在 Python 里快照整个批次保证每个切片读到一致版本issue #108随后内核再次快照每个切片因为它释放了 GIL、另一个 Python 线程可能写入源。两次完整拷贝——一次 200k × 768 add 就是 1.2 GB。直接测量np.array对该批次在 ARM 上耗时 37.1 ms逐切片拷贝的总量与它等量。方案在边界 Rust 侧、GIL 仍被持有时只做一次快照——对 Python 无法触达的内存读切片给出一致性保证但只付一份拷贝。校验移到快照上进行严格更强可证明切片编码的就是同一字节。切片循环与其信号检查移入内核KeyboardInterrupt仍在一个切片内落地且之前的切片仍已提交。测量15 repsARM累积bulkx3.006357.39 → 118.90 ms、append x2.066、single x2.274、remove x1.203ST x1.302 / x1.266 / x1.663 / x1.151WHM8 个 MT 单元x1.8736对比已合入集合的 x1.5921。阻塞原因——为什么没进 PR两个测试失败test_add_with_ids_always_chunks与test_add_with_ids_cancel_commits_completed_slices。二者都不是行为回退——它们通过__wrapped__驱动原始内核并计数逐切片调用而 H5 把该循环移进了内核它们观察的接缝不复存在。它们保护的语义批次中途取消提交已完成切片、且仅提交这些依然成立。但这不是重写它们的许可证这些基于__wrapped__的测试是分块功能确定性的、跨平台的覆盖旁边的真实 SIGINT 测试在 Windows 上跳过skip reason 中明确说明。删除接缝会让可中断功能在 Windows 上毫无覆盖、在任何地方都无确定性覆盖。替代方案需要给内核切片循环加测试专用钩子——这涉及已发布 API 表面的设计决策应当属于独立变更而不是附加在性能 PR 上。于是最重单元上进一步 x1.53 的提升卡在一个测试设计问题而非技术问题之后。该变更保留在perf/mutate-h5分支上。终局与确认状态日志开篇即给最终结论三个胜利H2、H3、H4在双架构上全部确认——x86 机器在约 1 小时重试后上线并针对各自 pin 的 x86 基线测量。八个 MT 单元的最终目标 WHM 为x1.6441全部 16 个单元MT 与 ST、双架构均有提升、无一 flag目标armx86HM(arm,x86)门限bulkx1.946x1.804x1.872x1.01appendx1.871x2.544x2.155x1.01singlex2.180x3.882x2.792x1.01removex1.086x1.017x1.051x1.01ST 单元bulk x1.174 / x1.342、append x1.158 / x1.617、single x1.597 / x2.590、remove x1.085 / x1.052——没有哪个胜利是 MT 独有的而这正是那条硬规则。两个 sanity gate 均通过且相互佐证single-add MT/ST 比率在 ARM 上 1.354 → 0.992、在 x86 上 1.554 → 1.037。双架构带有相同的 pool-install 特征且都被 H3 消除。一个诚实的保留意见swap-x86为 x0.982是唯一低于 parity 的子操作。它在噪声门限之内、没有任何变更触碰过它它从未有过探测、pool 交接或包装器且其 ARM 孪生为 x1.014——因此这读作噪声而非回退。它是remove单元的子操作而该单元在 x86 上得分 x1.017。正确性 oracle 摘要在双架构、基线与候选上均为4b91af2b…——编码字节跨架构一致且未被本日志中任何假设改变。复盘方法论要点从这篇日志可提炼出一套可复用的优化纪律先证伪再动手H1 用一次干净的反证计算受限而非带宽受限划掉了整类搬数据假设为后续指明了方向用对照隔离环境swap_remove全程 77 ns 不动证明胜利不是网格污染而是确实移除了逐调用开销性能门与正确性门分离WHM/门限管性能oracle 摘要管正确性二者互不妥协sanity gate 管测量有效性且被设计为度量相对基线偏移的漂移而非绝对 parity从而能正确地把消除 pool 安装判为健康而非污染测试接缝也是 APIH5 展示了性能收益被测试设计问题拦下的案例——确定性跨平台覆盖的接缝不能为性能删除替换它属于独立的 API 设计变更。对于想继续深入源码的读者IdMapIndex的slots_ready/batch_addable/id_to_slot实现在 turbovec/src/id_map.rs编码管线rotate_batch_into、quantize_batch、fused_quantize_scale_pack、par_first_invalid_coord在 turbovec/src/encode.rs绑定层谓词_all_finite/_batch_addable与validation_parallelizes门在 turbovec-python/src/lib.rsPython 侧可中断分块包装器BATCH_CHUNK_SIZE切片、整批快照、原生预校验在 turbovec-python/python/turbovec/_interruptible.py。每个假设在对应测试如 turbovec/tests/lazy_init.rs、turbovec-python/tests/test_interruptible.py中都有可追溯的验证。【免费下载链接】turbovecA vector index built on TurboQuant, written in Rust with Python bindings项目地址: https://gitcode.com/GitHub_Trending/tu/turbovec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考