Research

Research

出自phdcomics.

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

[tags]PhD, advice comics,thesis,PhDComics[/tags]

Tags: , , ,

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

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

benchmarking为什么不容易?第一,因为benchmark很少。说白了,就是SPECNASSPLASH2寥寥几种。这几个并整个学界当作普适得来使用,什么都用这个来验证有效性。你要是没跑这几个,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方面的积累和经验和熟悉,就是一般学校的学生需要很长时间才能达到的,或者很难达到的。

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

[tags]benchmarking, store benchmark[/tags]

Tags: , ,