Daily Archives: January 20, 2007

程序员的十种级别(ZZ)

http://coscpp1.spaces.live.com/blog/cns!DEF1CF80E224B861!180.trak

第一级:神人。天资过人而又是技术狂热者同时还拥有过人的商业头脑,高瞻远瞩,技术过人,大器也。

第二级:高人。有天赋,技术过人但没有过人的商业头脑,通常此类人不是顶级黑客就是技术总监之流。

第三级:牛人。技术精湛,熟悉行业知识,敢于创新,有自己的公司和软件产品。

第四级:工头。技术精湛,有领导团队的能力,此类人大公司项目经理居多。

第五级:技术工人。技术精湛,熟悉行业知识但领导能力欠佳,此类人大多是系统分析员或资深程序员,基本上桀骜不逊,自视清高,不愿与一般技术人员为伍,在论坛上基本以高手面目出现。

第六级:熟练工人。技术有广度无深度,喜欢钻研但浅尝辄止。此类人大多为老程序员,其中一部分喜欢利用工具去查找网上有漏洞的服务器,干点坏事以获取成就感。如果心情好,在论坛上他们会回答菜鸟的大部分问题。此级别为软件苦力的重要组成部分。

第七级:工人。某些技术较熟练但缺乏深度和广度,此类人大多为程序员级别,经常在论坛上提问偶尔也回答菜鸟的问题。为软件产业苦力的主要组成部分。

第八级:菜鸟,入门时间不长,在论坛上会反复提问很初级的问题,有一种唐僧精神。虽然招人烦但基本很可爱。只要认真钻研,一两年后就能升到上一级。

第九:大忽悠。利用中国教育的弊病,顶着一顶高学历的帽子,在小公司混个软件部经理,设计不行,代码不行,只会胡乱支配下属,拍领导马屁,在领导面前胡吹海侃,把自己打扮成技术高手的模样。把勾心斗角的办公室文化引入技术部门,实在龌龊。

第十:驴或傻X。只会写SELECL语句就说自己精通Oracle,连寄存器有几种都不知道就说自己懂汇编,建议全部送到日本当产业工人,挣了日本人的钱还严重打击日本的软件业。

其中又以前两级和后两级最为难得,其余级别只要努力,皆有可能达到。

contention from smth(ZZ)

http://coscpp1.spaces.live.com/blog/cns!DEF1CF80E224B861!145.entry

 c++把开发效率和执行效率的折中工作交给了程序员。而且利用c++提供的新特性在执行效率没有显著降低的条件下可以大大节约开发和维护成本.

很正常,C语言语法结构本身有很多是同机器结构对应的,相比之下更容易的编译出高效率的汇编代码,而且由于许多os本身就是c实现的,因此,很多函数,特对别io函数基本上可以直接映射系统调用,而c++却把系统调用包装了很多层,调用的时候要经过多层解包,当然效率就慢了。
当然效率的使用也跟程序员写程序的方法有关,很多次看见某些程序员写的程序,很简单,就是把大约1万个数,push_back到一个vector中去,他就是很简单的用一个循环不停的push,最后运行效率当然是很慢了.然后就攻击说c++太慢了,而c很快。这其是只是一个c++的误用造成的。vector在push的时候,如果超过容量了,都会重新分配内存,然后在拷贝原有的东西,而用c的时候,一般都是一来就malloc一个很大的内存,其间只有一次内次分配操作,当然会快很大。一般在用vector,push大量数据的时候都要先设定一个大容量,这会快很多。

c++我觉得主要还是面向应用级的,它提供了一种开发效率、可维护性与执行效率间还算良好的平衡,当然,更主要的是它同c结合的很好,一些效率不高的地方可以用c来弥补,一般在进行大量i/o操作的时候,最好还是使用c函数,效率的提升是很可观的~~ 呵呵,有时候觉得c++的路以后可能不会太好走,拼开发效率及跨平台可扩展性它拼不过java,一般的短小应用,写个脚本什么的,perl, php用起来比它方便,而更低层的操作上效率又明显不是c的对手~~,当然,c++的出现对于程序开发这个业界的影响是极其深远而重要的

