这一章的内容刚好让我联想到以前参加过的超算大赛，优化是一个需要从理论层面直到硬件层面多个角度同时考虑的系统工程。作者也提到了设计层面的问题，有时候一个好的设计恰恰能避免很多问题，譬如说遇到一个问题，你看了一眼就开始写DFS，其实那个问题有规律可循，最终可以得到一条优雅的通项公式。
问题探讨
4.这个题目就是说，比如程序的可靠性，一开始就要考虑进去，不然后期很难加上。这让我想到我曾经做过的一个项目，当时因为根本没有考虑到调试的问题，程序是用脚本语言写的，导致后期的维护任务异常艰巨。
6.这得看需求，在超算大赛时，我们优化的都是些科学或者大型工程软件，有精度上的要求，只要满足精度，怎么搞都可以。也就是说，如果精度允许，有几个小Bug无伤大雅。但是如果不能满足呢？再快又如何？古训还是得记得，不过我们也可以依情况行事。
摘录
Gordon Bell:「计算机系统中最廉价、最快速且最可靠的元件是根本不存在的」
如果仅需要较小的加速。就对效果最佳的层面做改进。对于效率，大多数程序员都有自己的下意识反应：「改变算法」或「调整排队规则」会脱口而出。决定在某一特定层面着手之前，请先考虑一下所有可能的设计层面，然后选择「性价比」最高的哪一个：投入最小的精力就可以获得最大的加速系数的那个设计层面。
如果需要较大的加速，就对多个层面做改进。要取得Appel那样的大幅加速，必须从各个不同的方向对问题进行深入研究，这通常需要付出巨大的努力。如果在任一设计层面上的改进都独立于其他层面的改进，那么各个层面上的加速系数可以相乘。