turbovec sync() 性能爬山实录如何在 fsync 硬底之上把同步压缩 5.5 倍【免费下载链接】turbovecA vector index built on TurboQuant, written in Rust with Python bindings项目地址: https://gitcode.com/GitHub_Trending/tu/turbovec导读本文是 turbovec 仓库中 benchmarks/hillclimb/LOG_sync.md 的完整解读。该文档记录了一场针对向量索引持久化接口sync()的系统化性能优化hill-climb战役在一个崩溃安全契约每次同步恰好一次批量写入、一次 fsync约束下把 1000 次零散删除后的同步耗时从 x86 的 18.58 ms 压到 3.39 ms约 5.5 倍、ARM 从 9.77 ms 压到 3.58 ms约 2.7 倍并最终逼近 fsync 的物理下限。读完本文你将掌握这套目标–基线–假设–判定的量化性能工程方法论理解崩溃安全同步的底层实现turbovec/src/io_v7.rs 的cursor_state、plan_incremental、run_sync以及如何识别成本转移型假优化。背景什么是 turbovec 的 sync()turbovec 是一个用 Rust 编写、带有 Python 绑定的向量索引构建在 TurboQuant 量化方案之上。它的磁盘持久化围绕sync()展开IdMapIndex::sync(path)把内存中的变更以增量方式提交到磁盘文件。sync()的核心契约可以概括为三条见 turbovec/src/io_v7.rs 中run_sync与fsync_commit的实现一次写入批次、一次 fsync崩溃安全由增量描述符delta digest保证而不是靠多个顺序屏障每次同步只产生一个 batch 的写入随后一次f.sync_all()注意用的是sync_all而非sync_data因为同步会改变文件长度。可恢复性任何字节位置的写入撕裂torn write之后加载器都能回退到上一个已提交版本。增量 vs 全量增量同步原地写入如果携带的操作数超过头部容量上限MAX_OPS1024则回退为临时文件 原子改名的全量重写。sync()有两种典型负载sync_append追加 32 行一个全新 block unit 加提交头部后的同步提交量约 12 KB。sync_remove执行 1000 次零散删除后把 ~995 条重做操作redo ops随头部一起提交的同步提交量约 400 KB。这场爬山优化的目标就是把这两个负载下的同步耗时压到物理极限。实验装置可复现的量化 Rig爬山实验不是在本机随意跑的而是搭建了一对专用基准机详见 benchmarks/hillclimb/LOG_sync.md 的 Rig 一节机器规格区域磁盘turbovec-bench-syncc3-standard-8x86us-central1-apd-balanced 100 GBturbovec-bench-arm-syncc4a-standard-8ARMus-east4-chyperdisk-balanced 80 GB3480 IOPS / 260 MB/s要点专用而非主基准机与正式基准机隔离避免相互干扰。ARM 机区域偏离us-central1 的 C4A 配额被其他目标占用因此 ARM 机落在 us-east4-c。但磁盘规格与 ARM 主基准机完全一致且每个加速比都是与同一台机器上记录的基线比较所以目标函数不受影响只是跨目标的绝对 ARM 数值不可比。构建纪律每次 release 构建前rm -rf target清掉增量编译残留并LD_PRELOAD对应架构的 libopenblas。独立工作树爬山在专用 worktreescratchpad/wt-sync上进行不触碰共享 checkout避免并发编辑污染实验。基准与评分脚本对应仓库中的 benchmarks/hillclimb/bench_sync.pyN200kdim7684-bit和 benchmarks/hillclimb/whm_sync.py。四个测量单元与两个门单元benchmarks/hillclimb/bench_sync.py 中定义了每架构五个 cellcell含义权重sync_append32 行追加后的同步目标权重 1sync_remove1000 次零散删除后的同步目标权重 1sync_first全新路径的首次同步全量写门单元权重 0sync_settle紧随其后的、把这些 ops 物化进 block unit 的同步门单元权重 0remove_calls1000 次remove()调用本身H5 时新增门单元权重 0为什么要有门单元因为把工作从被测同步里挪出去挪进全量写、挪进下一次同步、挪进remove()本身会让被测 cell 变快但总耗时没变——这是成本转移cost-shifting不是优化。门单元的作用就是当场抓住这种假胜利。whm_sync.py的评分逻辑benchmarks/hillclimb/whm_sync.py目标 cell 的得分 基线毫秒 / 当前毫秒speedupARM 与 x86 两个值的调和平均HM必须 1.01两个目标 cell 各自都不得回退speedup 1.0 即失败其余 cell含门单元回退不得超过 3%NOISE_TOLERANCE 0.03崩溃契约不动一次写入批次 一次 fsync sync_all持久性撕裂写入测试和损坏矩阵全绿停止规则连续 20 轮非胜利。基准数固定在 benchmarks/results/sync_baseline.json例如sync_remove-x86基线 18.578 ms、sync_remove-arm9.772 ms、sync_append-x861.822 ms、sync_append-arm1.774 ms。基准核心36ecaeec包含热身丢弃逻辑第一个 rep 是热身并被丢弃见bench_sync.py中WARMUP 1的注释说明。第一步测量 fsync 硬底任何优化都要先知道物理极限。日志记录了直接测量的 fsync 地板对已有 80 MB 文件写入 S 字节后 fsync15 次取中位数写入大小x86ARM4 KB1.41 ms1.42 ms64 KB1.69 ms1.74 ms400 KB2.46 ms2.44 ms12.6 MB8.75 ms6.14 ms由此得出的关键约束32 行追加提交约 12 KB所以sync_append在两端都只比其地板高约 0.5 ms——这里的波动就是 fsync 方差无论看起来多一致都必须拒绝。1000 次删除提交写约 400 KB 头部所以sync_remove在 x86 上约 75% 是 CPU 时间计划构建、头部组装、摘要计算——这才是诚实的目标。这个先量地板、再谈优化的做法贯穿全文也体现在whm_sync.py的--fsync-floor参数报告每个 cell 有多少比例是可寻址的即非 fsync 部分声称的收益若超过非 fsync 余量那只是测量假象。三条获胜假设H1、H2、H8H1sync 不再重复证明自己上一次的提交目标sync_remove现象来源热身异常——remove cell 的第 0 轮跑出 4.7 ms而稳态是 17.4 ms。原因第 0 轮之前的提交是全量写其头部没有命名任何 unit所以没有东西需要重新验证。底层机制每次 sync 开头都要调用cursor_stateturbovec/src/io_v7.rs 第 1614 行起来判断文件是否还是游标写的那一个。它原本的做法是从新到旧走查头部槽位对每个槽位重新读取该次提交写入的每个 unit并重算 delta 摘要。一次 1000 删除的 settle 之后这就意味着进入下一次 sync 之前要做12.6 MB 的读取 CRC 计算。但这其实是在证明一件已经被证明过的事。一个游标只有两种建立方式本进程写了这个提交且sync只有在sync_all报告持久化后才返回 Ok或者load采纳了它而load选提交正是跑这个 delta 检查。再往上nonce 比较文件头的 superblock nonce vs 游标 nonce已经确认是同一个文件。所以当最新可解析头部的 generation 等于游标自己的 generation 时它就是最新的可采纳提交——这就是Intact的含义。优化只有在 generation 不同说明有其他写者推进了文件时才走完整的验证路径。短路只跳过已被证明的提交在不受支持的并发写者场景下倾向于拒绝而非采纳。实现上cursor_state里的if cands.first().is_some_and(|h| h.gen cursor.gen)直接返回Intactturbovec/src/io_v7.rs 第 1724-1726 行。验证完整cargo test -p turbovec全绿121 个 lib 测试 所有集成二进制重点覆盖崩溃契约的撕裂写入测试族a_sync_torn_at_any_byte_recovers_the_previous_commit、a_torn_materialize_of_a_delta_named_unit_recovers、blocked_only_capture_survives_a_torn_sync、a_recovery_load_syncs_forward_and_survives_a_second_tear、an_id_mapped_sync_torn_anywhere_restores_ids_exactly见 turbovec/tests/sync_v7.rs、损坏矩阵、以及两个多写者测试a_stale_cursor_refuses_to_clobber_another_writers_commits、two_writers_at_the_same_generation_do_not_collide。结果15 轮 soaksync_remove ARM 9.77 → 3.49 msx2.80x86 18.58 → 4.90 msx3.79目标 HMx3.22。两个被基线标记的 cell 经交错 A/B 复查后均判定为基线漂移而非回退。H2只读头部槽位的已用前缀而非其操作容量目标sync_append底层机制cursor_state原本在查看任何槽位之前就要读整个头部区域——superblock 加两个槽位。而一个槽位是为 1024 操作上限约 428 KB dim 768预留大小的所以每次 sync 路上都要读并清零约 856 KB——哪怕一个 32 行追加的整个提交只有约 12 KB。优化不携带待重做操作的提交追加或任何紧随一次已物化 ops 的同步之后的同步——目标两个 cell 的稳态都是这个形态只用固定字段、尾部块、delta 描述符和 CRC约 16 KB。现在每个槽位按这个尺寸读取只有解析需要更多时才扩展到完整槽位那是一次性的第二次读取且稳态下从不发生。实现上parse_header_slot被拆出一个槽位局部的parse_header_atturbovec/src/io_v7.rs 第 1126 行起每个字段读取都有边界检查前缀够长就解析成功不够就返回None。cursor_state里的read_slot闭包正是先探测、装不下再扩宽第 1663-1688 行。验证A/B 交错预构建模块x86 4 轮、ARM 6 轮目标 HMsync_appendx1.072无任何 cell 在任一架构回退。诚实解读胜利主要由 x86 贡献每轮 sync 少读 840 KB机制明确非设备噪声ARM 在噪声内持平。H8把捕获删除字节门控到 x86目标sync_remove这是 H5–H7 一系列尝试收敛后的最终形态详见下文失败假设部分。穿插的探针删除同步的时间都去哪了H2 落地后日志记录了一个非假设的探针实验在 x86 上以 50/200/500/1000 次删除计时sync_remove得到 1.92 / 2.40 / 3.23 / 4.78 ms——干净且线性。每操作 3.02 µs固定成本 1.77 ms。其中 1000 次操作增加的 3.02 ms 里fsync 本身约 0.9 ms提交从约 20 KB 长到约 400 KB按地板表 1.5 → 2.46 ms剩下约 2.1 ms 是 CPU——这是任何按操作优化唯一能触及的部分。这 2.1 ms 在哪里每个操作要从 32 路交织块中串行化一行代码dim 768 下就是从 stride 32 中做 384 次字节提取——为了收集 384 字节要走完整个 12 KB 块单元。约 995 个操作就是约 12 MB 的散乱读取。成本是内存延迟不是算术、不是分配——这一点后来被 H3 以惨痛方式证实。六次被拒绝的假设失败同样有方法论价值H3把行代码直接追加进头部缓冲区目标sync_remove头部组装原来每操作调用seq_row分配并返回一个Vec见 turbovec/src/lib.rs 第 1647 行再拷进头部并 drop1000 次删除同步要约 995 次分配、约 382 KB 拷贝。改为seq_row_into直接扩展头部缓冲区。结果目标 HMx0.986——不是胜利是回退。原因Vec::extend从迭代器逐字节地重新检查容量384 字节的行比它替换的collect()分配 extend_from_slicememcpy 更贵。结合上面的探针这证实按操作成本在 stride 收集上分配从来不是要移除的瓶颈。已回退。A/A 对照什么没改时装置在测什么H4 在 append cell 上跑出 x1.07——与 H2 完全不同的机制却得到相同数字。于是用两份完全相同的模块按 A/B 相同的方式交替cell未改动代码上的波动范围第二位比率第二位更慢sync_appendx861.56–1.82±7.9%x0.9522/3sync_appendarm1.50–1.81±9.7%x0.9672/4sync_removex864.55–4.88±3.5%x0.9423/3sync_removearm3.41–3.67±3.7%x1.0162/4sync_settlex8632.6–35.3±4.0%x0.9612/3sync_settlearm17.5–18.8±3.6%x1.0051/4两个发现都改写了此前结果的读法append cell 无法支撑低于约 10% 的声明。未改动代码上它自身逐轮波动就是 ±8%x86/±10%ARM——它只比 fsync 地板高约 0.15 ms而动的正是那个地板。这正是目标里写的拒绝 fsync 方差内的胜利。H2 的 x1.072 和 H4 的 x1.071 都在这个带内。ab.sh总是 base 先跑而第二位并不中性。x86 的sync_remove上第二轮在 3/3 中更慢约 6%。这意味着此前的每个 A/B 都在那个 cell 上给new加了约这么多 handicap——remove cell 的数字是被低估而非美化H2 的 x1.034 位置校正后约 x1.10H3 的 x0.985 约 x1.05H4 的 x1.007 约 x1.07。所以H3 的拒绝存疑——它可能是个被更大 handicap 掩盖的小胜利——H4 的结论悬而未决。H2 在ab2.sh上重述8 轮、顺序交替ab2.sh从这以后取代ab.sh奇数轮 base-先-new偶数轮 new-先-base轮内趋势均匀落在两侧。H2 重测8 轮sync_appendx86 1.950 → 1.700x1.1477/7 更优ARM x1.0155/8目标 HMx1.077无 cell 回退。胜利成立。日志还给出了一个方法论要点A/A 对照测得的是 cell 的非配对波动±8% 逐轮那只是不同时间取两个数比较即与基线比较时的正确标尺对于配对设计——base 与 new 在同一机器状态内交替——统计量是跨轮次的符号检验x86 append 7/7 更优p ≈ 0.008。幅度落在非配对波动带内并不削弱它——这正是配对存在的原因。自此立下的规则每个 A/B 以中位数比率N-of-M 更优形式报告符号检验没有多数派就视为持平无论中位数如何。H4 在ab3.sh上重述8 轮、顺序交替、固定装置H3 的修正形态一次性增长头部缓冲区通过索引切片填充而不是逐字节extend。结果x86 append cell回退x0.9738 轮中仅 3 轮更优违反无 cell 回退remove cell 在 x86 无符号检验多数派4/8 持平x1.015 的调和平均完全落在 ARM 的 6/8p ≈ 0.145上——不是结果。NON-WIN已回退。这也顺带关闭了 H3 的问题H3 与 H4 是同一个想法的劣形与优形而优形在它针对的 cell 上是持平的——约 995 次按操作分配从来不是成本。ab3.sh还把装置固定到一份独立副本而不是从检出树读取——这样碰过bench_sync.py的假设不可能让 base 和 new 跑两份不同的基准。它携带新增的remove_calls门单元x86 约 3.35 ms、arm 约 1.70 ms1000 次remove()调用。H5在已经持有行字节的移动处捕获它们目标sync_remove探针把按操作成本钉在从 32 路交织块串行化一行上stride 32 的 384 次字节提取、走完整个 12 KB 单元去收集 384 字节、每 sync 约 995 次。但swap_remove的move_lane早已算出这些字节——x86 上每个组调用deinterleave_x86_code_byteturbovec/src/pack.rs 第 125 行并把结果放入目标 lane。留住它们sync 就不必重新推导。正确性是最有趣的部分全是时序问题捕获只在其被读取的窗口内获取slot 在已提交地板之下、阻塞缓存权威且只在该窗口内被查阅所以唯一会重写每一行的事件——重新校准——不可能透过陈旧条目被读到它会物化packed_codes并永久关闭读路径。新测试captured_removal_bytes_match_a_reread_of_the_rowturbovec/tests/sync_v7.rs 第 557 行起覆盖双删除、增补回填、未提交填充、重新校准和每种位宽每轮重载并强制to_bytes相等用突变检查验证篡改捕获字节即失败。结果sync_remove x86x1.3498/8、ARMx1.1838/8目标 HMx1.261——依然被拒绝。因为remove_calls在 x86 回退 9%、ARM 回退 20%两端都是 0/8 轮更优sync 变快的方式是把工作挪进了remove()。净算下来 x86 省 1.22 ms 同步、付 0.31 ms 删除0.90 净ARM 省 0.55、付 0.440.11——ARM 那一半几乎完全是转移。NON-WIN成本转移被一个假设前刚加的门单元当场抓住。机制本身成立、目标数字真实所以存储方式是下一步要修的——通向 H6。H6把同样的捕获放进 arena 而非 map目标sync_removeH5 的诊断说存储是问题于是一个字节 arena 加一个只追加的(slot, offset)索引slot→bytes 查找每 sync 构建一次而不是每删除一次哈希。结果sync_remove x86x1.3548/8、ARM x1.1628/8但remove_calls依旧 x86 x0.9510/8、ARM x0.7910/8。NON-WIN仍是成本转移。map 在 x86 上值约 4 个点在 ARM 上一文不值——剩余成本从来不是 map而是捕获仍然按字节做的事每删除一个临时Vec、每字节组一次容量检查的push、然后整行从临时区拷进 arena。arena 消除了三者中的最后一个留下前两个 → H7。H7通过预置大小的切片直接捕获进 arena目标sync_remove三个按字节成本中的最后一个。调用方现在先增长 arena再给move_lane_capturing一个恰好n_byte_groups长的切片于是捕获变成每组一次索引存储无临时Vec、无容量检查、无拷贝。选项测试也移出了内层循环——两个循环体取代带逐字节分支的一个。结果x86 转移终于消失——remove()只付 1.5%在门限内——sync_remove是 x1.3847/7。但 ARM 的remove()仍付 16%。为什么 ARM 无法靠继续收紧代码修复x86 上 lane 移动是去交织 nibble 合并写捕获的多余存储只占本已很重的循环的一小部分在 x86 之外移动就是一次字节读和一次字节写——捕获是在两步循环上加第三步内存操作remove()多约 50% 工作却只省 sync 里不到那个量的时间ARM 的 sync 本来就只有 0.5 ms 的收集量。三种实现H5 map、H6 arena、H7 预置切片把 ARM 的remove_calls从 2.150 → 2.130 → 2.010基线 1.685。地板就是那个多余的存储本身 → H8 把捕获门控到 x86。H8 详述捕获门控到 x86目标sync_removeH7 原样但capture_this额外要求cfg!(target_arch x86_64)。x86 之外什么都不捕获、查找返回空、删除路径是旧路径。首轮 8 轮 A/Bx86 目标明确x1.3668/8remove_calls两端终于干净x0.994 / x0.988门限 OKARM 各 cell 均持平按设计那里什么都不捕获。但 settle 门不干净算术令人不安base: remove 4.740 settle 33.715 38.455 ms new: remove 3.470 settle 34.995 38.465 ms删除同步的节省与 settle 的损失对消到 0.01 ms。有一个机制能精确解释这一点本假设移除的那个收集正在读取约 995 个 unit约 12 MB而 settle 同步随后会覆写它们——所以它一直在为不按块对齐unit 是 12,672 B两端都需要读-改-写的写入预热页缓存。把读拿走settle 来付账。但这与同一机制下 H6 的 x1.003、H7 的 x0.995 冲突且 3.7% 的移动落在 ±4.0% 的 A/A 带内——三次运行不可能都对。用每架构再 8 轮配对各 16 轮解决settle 回退没有复现——第一组 x0.9631/8第二组 x1.015合并 x0.9866/16 无多数派——既在 3% 门内也在 cell 自己的 ±4.0% A/A 带内。而成本转移的解读被周期总账直接驳倒那个解读预测总账会持平basenewremovesettle每周期x8638.60537.725x1.02314/16 更优最终每架构 16 轮配对sync_removex86 4.735 → 3.390x1.39716/16ARM 持平x0.9927/16每个门都在 3% 内。目标 HMx1.160。WIN已提交连胜归零。关于 ARM 目标 cell 读 x0.992 的诚实表述名义上略低于 1.0而胜利规则要求目标 cell 不回退。判为持平的理由不是它很小aarch64 上捕获被#[cfg]掉删除路径与基线是同一份代码符号检验 7/16 无任何方向多数cell 未改动代码的 A/A 波动是 ±3.7%把样本翻倍使 0.986 → 0.992 向 1.0 回归——正是向均值回归的预测。这场胜利完全由 x86 承载因为机制只在 x86 适用。地板分析remove sync 如今约 87% 是 fsync在 H8 核心上重跑斜率探针按操作成本降到x86 1.89 µsH8 前是 3.02固定截距 2.42 / 1.81 ms。然后一个一次性插桩构建wip/sync-prof从未合并把 sync 本身拆开x86 上 28 个样本阶段remove syncsettle synccursor_state~210 µs~220 µsplan_incremental头部组装 摘要~300 µs~14,600 µsrun_syncseek 写 fsync~3,500 µs~21,000 µs所以一个 4.0 ms 的 remove sync 中约 3.5 ms 是崩溃契约锁定的那一次写入批次和一次 fsync整个可寻址余量约 510 µs——300 在计划构建、210 在身份检查。那个 cell 上任何高于 13% 的东西都只能靠交易契约来实现而契约不在谈判桌上。3.5 ms 高于地板表给 400 KB 写入的 2.46 ms因为那张表让设备先排空 150 ms 再 fsync真实 sync 是立即 fsync 自己 100 个刚弄脏的页面。另一个值得记录的数字一次 settle sync 花14.6 ms CPU构建计划——995 个 unit 物化、约 12.6 MB 组装与摘要。这是 sync 路径上剩余的最大 CPU 成本但它属于门单元权重 0不在本目标范围内——留给接手的人。H9借用 op-group 切片而非每 unit 一个Vec目标sync_removeplan_incremental原本构建Vec(usize, Vecusize)——每个承载操作的 unit 一次堆分配最多每 sync 1024 次。carried已排序所以每个 unit 的 ops 是它的一段连续区间可以借用切片。目标是约 300 µs 计划构建中属于分配的那约 230 µsmemcpy 和 CRC 加起来只约 70 µs。预期上限约 cell 的 5%对 ±3.5% 的 A/A 带——按构造就是边缘的正因为如此才要测量而非任其假定。结果目标 HM x1.015——纸面上过 1.01 线无目标 cell 回退每个门都在 3% 内。仍是 NON-WIN按权重列三条理由ARM 的remove_calls移到 x0.975 且 base 在 8 轮中 7 轮更优——而这个 diff不可能触碰remove()它只改plan_incremental。一个门单元朝代码不可能导致的方向动 2.5%直接证明这一轮携带了配对未吸收的漂移这使同一轮测出的 1.5% 读数失去资格。x86——计划构建最大的架构——没有符号检验多数派4/7。按既定规则这是持平调和平均于是落在 ARM 的 x1.011 上。整个效应在或低于各 cell 的 A/A 带remove ±3.5%append ±10%。目标指示正是要拒绝这个。这个改动本身是真实的改进——每 sync 最多少 1024 次分配、严格更少的工作——但真实且不可测不是胜利拿 x1.015 的声明发布它会歪曲证据。已回退。这场爬山的终点装置的分辨率已等于全部剩余机会三胜H1、H2、H8、六拒H3–H7、H9baselinenowfsync 占比sync_removex8618.58 ms3.39 msx5.5~87%sync_removearm9.77 ms3.58 msx2.7—sync_appendx861.82 ms1.67 ms在地板处sync_appendarm1.77 ms1.59 ms在地板处x86 remove cell 上实测的可寻址余量是 4.0 ms 中的约 510 µs而这套装置在该 cell 上能分辨约 3.5%±140 µs。装置的分辨率与全部剩余机会已经是同一量级。H9 就是这一点的活样本一个确定是改进的改动测得 1.5%对 3.5% 的带。对这个目标再提假设就是在提出低于噪声的工作。诚实的结论是爬山已收敛——而不是为了凑出正式的停止规则连续 20 轮非胜利再记录 19 次纸面拒绝。方法论收获这套流程最值得带走的东西从 benchmarks/hillclimb/LOG_sync.md 的全过程可以提炼出几条可复用的量化性能工程原则先量地板fsync 地板表决定了什么甚至不值得讨论。在地板方差之内的胜利无论多一致都被拒绝。门单元抓住成本转移目标 cell 变快不等于总耗时变少。门单元sync_first、sync_settle、remove_calls存在的意义就是让把工作挪出被测区间原形毕露——H5/H6 的两个 x1.35 级别胜利就是这么被否掉的。A/A 对照校准装置在未改动的代码上跑相同协议得到 cell 的逐轮波动带和位置偏差。这既否决了带内的声明也暴露了ab.sh的顺序偏差。配对 符号检验同一机器状态内交替 base/new用跨轮次的符号检验做判定中位数比率只作报告。没有多数派 持平无论中位数如何。架构分化是机制使然H8 最终把捕获门控到 x86因为 off-x86 的 lane 移动本身就轻到没有可捕获的冗余。机制在哪里成立胜利就由哪里承载。诚实记录失败H3 被自己的 A/A 对照部分翻案、H9 因门单元漂移被判不可测——每一次拒绝都带着可复验的算术与理由这正是证据链可信的原因。对想要深入代码的读者建议按这个顺序阅读benchmarks/hillclimb/bench_sync.pycell 定义与热身逻辑→ benchmarks/hillclimb/whm_sync.py判定规则→ turbovec/src/io_v7.rs 的cursor_state、plan_incremental、parse_header_at、run_syncH1/H2/H9 的机制→ turbovec/src/pack.rs 的deinterleave_x86_code_byte与 turbovec/src/lib.rs 的sync入口H5–H8 的机制→ turbovec/tests/sync_v7.rs撕裂写入与捕获正确性测试。基线数据在 benchmarks/results/sync_baseline.json同一场战役的其他视角可见 benchmarks/hillclimb/LOG.md 与同目录下的各目标日志。【免费下载链接】turbovecA vector index built on TurboQuant, written in Rust with Python bindings项目地址: https://gitcode.com/GitHub_Trending/tu/turbovec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考