Pitfall of OO Programming

http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

 

个人比较喜欢这篇文章的思考方向和一些想法。

 

首先作者给出了一些历史回顾，c++是如何发展的，硬件是如何发展的。

c++在发展和繁荣的阶段，刚好是硬件和应用程序非常适合c++的阶段，类似生产力和生产关系的适应，所以大家happy。

甚至衍生到OO programming，也是如此。

 

然后硬件的发展方向开始改变，processor的频率和多核的进展让处理能力大幅度增加，但是相应的memory这边的速度远远跟不上。

 

所以现在游戏开发中更多的时候bound在数据上，而不是计算上。cpu端和gpu端都有类似的趋势。

 

因此，对于速度的追求要求我们去优化内存的使用和访问，进而做DataOrientedDesign。

 

我觉得DataOrientedDesign和ObjectOrientedDesign没有太大冲突，一个从逻辑组织的角度出发，一个从hardware运行方式出发，在其中找到一个平衡点是我们需要做的事情。

这样可以在逻辑层面上仍然具有通过object oriented design来大幅度降低逻辑复杂度的优势，而且从hardware运行层面，还可以获得很好的数据访问能力。

而且现在很多引擎就是在走这个方向。

 

具体到细节上，文中讲的东西可以从阅读汇编代码和查看profiler工具来获得，因为不同的硬件情况的不同，需要具体情况具体分析了。

 

比如其中有说到branch的例子，做一个branch带来的分支预测和并行性的损失大于伪branch两边都算来的大，所以我们不能那么想当然的以为branch可以再任何情况下都会得到性能提升的。

 

还有就是用pool来集中数据，比如所有node的bounding box就可以放到pool里，然后pass这个pool就可以了，这块内存是连续的，所以cache性能可以达到最好。

 

还有prefetch等一些做法，教科书里面已经有了，就跳过吧。

 

总之，oo programming对于降低复杂度还是相当不错的。

但是也容易让人（因为犯懒）而忘记内部和底层的细节，导致性能上的降低。

合理做法是，写和维护的时候仍旧保持对内部细节和底层的良好理解和相应的算法，使用object的时候可以享受复杂度降低带来的好处。

 

最后一个有意思的是说，游戏开发么，最快的是design for specific而不是design for general。

这个赞同一半，两个都有好处，就是一个平衡吧。

 

 

 

 

原文链接： http://blog.csdn.net/ccanan/article/details/5209103