灌水: StringZilla——将 C、C++、CUDA、Python和 Go 的字符串速度最高提升 100 倍

StringZilla项目介绍

字符串是每种编程语言在软件而非硬件中实现的第一个基础数据类型,因此专用的 CPU 指令很少——而且现有的指令也几乎不理想。这就是为什么大多数语言依赖 C 标准库(libc)来进行字符串操作,而尽管名为“标准”,它最热的代码却是用手工优化的汇编语言写的。它确实利用了 SIMD,但并不完美。:one: 即使是在普遍的硬件上——超过十亿个 64 位 ARM CPU——像 strstrmemmem 这样的例程最多只能达到可用吞吐量的三分之一。:two: SIMD 覆盖不均:快速前向扫描并不能保证快速反向搜索,哈希和大小写映射甚至不在标准之内。:three: 很多高级语言根本无法依赖 libc,因为它们的字符串不是以空字符结尾的——甚至可能包含嵌入式零字节。这就是 StringZilla 存在的原因:在每个现代平台、操作系统和编程语言上都能实现可预测的高性能。

StringZilla 是字符串库中的哥斯拉,利用 SIMD 和 SWAR 在现代 CPU 和 GPU 上加速二进制和 UTF-8 字符串操作。它在 C、C++、Rust、Python 等多种语言中可将 CPU 吞吐量提高多达 10 倍,并且比现有的 GPU 内核快多达 100 倍,涵盖了广泛的功能。它加速精确和模糊字符串匹配、哈希、编辑距离计算、排序,提供无需分配的惰性求值智能迭代器,甚至还有随机字符串生成器。

这是给谁用的?

  • 对于解析大型数据集的数据工程师,例如 CommonCrawl、RedPajama 或 LAION。
  • 针对在应用程序和服务中优化字符串的软件工程师。
  • 对于寻找 USearch 编辑距离的生物信息学家和搜索工程师。
  • 对于数据库管理系统开发人员,优化 LIKEORDER BYGROUP BY 操作。
  • 对于硬件设计人员来说,需要一个 SWAR 基准来实现字符串处理功能。
  • 对于学习 SIMD/SWAR 应用到非数据并行操作的学生。

项目地址

对DBMS系统的帮助:

StringZilla 能为 DBMS 提供核心助力的原因,在于它从底层加速了 DBMS 中 LIKE、ORDER BY、GROUP BY 等高频操作依赖的字符串处理逻辑,直接解决这些操作的性能瓶颈(CPU 计算效率低、内存 / 磁盘 I/O 开销大)。具体可以从三类关键操作的优化场景展开:

  1. 大幅提升 LIKE 模糊查询的匹配效率
    LIKE 操作的核心是字符串模式匹配,这正是 StringZilla 的强项。
    • 传统痛点:传统 DBMS 依赖 C 标准库的字符串匹配函数(如 strstr),这类函数多为单字符遍历,对 %xxx% 这类任意模糊匹配,只能全表扫描 + 逐行比对,CPU 利用率低;即使是 xxx% 前缀匹配,若涉及 UTF-8 多字节字符,字符边界判断也会额外消耗性能。
    • StringZilla 的优化逻辑:
  2. 它基于 SIMD(单指令多数据)和 SWAR 技术,可一次性对数十个字符进行批量比对,将字符串匹配的吞吐量提升数倍甚至数十倍。例如在处理 UTF-8 字符串的模糊匹配时,能高效处理多字节字符的边界检测,避免逐字节校验的开销。
  3. 支持快速的 子串查找、大小写不敏感匹配,这正好对应 DBMS 中 LIKE ‘xxx%’、ILIKE ‘XXX’ 等常见需求,减少 CPU 在字符串比对上的耗时,间接降低全表扫描时的资源消耗。
  4. 加速 ORDER BY 中的字符串排序
    当 ORDER BY 的排序字段是字符串类型(如 ORDER BY username)时,排序的核心开销是字符串的字典序比较。
    • 传统痛点:字符串比较是典型的 “逐字符对比” 操作,数据量大时,排序的时间复杂度会显著上升;若涉及 UTF-8 字符的本地化排序(如中文拼音排序),还需额外的字符转换开销,容易触发磁盘文件排序(Filesort)。
    • StringZilla 的优化逻辑:
  5. 提供 SIMD 加速的字符串比较函数,可并行对比多个字符,大幅降低单次字符串比较的耗时。例如在排序大量字符串时,比较操作的效率提升会直接减少内存排序的时间,甚至避免磁盘文件排序的触发。
  6. 支持高效的 UTF-8 字符处理,无需额外的字符编码转换,直接对原生 UTF-8 字符串进行排序比较,适配 DBMS 对多语言字符串排序的需求。
  7. 降低 GROUP BY 分组聚合的计算开销
    GROUP BY 针对字符串字段分组时(如 GROUP BY email_domain),核心步骤是 字符串哈希计算 和 分组去重。
    • 传统痛点:传统字符串哈希函数(如 djb2)是单字符迭代计算,哈希冲突率较高;分组时需要频繁将字符串哈希值与已有的分组哈希表比对,冲突处理会增加额外开销。
    • StringZilla 的优化逻辑:
  8. 提供 高速的字符串哈希函数,基于 SIMD 并行计算字符串的哈希值,计算速度远超传统哈希函数,且哈希分布更均匀,减少冲突概率。
  9. 支持快速的 字符串相等性校验,在分组去重时,可快速判断两个字符串是否完全一致,提升分组聚合的效率。
  10. 其他通用优势:轻量、跨平台、易集成
    • 轻量级架构:StringZilla 是单头文件的 C 库 + 多语言绑定,DBMS 开发者可以直接嵌入源码,无需引入复杂的依赖,对 DBMS 的体积和部署无额外负担。
    • 跨架构 / 编码支持:支持 x86、ARM 等主流 CPU 架构,兼容 UTF-8、ASCII 等编码,适配 DBMS 在不同硬件环境和多语言场景下的部署需求。
    • GPU 后端扩展:StringZilla 的 StringZillas 层支持并行 CPU/GPU 后端,对于大规模数据的字符串处理(如数据仓库的批量查询),可进一步利用 GPU 的并行计算能力,突破 CPU 性能瓶颈。
    总结
    DBMS 的 LIKE、ORDER BY、GROUP BY 操作,本质上都依赖大量的字符串处理(匹配、比较、哈希)。StringZilla 从底层用 SIMD/SWAR 技术重构了这些核心操作的执行逻辑,以更低的 CPU 开销、更高的并行度,提升字符串处理效率,最终帮助 DBMS 降低查询延迟、提高吞吐量。

有大佬把代码搬运到国内了:
https://gitee.com/tjopenlab/StringZilla