Redis K/V 存储引擎的 RVV 向量化优化
项目描述
Redis(Remote Dictionary Server)是目前全球最受欢迎的开源、内存中数据结构存储系统。它通常被用作数据库、缓存、消息队列(Broker)和流处理引擎。
Redis 作为高性能的内存键值数据库,其核心瓶颈之一在于网络输入缓冲区的协议解析,比如,Redis 采用 RESP(REdis Serialization Protocol)文本协议,服务端在处理请求时,需要频繁执行单字节循环扫描,以查找控制字符(如 *、$)及换行符(\r\n)。在传统的标量处理器上,这种串行字符匹配消耗了大量的 CPU 周期。
RISC-V Vector(RVV 1.0)扩展提供了强大的单指令多数据(SIMD)并行处理能力,本题要求参赛者将 Redis 完整适配至 RISC-V 平台,并利用 RVV 1.0 向量指令对 Redis 的 RESP 协议解析、RDB/AOF 压缩、Dict 哈 希计算等核心模块进行性能加速,推动 RISC-V 在数据库向量化方向的应用落地。
- 目标架构:RISC-V(RV64GCV,支持 RVV 1.0)
- 推荐测试环境:QEMU
virt机器(-cpu rv64,v=true,vlen=256)或真实 RISC-V 开发板 - 验证平台:蓝芯 LX5000 开发板
评分要求
必做任务
优化后的代码必须完全兼容 RESP 协议规范,能够正确解析包括单行字符串、错误信息、整数、大块字符串(Bulk Strings)和数组在内的所有标准 Redis 命令报文。
-
必须使用 RVV 1.0 Intrinsic 函数,可以辅助少量 RISC-V 内联汇编进行优化
-
支持不同 VLEN(128/256/512 bit)的自适应实现,可利用 RVV 的
vsetvl灵活向量长度特性 -
可实现自动向量长度调优(VLEN 探测 + 运行时分发)
-
允许合并或重构原有的循环结构,但不得改变原解析状态机的业务逻辑边界
-
禁止使用多线程优化
-
验证文档:记录测试方案,用于组委会验证参赛选手的优化成果
性能要求及正确性验证
- 评测指标:基础测试、高并发测试、高Value测试、管道测试、持久化测试
- 能正确运行自带的回归测试集(对比 ARM 平台的测试结果)
- 相比于 memtier_benchmark 标量版本在验证平台的基线测试结果,性能需提升至少 30%
- 性能提升指标包括: GET/SET QPS、P99 延迟等
- 现有数据库内核、字符串核心以及协议解析函数的 RVV 向量化占比 >=70%
注意事项
- 请确保遵循相关的开源协议和版权规范。
- 参赛者需要自行准备开发环境。
- 禁止直接搬运已有第三方 RISC-V Redis 移植代码,须自主实现或明确标注引用来源。
- 若使用 AI 辅助编写代码,需在提交报告中说明使用方式及占比。
- 需符合现有 Redis 代码规范。
参考资料
| 资源 | 链接 |
|---|---|
| Redis 8.8.0 源码 | https://github.com/redis/redis/tree/8.8.0 |
| memtier_benchmark | https://github.com/redis/memtier_benchmark/releases/tag/2.4.1 |
| RISC-V RVV 1.0 规范 | https://github.com/riscv/riscv-v-spec |
| RISC-V RVV 1.0 规范 | https://github.com/riscv/riscv-v-spec |
| RVV Intrinsics 参考手册 | https://github.com/riscv-non-isa/rvv-intrinsic-doc |
| RISC-V GNU 工具链 | https://github.com/riscv-collab/riscv-gnu-toolchain |
| QEMU RISC-V 文档 | https://www.qemu.org/docs/master/system/target-riscv.html |
提交说明
1. 提交仓库
参赛者需将代码提交至以下仓库:
https://github.com/rv2036/rvspoc-S2603-redis2. 提交方式
请通过 Pull Request(PR) 的方式将结果提交至上述仓库。
下文中所提及的「PR」均指针对该仓库创建的 Pull Request。
3. PR 中需包含的内容
创建 PR 时, 必须提供用于复现移植及优化结果的全部必要内容,包括但不限于:
- 完整的源代码或二进制文件(* 详见第 5 条说明)
- 配置文件(若有)
- 依赖的库文件(若有)
- 补丁文件(若有)
- 其他对验证提交结果所必需的内容
4. 必须附带的说明文件
创建 PR 时,须同时附带一份说明文件,内容应包含用于验证优化成果的详细步骤与信息,包括但不限于:
- 验证平台说明:是否限定特定平台?若限定,请注明操作系统名称、版本及安装说明
- 依赖库说明:是否限定特定依赖库?若限定,请注明相关信息及安装说明
- 程序编译及安装步骤
- 程序运行步骤
- 程序运行结果
- 其他对验证提交结果所必需的信息
5. 关于源代码的特别说明(优化类赛题)
针对第 3 条中「完整的源代码或二进制文件」一项,补充说明如下:
- 若参赛者在比赛截止时间前仅提交了二进制文件用于结果验证,则必须在之后通过 PR 的方式补充提交完整的源代码,方可视为完成本赛题。
- 补充提交的完 整源代码必须与先前提交的二进制文件 100% 对应(即由该源代码编译生成)。
- 比赛截止时间后提交的源代码,其验证结果不计入比赛成绩,组委会仅会核实其是否与对应的二进制文件一致。
6. 成绩认定时间节点
组委会将在比赛结束后(即 2026 年 8 月 31 日 (AoE) 之后)统一对提交内容进行验证。
自该时间点起,新增或修改的 PR 内容均不计入比赛成绩。
获胜条件:精度符合产出要求,性能评分最高的选手。
7. 评判与争议处理
比赛组委会与赞助商将共同委派技术代表,组成 「联合评判组」。
评判组的职责包括:
- 对比赛过程及评判结果进行技术评判
- 受理并处理所有与比赛相关的争议
验收说明
- 2026 年 9 月 20 日后,由 RVSPOC 组委会公布。
- 由于赛题的开放性和软件的复杂性,赛题发布时可能存在未解释或需要修正的部分。针对未考虑到的方面,随着比赛进程的推进可能根据选手的反馈会有调整,请保持对赛事网站的关注。最终解释权归属于比赛的赛题评审委员会。
知识产权及开源协议要求
所有参赛结果要求开源,并提交至主办方指定仓库。参赛者(作者)持有作品的所有权。主办方鼓励参赛者将结果回馈贡献至 upstream。