能否做一期关于不同编译器代码速度的评测？

[xicongye]

首先，我对代码速度的理解是：用不同的编译器，例如clang、gcc，编译同一个Benchmark，例如Coremark，然后在同样的测试环境中（例如Spike、QEMU）比较Benchmark的得分。
我用Coremark分别测试了Clang9.0.0和GCC9.2.0在不同优化选项的情况下，在Spike上面的跑分情况，设定CPI=1（不考虑Cache miss），时钟频率为48MHz，单核，得到的Coremark跑分如下：

	Clang9.0.0-O2	Clang9.0.0-O3	Clang9.0.0-Os	Gcc9.2.0-O2	Gcc9.2.0-O3	Gcc9.2.0-Os
RV32 CodeSpeed	2.752	2.758	2.58	3.201	3.256	2.645
RV64 CodeSpeed	2.571	2.584	2.427	3.197	3.246	2.683

从上表可以看到，Clang除了Os优化选项和GCC比较接近外，其他选项基本上只有GCC性能的80%左右。

BTW，还有一些问题：

1. 我不清楚这样的评测是否具有意义，毕竟没有考虑数据冲突、结构冲突、Cache miss、多发射、多核等这些情况，关于具体的测试步骤和测试环境可能还需要特别强调？
2. 关于Benchmark的选择，Coremark是否具有代表性？或许可以选择一些更好的测试程序？例如：https://github.com/embench/embench-iot

[Wei Wu]

Hi @xicongye

收到，这个我们有后续考虑放进来的。

生成的代码的速度，本身就是我们关注的重点。在MCU领域比较看重 codesize，在更一般的环境下， speed 更加被看重。我们（永恒天平项目）目前还在采购具体的硬件平台，后续会陆续放出结果。

代码的执行速度（性能）一般是放在具体的硬件上（不同硬件微架构不同）进行测试的，一般是测试具体的某一款CPU、编译系统及其内存子系统。测试 Spike 的数据有参考的意义，一方面，同样的模拟器，不同的代码跑出来的速度的偏序性质我们一般认为是保持的（aka 在模拟器上A比B快，那么在真实硬件上A很可能比B快）。另一方面，Spike跟QEMU可能都不是cycle级别的模拟器，测试的速度差异很可能跟Spike自身的实现方式有关（测试目标发生了变化）

后续有新的测试结果了我会贴在这里。

[Wei Wu]

关于Benchmark的选择，Coremark是否具有代表性？或许可以选择一些更好的测试程序？例如：https://github.com/embench/embench-iot

感谢提供。我看下。免费的后续我们都可以纳入进来😄 （收费的要申请采购，流程长一点

[Wei Wu]

ok 现在是2021年，我们拥有了性能更好一点（但是也没有好到哪里去）的 SiFive Unmatched 、 全志哪吒D1开发板 等。今年可以开始做一些性能对比的工作了。

[Wei Wu]

Update：

2021 年 CI Farm 完成了基础的部署，但是性能评测的 PTS 还没有完成。计划在 2022 年上半年完成。

[Wei Wu]

代码测评后续持续通过性能跟踪小队的PTS项目进行，请留意后续的PLCT开源进展。