通往高速的次元

恭喜你! 你亲手一砖一瓦搭建的计算机世界可以运行真实的程序, 确实是一个了不起的成就! 不过通常来说, 仙剑奇侠传会运行得比较慢, 现在是时候对NEMU进行优化了.

说起优化, 不知道你有没有类似的经历: 辛辛苦苦优化了一段代码, 结果发现程序的性能并没有得到明显的提升. 事实上, Amdahl's law早就看穿了这一切: 如果优化之前的这段代码只占程序运行总时间的很小比例, 即使这段代码的性能被优化了成千上万倍, 程序的总体性能也不会有明显的提升. 如果把上述情况反过来, Amdahl's law就会告诉我们并行技术的理论极限: 如果一个任务有5%的时间只能串行完成(例如初始化), 那么即使使用成千上万个核来进行并行处理, 完成这个任务所需要的时间最多快20倍.

跑题了... 总之, 盲目对代码进行优化并不是一种合理的做法. 好钢要用在刀刃上, Amdahl's law给你最直接的启示, 就是要优化热点代码, 也就是那些占程序运行时间最多的代码. KISS法则告诉你, 不要在一开始追求绝对的完美, 一个原因就是, 在整个系统完成之前, 你根本就不知道系统的性能瓶颈会出现在哪一个模块中. 你一开始辛辛苦苦追求的完美, 对整个系统的性能提升也许只是九牛一毛, 根本不值得你花费这么多时间. 从这方面来说, 我们不得不承认KISS法则还是很有先见之明的.

那么怎样才能找到热点代码呢? 一边盯着代码, 一边想"我认为...", "我觉得...", 这可不是什么靠谱的做法. 最可靠的方法当然是把程序运行一遍, 对每处代码的运行时间进行统计. Profiler(性能剖析工具)就是专门做这些事情的.

GNU/Linux内核提供了性能剖析工具perf, 可以方便地收集程序运行的信息. 通过运行perf record命令进行信息收集:

perf record nemu/build/nemu nanos-lite/build/nanos-lite-x86-nemu.bin

如果运行时发现类似如下错误:

/usr/bin/perf: line 24: exec: perf_4.9: not found
E: linux-tools-4.9 is not installed.

请安装linux-tools:

apt-get install linux-tools

通过perf record命令运行NEMU后, perf会在NEMU的运行过程中收集性能数据. 当NEMU运行结束后, perf会生成一个名为perf.data的文件, 这个文件记录了收集的性能数据. 运行命令perf report可以查看性能数据, 从而得知NEMU的性能瓶颈.

性能瓶颈的来源

Profiler可以找出实现过程中引入的性能问题, 但却几乎无法找出由设计引入的性能问题. NEMU毕竟是一个教学模拟器, 当设计和性能有冲突时, 为了达到教学目的, 通常会偏向选择易于教学的设计. 这意味着, 如果不从设计上作改动, NEMU的性能就无法突破上述取舍造成的障壁. 纵观NEMU的设计, 你能发现有哪些可能的性能瓶颈吗?

results matching ""

    No results matching ""