一个问题的BF答案

很禽兽的一个问题：怎么样证明一个处理器已经是最快的运行一个程序了。

一个很禽兽的答案：用汇编写，确定最好的流水线调度和最好的局部性。

这个问题的一些延伸：

IPC能不能用来说明问题，可以，但是要是cpu-intense程序，或者是io-intensive的cpu-intensive部分。

如果从程序运行上看不出什么效果呢？

那只能说cpu太烂了，或者程序太超前了，反正是瘦驴拉大磨。

这又提出一个新的问题，编译器对超前的程序总是无可奈何？

这个问题就很大了，要调整程序结构和实现，使之可以在慢的cpu上运行的更快？

还是调整编译器，使之把程序像更慢的cpu上优化？

其实我真正想知道的是：怎么样才能知道或者说诊断，一个程序在运行过程中的瓶颈出在什么地方。

或者说，这个程序有没有很好的利用cpu呢。

这需要benchmark数据来刻画，但同时也需要一个interpreter来给程序员更明显的指示。

进一步的问题是，benchmark刻画出来的数据，是cpu的运行时状态，也是程序运行时的状态。

但是这里所谓的程序，是程序员的杰作，也是编译器的，因此这些数据刻画出的瓶颈，是程序员的也是编译器的。

这就是最大的问题所在了，怎么样刻画这个瓶颈，可以让这个职责更明显呢。

现在，直白的方法就是知道编译器对这段热点瓶颈做了什么，你对她的hotspot做了什么？

但是这之间仍然饱含巨量的人工分析和经验判断，对于大规模工业化过程之能说是，

杯水车薪。

当然问题没有这么悲观，一个很乐观的规律是，任何自动化方法都是对人工分析和经验判断的抽象。

所以说，万事开头，还是要从那个人工分析开始的。

就是要先想办法把分析工具建立起来，这个基本已经有80%的完工了。

但是很大一部分工作在于，使用该工具进行实际的性能分析，这个看上去就没那么容易了，估计一两周的工作量都算是快的。

但是由此产生出一个YY高手的想法，那就是根据前面的问题，我们可以提出一种混合式的的编译器。

该编译器接近调试器，可以实时编译，有利于程序员一边优化一边评判最终性能。

这个想法听上去很想profile driven optimizing，只不过是programmer driven。

思路到这里转了一个圈。

既然是要根据profile的结果来分析程序和优化选项进而改进，那为什么不能直接把

profile的结果反馈给编译器，形成一个异步的，离线的反馈环节。

这不就是profile driven optimizing嘛。

但是这个问题的之能解决一半的问题，那就是compiler端的问题，而实际上，根据profile的结果，来给程序员提出合理的建议，

也是另外一个反馈环节，而这个环节同compiler的环节一样，都比较难达到很好的自动化。

进一步的思考会发现，其实对于cpu和profile数据而言，没有什么完美不完美，倒是IPC可以说明一些问题。

更多的，我们希望，通过其他各项数据得到一个完整的刻划，这个本身就很难。