Chisel编译时间优化实例——将香山的双核RTL生成时间从36分钟压缩到7分钟

背景 自从香山新后端合并后,Chisel编译时间大幅增加,特别是在双核的DefaultConfig下,在我的13900K机器+OpenJDK 11的条件下,FIR的生成时间已经达到的34分钟,具体可以见该issue,而在之前,FIR生成时间仅为2分钟不到。这样的编译时间大幅增加导致开发流程不再敏捷,大幅时间浪费在等待编译上。 观察 我首先怀疑是电路规模也存在大幅增加,因此我首先观测了FIR的大小。通过git checkout或git reset –hard使用新后端合并前的commit进行观察可发现,在使用DefaultConfig双核的情况下,旧后端的FIR大小为1.4GB,新后端为2.4GB。尽管FIR大小不能完全反映电路大小,但时间并不应该是小于2分钟至34分钟的区别。 因此,我怀疑问题出在以下两点: Scala的写法不同导致了CPU微架构层面出现了巨大的IPC差异 存在大量重复的代码执行,而RTL的生成过程中存在非常多可以复用的部分 Profiling 鉴于Scala最终也会在JVM里执行,我首先调研了一些Java的Profiling工具,最后发现我们常用的IDEA idea自带该功能。使用方法非常简单: 在打开的Profile窗口后,去终端执行编译(例如 make verilog NUM_CORES=2…

让树莓派4 WireGuard 性能从 400Mbps 飞涨到 1Gbps

背景 由于学校机房依然需要网络认证,因此我采用了使用 WireGuard 从别处接入网络的方式。为了评估放在学校机房的软路由需要什么样的性能才足够跑满千兆大包 WireGuard ,上周末写了个 WireGuard Benchmark 脚本 来评估 CPU 以及 Kernel 网络栈处理 WireGuard 的性能。为了方便评估以取得更多的结果,我采用 network namspace…

从CPU RTL到GCC expmed Cost Model

背景 最近和朋友讨论一个编码算法的问题的时候意外发现,当前 RISC-V 的 GCC 即使使用-O3优化的情况下,也不会将 divide by const 优化为Barrett reduction。但我测试了默认参数的 x86 、 aarch64 、 mips32 ,均存在该优化。且通常来说, CPU…

自己家的全屋光纤与无线覆盖布网实战

原则与实战结果 自己家今年搬入了新居,对于我来说一件十分重要的事情就是规划网络布线了。 我计划按照以下原则布置网络: 每个房间都有4芯光纤,确保以太网使用2芯之后还有2芯可用,从而可以接HDMI光端机等设备以及出现断芯等情况后可以替换。 有人活动的位置5GHz WiFi RSSI <= -65 dBm 尽可能不出现明线 先给大家看一下最终的布网效果图: 这张图里大家或许或看出很多疑惑的不完美部分,其中有一部分来源于开发商以及装修公司的历史遗留问题,我会在后续详细解释。 光纤布网 光纤选型 光纤从模式上分为:单模光纤、多模光纤 光纤从形态上分为:皮线、室内光缆、室外光缆、隐形光纤 光纤从接口上分为:LC-UPC、LC-APC、SC-UPC、SC-APC等等(该参数在选购光纤时不需要考虑,后续可以熔接不同的接头)…

Back to Top