系统与数据库2021rsg.ci.i.u-tokyo.ac.jp
开源 FPGA 优化的乱序 RISC-V 软处理器（2019）
An Open-Source FPGA-Optimized Out-of-Order RISC-V Soft Processor (2019)
进阶 · 约 90 分钟读完前置知识：计算机体系结构、乱序执行流水线、FPGA/RTL 设计基础
导读
这篇 2019 年的论文（FPT'19）介绍了一个开源、面向 FPGA 优化的乱序执行 RISC-V 软处理器。作者用 SystemVerilog 实现，目标是让软处理器在 FPGA 上也能获得接近高性能 CPU 的乱序执行能力，论文附带了架构描述和流水线可视化工具。
HN 关注点：开源高性能 RISC-V 软核的实现细节，以及乱序软处理器在 FPGA 上实际能达到的性能水平。
HN 评论精选
这几条评论里：支持 1 质疑 2 补充 1
支持推荐阅读论文本身，认为其架构描述很有价值
顶一下：如果你想知道这项工作为什么重要、作者想做什么，他们描述方法和架构的 PDF 非常值得一读。
Symmetry查看英文原文
To push this up from the comments, if you're interested in why this is important or what the authors are trying to do the PDF where they describe their approach and architecture is really interesting. http://www.rsg.ci.i.u-tokyo.ac.jp/members/shioya/pdfs/Mashimo-FPT'19.pdf
质疑质疑论文缺少性能量化数据，想知道与真实 CPU 的具体差距
有没有对"高性能"的量化？它显然会比真正的高性能 CPU（现代 x86-64）的 IPC 低很多，但差距有多大？和典型的移动处理器相比又如何？
CodesInChaos查看英文原文
Is there a quantification of "high performance"? It will obviously be much lower than the IPC of an actual high performance CPU (modern x86-64), but how big is the difference? And how does it compare to typical mobile processors?
补充批评 SiFive 用 Chisel 阻碍 RISC-V 推广，赞赏本项目用 SystemVerilog
很高兴他们用的是 SystemVerilog。我一直不理解 SiFive 为什么选 Chisel 作为 RTL 语言，我觉得这在悄悄拖慢 RISC-V 的采用。我认真尝试过理解 Chisel 的优势，但完全看不出来，Stack Overflow 上关于 Chisel 好处的回答简直令人尴尬。
choletentent查看英文原文
I am glad they are using System Verilog. It is hard for me to understand why SiFive chose Chisel as RTL language. I think that quietly slows down the RISC-V adoption. I honestly tried to understand the advantages of Chisel, but I can not see any. There is an answer on Stack Overflow regarding Chisel benefits, it is just embarrassing [1]. [1] https://stackoverflow.com/questions/53007782/what-benefits-does-chisel-offer-over-classic-hardware-description-languages
质疑根据可视化数据质疑实际 IPC 偏低，与乱序设计预期不符
Konata 流水线可视化器的 gif 显示大部分时间差不多每周期一条指令……很多片段甚至低到 0.2 条指令/周期。考虑到前端/后端流水线的数量，难道不该有更高的并行度吗？
londons_explore查看英文原文
The gif of the Konata pipeline visualizer seems to show pretty much one instruction per cycle most of the time... Many parts of the trace show as low as 0.2 instructions/cycle.. Wouldn't we expect much higher numbers (more parallelism) considering the number of frontend/backend pipelines?
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2021Hacker News 讨论帖239 分 · 74 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选