small change to perf idea

_posts/2024-04-14-riscv-perf-idea.md

@@ -16,9 +16,9 @@ tags:
 
 时间回到2022年，那时我们能买到的板子还是sifive unmatched。这是一款in-order的cpu，甚至连内存prefetcher都没有，我们对比了unmatched和一款老的atom cpu，性能特别是内存带宽差距非常大。性能调试手段也比较有限，比如PMU不够丰富，也不支持PMU counter overflow，为了作热点采样我们只能通过perf的software event。我在RISC-V Summit 2022上讲了Advance the Performance Analysis on RISC-V这个主题，只收到了零星的一些反馈，说明在那个时候性能还不是riscv生态的关注重点，但是这作为riscv社区第一次尝试至少是较早的尝试，我认为是有意义的。对于我们自己来说这也是必要的，是我们去了解riscv生态的第一步。在此期间我们做了:
 
-* 从benchmark出发，并最终选定并移植了Linux Kernel Performance (LKP)到riscv上。我们的目标并不只是性能测试，更多的是性能分析和优化从而推进riscv生态建设，所以lkp集成的一些性能分析脚本也是我们比较看重的，这也是当时选择lkp而不是phronix的原因。刚开始的时候我们选择的benchmark更偏向硬件的性能，比如lmbench/stream/coremark等，当然也分析了unixbench等偏os的测试。
+* 搭建测试框架。从benchmark出发，并最终选定并移植了Linux Kernel Performance (LKP)到riscv上。我们的目标并不只是性能测试，更多的是性能分析和优化从而推进riscv生态建设，所以lkp集成的一些性能分析脚本也是我们比较看重的，这也是当时选择lkp而不是phronix的原因。刚开始的时候我们选择的benchmark更偏向硬件的性能，比如lmbench/stream/coremark等，当然也分析了unixbench等偏os的测试。
 * 调研了当时在performance tools上的软硬件生态，包括Linux内核对性能工具的支持程度，riscv pmu相关的extensions，以及riscv spec本身的一些性能特性，比如ipi放在M mode的性能影响。另外，performance tools不只存在于真实硬件上，qemu以及其他很多工具同样可以分析部分性能问题
-* 出于兴趣我也分析了in-order vs out-of-order, memory prefetcher等对性能的影响。
+* 出于兴趣也分析了in-order vs out-of-order, memory prefetcher等对性能的影响。
 
 后面基于t-head c910/c920的产品大量上市，包括sophgo sg2042和lichee pi 4a等，我认为t-head这款产品非常成功，至少把riscv开发版普及到下一个level。因为c910有一个相对不错的性能，riscv变得更加有趣起来。
 
@@ -33,7 +33,7 @@ tags:
 
 * 目前大部分软件优化是基于qemu来开发和验证的，比如gcc关于vector的优化，主要是靠统计指令数来验证优化效果。很明显这只是迫于现实条件约束而不是最优选择，动态指令条数并不完全和性能正相关，况且不同rvv硬件实现也可能会有不同效果
 * 需要有测试框架能及时发现performance regression，现在大部分软件在riscv上都没有性能回归测试，此时搭建一个能用于不同软件的性能回归测试会有很大收益
-* 除了regression，展示riscv software优化进展同样重要，这是riscv社区从用户传递正能量的有效手段
+* 除了regression，展示riscv software优化进展同样重要，这是riscv社区从用户传递正能量的有效手段。同时，也可以收集到优化方法的数据库，甚至可以将这些优化应用到不同的开源软件。
 * 极大提高运行这个perf ci框架的组织社区可见段，不管是RISE还是其他组织，可以很好地参与到各种开源社区
 
 接下来我相信riscv应用会迎来井喷，时间不会太久，到时各种软硬件优化的需求会出来，不像现在偏通用的优化，还有针对各种不同领域不同软件的优化，新的硬件扩展会出现，调试也需要越来越好的PMU和工具的支持。riscv会重走arm走过的路，但是走得更快，所以我们更早地做好准备。