现代 CPU 的 SIMD 指令为字符串查找带来了新的加速可能。传统算法基于字符比较便宜的假设，但在 SIMD 下，向量比较变得高效，而分支预测和内存查找成为主要瓶颈。文章探讨了如何利用 SIMD 进行快速预判，并结合精确比较来提升查找性能。
SIMD 加速字符串查找
文章指出，传统的字符串查找算法（如 KMP, Boyer Moore）在现代 CPU 上效率受限，因为它们的设计基于单字节比较开销低、子串比较开销高的前提。然而，借助 SIMD (Single Instruction, Multiple Data) 指令，CPU 可以并行处理多个数据，使得向量比较的效率接近单字节比较，此时分支预测失败和内存查找的开销反而更为显著。
作者提出利用 SIMD 的向量比较能力作为快速预判潜在匹配位置的方法，替代传统算法中的哈希或复杂状态机。对于通过向量预判筛选出的位置，再进行精确的 memcmp 子串比较。
文章介绍了两种 SIMD 友好的算法：
- 通用 SIMD 方法： 利用子串的第一个和最后一个字符作为预判条件。通过 SIMD 指令并行比较文本块中多个位置的这两个字符，生成一个掩码。然后只对掩码指示的潜在匹配位置执行精确的
memcmp。这种方法适用于多种 SIMD 指令集，如 SSE、AVX2、AVX512F，以及 SWAR 和 ARM Neon/AArch64。作者提到，选择子串中出现频率较低的字符作为预判条件可能比固定使用首尾字符更有效。 - 基于特定指令的方法： 针对 SSE4.1/AVX2 的 MPSADBW 指令，它可以快速计算块间的差异和，零差异表示潜在匹配。此外，SSE4.2 的 PCMPESTRM 指令是专门用于字符串处理的 SIMD 指令。
评论区讨论
评论区对文章内容进行了深入探讨。有人指出，文章中的通用 AVX2 方法与 ripgrep 内部使用的 memchr 库思路相似，memchr 会根据启发式选择子串中出现频率较低的两个字节进行预判，实际效果更好。评论也提到了标准库 API 的不足，例如无法预先构建搜索状态。
关于实现细节，多位评论者指出了文章示例代码中潜在的 Undefined Behavior (UB)，例如类型转换和边界条件处理不当。大家普遍认为，生产级代码中处理边界情况和内存对齐问题非常复杂，这也是使用成熟库（如 ripgrep）的原因。
关于 SIMD 算法的效率阈值，讨论认为，虽然 SIMD 设置有开销，但对于这种简单的预判方法，开销很小，即使对于相对较小的子串和文本，只要不是立即找到匹配，SIMD 也能带来优势。
此外，评论还提到了 musl libc 的 strstr 实现也很快，值得比较。讨论还延伸到如何在 Python 中利用 SIMD，以及在性能是瓶颈时是否应考虑切换语言。
Filedb 是一个用 Zig 语言实现的磁盘键值存储项目，其设计灵感来源于 Riak 数据库的 Bitcask 存储引擎。它采用日志结构，将所有写入操作追加到数据文件，并通过内存中的哈希表实现快速查找。这种设计带来了快速的顺序写入和高效的读取性能。
Filedb：基于 Bitcask 的 Zig 语言键值存储
Filedb 的核心是一个日志结构的存储引擎。这意味着数据不是在原地修改，而是所有写入操作都被追加到一个数据文件的末尾。为了实现快速读取，Filedb 在内存中维护一个哈希表，这个哈希表存储了每个键对应的值在磁盘数据文件中的具体位置（文件 ID 和偏移量）。
当当前数据文件达到预设大小或数据库重启时，Filedb 会切换到一个新的数据文件进行写入，旧文件则变为只读。为了管理磁盘空间和避免文件过多，Filedb 会定期执行“压缩”（compaction）过程，将旧文件中仍然有效的最新版本数据合并到一个新的文件中，同时更新内存中的哈希表指向新的位置。此外，Filedb 提供了同步（sync）机制，可以将内存中的数据（主要是哈希表的变化）强制刷写到磁盘，确保数据的持久性。
这种设计模式有几个显著优点：
- 写入速度快： 写入操作是简单的文件追加，属于顺序写，效率很高。
- 读取速度快： 通过内存哈希表可以实现 O(1) 的键查找，然后直接定位到磁盘上的数据位置进行读取。
- 内存占用相对固定： 内存中存储的主要是键和数据位置信息，其大小与值的实际大小无关，只与键的数量和大小有关。
评论区讨论
评论区对 Filedb 项目表现出浓厚兴趣。有人回忆起在大学课程中实现 Bitcask 的经历，认为其设计简洁直接，特别适合日志存储等需要高写入吞吐量的场景。但也有人指出 Bitcask 的一个局限性是缺乏内置的二级索引功能，这限制了它在复杂查询场景下的应用。
大家称赞作者用 Zig 语言实现了这个项目，并包含了 Redis 兼容的服务器端。得知这是印度理工学院学生的作品后，不少人表示赞赏。关于数据持久性，有评论对客户端手动调用 sync 的需求表示担忧，但其他评论指出 README 中说明了存在自动同步间隔和强制同步选项。
关于 Filedb 与 SQLite、PostgreSQL、Redis 等常见数据库的区别及适用场景，评论区展开了讨论。一些人认为这类项目更多是学习目的的“玩具”，通用场景下 SQLite 更可靠。但也有人反驳说，Bitcask 这种日志结构设计在特定生产场景（如收集大量时序数据、日志、遥测数据）下非常有效，能提供比传统 ACID 数据库更高的写入吞吐量。
国际包裹上常见的 13 位追踪号码遵循万国邮政联盟 (UPU) 的 S10 标准。这个全球协调的系统定义了号码的结构：两位服务类型字母、八位序列号、一位校验码，最后是寄件邮政运营商的两位 ISO 国家代码。服务类型字母指示邮件类型（如追踪邮件、包裹、快递），序列号由寄件邮政服务分配，校验码用于验证序列号的正确性。
国际包裹追踪号码：UPU S10 标准解析
文章深入探讨了国际包裹追踪号码背后的 UPU S10 标准。这个标准规定了我们熟悉的 13 个字符的追踪号码格式并非随机生成，而是一个全球统一的体系。
S10 标准的结构如下：
- 服务类型 (Service Indicator): 开头的两位字母，例如 EA-EZ 用于 EMS (Express Mail Service)，CA-CZ 用于包裹，LA-LZ 用于追踪信件等。这些字母指示了邮件或包裹的服务类型。
- 序列号 (Serial Number): 紧随其后的八位数字，由寄件国的邮政服务分配，用于唯一标识一个邮件或包裹。标准建议在至少 24 个月内不重复使用序列号。每个服务类型代码在一个国家内有 1 亿个可能的序列号（从 00,000,000 到 99,999,999）。
- 校验码 (Check Digit): 序列号后的一个数字，通过一个特定的计算方法得出，用于验证序列号的准确性，帮助发现输入错误。
- 国家代码 (Country Code): 最后两位字母是寄件邮政运营商的 ISO 3166-1 Alpha-2 国家代码。这表示处理该邮件的邮政机构