我的哲学观:
绝大多数情况下,程序员开发和维护代码的时间,要比程序的运行时间宝贵的多

这种程序没必要用c++写

不纠缠该不该用C++的问题,我说的开发维护时间比运行时间宝贵,只是一种态度,记得在Unix Phylosophy中就有前辈提出,当然不是说不用关心效率,而是要摆正各种因素的trade-off. 比如,一个有GUI的程序,采用好的OO结构,无疑效率会慢个几毫秒,但是GUI的显示就需要好几个毫秒,如果程序员说我的代码是很烂很难读,我没用OO思想,但是效率很高,这样的托词是不能接受的. 我想你说的GUI慢的例子往往是这样,有的UI系统上一个进程只能有一个UI线程,或者即使可以有多个UI线程. 程序员没有意识到这一点,把一些耗时操作也放在UI线程上来做了结果按了一个按钮,这个线程在做一个很长时间的操作才回来重新处理下一个Event正确的办法是分出一个worker线程来做这个耗时操作,UI线程继续,这样一般要考虑线程同步搞UI这个东西,迟早要和线程打上交道.开发维护时间与运行时间哪个更宝贵,看怎么说了.
相反我到是认为运行时间可能更重要点,因为运行的次数远比开发次数多,要是每次运行都耗费大量时间还是不可忍受的.最主要还是在这之间找一种可以接受的平衡

测过一些c和c++的算法.
c++的sort比c的qsort快大概20%
空间效率c的一定比c++的高.
c的io 流也比c++的快了不止一点半点
我的经验,优化和debug版本的c++可以相差20倍,计算密集型的。
(优化仅仅指-03之类的编译优化)(debug版本的c++速度和matlab相当。)
手工优化c++代码(关键地方改改),再提高5-10是可能的。
由此可见,简单的说c++的速度,是多么不严谨的事情。(与c的没有比过,不知道)
谈C++和C的效率的差别没有意义,效率的差别主要还是取决于程序员的做法的,
还没有什么应用苛刻到只能用C才能符合效率的要求,而用C++就会导致效率降低到无法接受。
即使对于成本非常敏感的通用手持设备。。。
我最近在做服务端程序的优化,主要考虑的是怎么让一台
服务器支持数千到上万人,
在我面对的问题里,单段代码的效率几乎不在考虑范围之内,
因为很明显,cpu占用率,user time 1%,kernel time 65%,
怎么优化也只是优化这1%,呵呵,没有意义。
对于我所面对的这类特殊的服务器来说,我现在猜测当前的瓶颈点在于不合理的系统
调用,以及不合理的内存换页、L2 cache命中之类的地方,当然以后可能发现新的瓶颈,
而这一类问题常用的解决方法是提高资源访问的局部性,
比如对于一些特殊的资源类型,通过特定的alloctor之类的东西进行分配,
将他们集中在一起,并且考虑使用操作系统的内存管理函数,将他们锁定在物理内存中,
这时候,我以为c++是比c要更容易建立这种清晰的抽象模型,
而同时,我决不可能去考虑java,坦率的说,在操作系统之上编程,就已经很痛苦了,
因为你必须要面对操作系统内部的复杂带来的不确定性,以及你的代码将只能运行在
cpu的用户态的无力感,无法想象在操作系统之上,再加上虚拟机,这个问题就真的无法解决了,想想,你使用的对象,内存是由虚拟机管理的,你怎么来保证内存是分配在一起的,
你怎么在页面中锁定部分内存。更不用说其他的一些细微考虑了。
其实你无法想象现在的cpu究竟有多快,真正的性能瓶颈点往往在体系结构上,
离开了这一点,去过多的考虑局部效率,没有意义。
当然我的经验有限,对于3d、编码解码类的程序,不清楚相应情况,也许很多代码的效率都是需要注意的。
但是估计也是在整体清晰的抽象模型的基础上,找出性能瓶颈点,局部优化的多吧,甚至此时考虑汇编更合适。
当然,如果不了解c++到机器代码的映射实现,不理解c++标准库到纯c代码的映射实现,那么使用c++是更容易犯些错误,或者说不知道在什么时候,该选用什么样的抽象程度和细节控制能力。