频道栏目
首页 > 程序开发 > 综合编程 > 其他综合 > 正文
linux编程的108种奇淫巧计-7(再答gangban_lau)
2011-01-22 13:25:10           
收藏   我要投稿

再答gangban_lau:http://blog.csdn.net/gangban_lau/archive/2010/11/10/6000977.aspx

      博客确实不是很好的讨论平台。

      对于是否原子性这个问题,我们在水木体系结构版曾讨论过这个话题,参见yifanw的发言,“在所有mordern archiecture上,对齐的machine word读写肯定是atomic的,这点无须质疑”,当然体系架构变化后这个假设变化了,整个都要发生变化,正确性就不被保证了。但是这个体系架构变化的可能性太小了,未来很长一段时间不太可能,即便变了也会考虑兼容性,  __sig_atomic_在linux里定义为一个ordinary int : typedef int __sig_atomic_t;当然如果写__sig_atomic_t会更好,当前没什么价值,但为了将来的移植性好,这是对的,大家都遵守__sig_atomic_t语义,将来肯定是有好处的,这是毫无疑问的。严谨的角度看的确应该如此写。

     你说的“也许有个实现碰巧出现 size_t 需要两次 bus access才能取到完整的值。”,因为都是在栈上定义的,所以肯定都是对齐的,所以真的不会出现碰巧需要两次bus access的可能性,如果这一点我说的不能让你信服,你可以查查资料,这个都是公知的。我这个人也比较较真,但我要看到实践,你说月球上可能碰巧有水,我不能证明月球上无水,因为不可能遍历地球每一片土地,但要说月球有水需要拿出证据才好。因为目前没有一个人能拿出月球上有水的证据,而大部分证据证明月球上无水,所以现在公认月球上无水,应该是合理的。

       对spin lock来说,我是比较经验主义的,相信第一手的实践的东西,但是实践的环境总是有限的,不免陷入局限,以后体系结构变了不兼容现在了这种情况也是有可能的。超高并发,或者多核心的情况慢可能会存在,我想也一定会存在,应该具体问题具体分析,spin lock是有应用场合的,比如一次慢速的磁盘访问还spin lock显然就不合适了。就应该把自己放到阻塞态去。

      

关于你说的题外话,http://blog.csdn.net/pennyliang/archive/2010/10/28/5971059.aspx上提到了-O3的优化编译,还贴了代码,来证明需要手工优化,因为加了-OX的优化后,汇编代码就很难看懂了,这是我不用-O的原因,如果需要,以后我都加上。

       再比如,结构体建议是2的幂(第二篇),以及false shareing问题都是经典的优化问题,这个应该不存在什么疑问吧,即便在-O3,-O2也是避免不了的,不信的话可以实验看看,呵呵。

       很多时候,我们做的东西在一个平台上好用了,移植到另一个平台可能就出问题了,优化在一个平台上有效,换了另一个平台可能出问题,甚至会有机器性能提升了,反而程序性能下降了,但遗憾的是,真的没有办法去照顾到所有可能的平台,一些general的东西应该写入教材,而不是写在博客中,博客中是难免局限的。好在我的博客中有申明:“不代表学术立场,只是非正式交流”呵呵。

       到目前为止机器的很多问题,我还没有能力完全解释,相信有这个能力完全解释的人且愿意分享的人也会很多,因为操作系统太复杂,涉及的问题太多,我们的研究只能固定住其他的点,只对一个点进行研究讨论,但实践环节中,比如搜索引擎,影响性能的原因太多了,要找到全部的原因,进行深入的定量的分析和解释,需要对操作系统,指令集等等一系列深入理解,我有一个心愿,在有限的将来可以写一本《计算原理》这本书,能够把问题讲明白,遗憾的是我现在还在努力学习中,不断探索,只是我有时候停止脚步,趴下来,把肩膀露出来,垫更多的人从我的肩膀上去,去看到曾让我着迷的东西,和我一起去探索背后的原理。

      最后,欢迎大家都来进行实验和质疑,实践和质疑才是进步的前提,感谢gangban_lau提出的质疑。

点击复制链接 与好友分享!回本站首页
相关TAG标签 巧计
上一篇:在内核驱动中检测隐藏进程
下一篇:linux编程的108种奇淫巧计-9(Lock-free之二)
相关文章
图文推荐
点击排行

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站