Research

出自phdcomics.

不要问我这两个问题哦….

搞computer architecture，parallel processing，或者compiler之类的，无论具体的方向是什么，都很难逃过benchmarking这一关。读这一行的PhD真得是比较郁闷。要是正好逢上group开始从头搭建平台，好几年可能就全耗在工程上了，这部分工作时间长，辛苦，但是谈不上多少research，因为nothing new。几年下来，看看已经呆了好多年了，急于毕业，开始找topic，赶紧做。运气不错的话，能做到最后。这时候总要证明你的东西有优点吧，怎么证明？只能做实验。用什么做实验？答案 — 跑benchmark。

而benchmark这块，恰恰一点也不容易。就好像绕着田径场跑长跑，跑着跑着忘了数圈数了，自己觉得差不多，最后加速冲刺了，冲到了头，裁判告诉你，还有几圈没跑，哭都没力气哭。

benchmarking为什么不容易？第一，因为benchmark很少。说白了，就是SPEC，NAS，SPLASH2寥寥几种。这几个并整个学界当作普适得来使用，什么都用这个来验证有效性。你要是没跑这几个，top conference就很难收你的paper。但是，事实上，architecture，尤其是parellel architecture非常的diverse。再加上上面跑得软件环境，更是千变万化。岂是，几个或者几组benchmark能涵盖得了的。所以，这几个虽然被当作普适，实际用起来未必能符合研究者的具体目的。第二，程序语言，种类繁多。而这一行里头，最主要的是fortran和C。目前来说，大家当然愿意用C了。可是偏偏不少benchmark就是十几年前用fortran写好了，放在那里，就是没C的版本，比如著名的Sweep3D。逼于无奈，很多人用f2c来硬转。f2c这个程序本身就不知道多久没更新过了，转出来的东西基本没有可读性，这条路不值得提倡。第三，稍微大一点的benchmark，都有应用的专业背景知识在里头。比如NAS，就是computaional fluid dynamics，听听就吓人。任何一个benchmark，你都要去硬着头皮了解相应的知识，然后硬着头皮去看code，没有一两个月（保守估计），根本不可能真正纯熟。然后再考虑为我所用。第四，这些benchmark写成的时候，都是按照作者当时使用的programming model来写的。而你研究使用的model可能完全不同，这些benchmark未必是合适的。就算应用本身是合适的，也需要大量的工作来改写。这就又回到第三条，你需要懂这个应用。

那些牛校的牛research group强在什么地方？其他不说，在平台和benchmark方面的积累和经验和熟悉，就是一般学校的学生需要很长时间才能达到的，或者很难达到的。

报怨也改变不了现状，就是随便报怨几句，算是推卸点责任吧。