本文内容是ADMS2025（VLDB 2025 WorkShop）的后日谈
由于工作繁忙，本文内容基本属于想到啥就说啥😂，以后有机会再系统整理下
起因
对于RISC-V的兴趣是从关注PLCT实验室吴伟老师的B站号开始的，外加年初的时候给DuckDB的仓库加了RISC-V的CI Check（详见：当DuckDB遇上RISC-V），想着找个机会把玩下MilkV Jupiter（虽然事实是年底就弃坑了bushi），在导师的建议下，去做了对于数据库在RISC-V生态的调查
能被VLDB Workshop接收这事情之前是真没想过😂很高兴导师能给我这个机会去伦敦的VLDB 2025去学习观摩
这个话题很有意思，我从吴伟老师的视频知道，PLCT实验室的很多大佬在做GCC & LLVM编译器对RISC-V的适配工作，而这些工具链的移植在这几年趋于成熟（21世纪的20年代），这些工作使得数据库软件理论上可以在RISC-V架构的Linux上运行（BSD其实也可以，但这个生态现在来看过于小众，因此不作讨论）
既然理论上是可行的，那就会有以下两个问题：
- 数据库是否能顺利移植/提供支持到RISC-V平台上？
- 编译器优化是否能最大发挥数据库运行的潜力？
RISC-V上数据库兼容性调查
对于问题1，结论是：开源数据库由于参与人数众多，或多或少都有提供文档/相关问答以解决数据库在RISC-V上的运行问题。而商业闭源数据库基本对于RISC-V态度十分冷淡——我对这个结果并不觉得奇怪，因为适配RISC-V在商业上确实不能带来明显收益，这个问题在后面和ARM的比较就能看到了
编译器参数对于数据库性能的影响
这个问题就不得不提到RISC-V的ISA设计：
RISC-V采用分层ISA模型，核心是基础指令集（Base ISA），其他功能通过可选扩展实现
对此可以控制变量设计实验：通过修改编译参数中的标准扩展的使用，从而验证标准扩展对于数据库的影响
论文选择了TPC-H进行测试，核心是衡量OLAP负载的性能影响
但就结论而言，我的看法是：标准扩展的使用与否，对于数据库性能的影响微乎其微
在设想当中，影响最大的应该是V Extension，该扩展给予了RISC-V SIMD运行的能力，而现代的OLAP数据库（DuckDB）基于自动向量化执行，理论上应该能得到很大的性能提升
但很遗憾，实验结果表明：在RISC-V上开启/关闭V扩展并不会对DuckDB的性能带来多大影响
于是我猜想可能是编译器的实现问题，为此我同时比较了Clang 20和GCC 14在开启/关闭 V-Extension对于DuckDB TPC-H负载的影响，结果是各有优劣，但也不会有特别大的影响
与ARM架构的比较
费劲说了半天，那对于大家而言，可能还有一个非常灵魂的问题：我为什么要选择RISC-V架构的芯片？😂ARM架构的芯片它不好么
于是我在文章中做了最后一个测试：MilkV-Jupiter 16GB版本的架构差不多1000RMB，差不多的价格我可以买到树莓派4/5，拉出来做个测验不过分吧😂
于是我们就看到了以下场面：同样的TPC-H负载，树莓派普遍要比MilkV Jupiter快1-2倍
这里面问题很多，从软件到硬件都有：
- 硬件上，树莓派5的Broadcom BCM2712运行频率2.4Ghz，而且支持乱序运行，而MilkV Jupiter的Spacemit M1频率只有1.8Ghz，且只支持顺序运行
- 软件上，ARM的编译器无疑会更加成熟，而RISC-V上的编译器从前面的实验结果上来看，优化效果存疑
我认为最适合用于和树莓派对比的应该是Milk-V Oasis，但这玩意因为算能(Sophgo)吃制裁，核心的SG2380难产了
也许有的会问为什么不用SiFive的P550 ——那颗CPU支持乱序执行，且性能应该是高于SpaceMIT M1的，但那颗U不支持RVV 1.0，所以被排除了
结语
你现在问我RISC-V芯片未来如何，我会说：只有天知道😂
实验结果和当初设想的截然不同，而且短期内似乎并没有很好的解决方案
但你要是问我收获有多少，那我会说：学到了很多，收获很大
- 首先，我要感谢帮我改论文格式的导师和绘图的同学，如果没有他们的帮助，这篇Paper极有可能因为格式问题被拒
- 第一次体验到连续坐12小时的红眼航班经济舱是什么体验😂从南半球到北半球，从东半球到西半球，下飞机倒头就睡
- 在VLDB 2025上见到了Andy与Naumann大佬，也见到不少老师和做数据库的同学，和大家的交流让我受益匪浅
- 通过这篇Paper，我和PLCT的大佬们搭上了线，可能有些新的Idea去改善论文的实验，但今年应该是没机会了
也许这就是科研的魅力所在？论文的结果是一方面，但参与会议和论文写作的经历也是不可或缺的一环