Unreal GC 是准确式的吗，它的GC是怎么实现的？
Unreal GC 是准确式的吗，它的GC是怎么实现的？ 1/2.是精确式的，标记删除的流程。性能好，是因为游戏引擎这个场景非常单一，并且它是侵入式的，整个引擎的各个系统都有很多优化和考虑在里面（比如streaming和粒子）。再比如它会分簇，会在gc的时候多线程标记，可以把单次标记清扫钳制在0.002ms。
最重要的是游戏有帧概念，内存的实际回收也可以通过依赖关系分散在各个帧中。
当然我答的这些很有限，南京周润发，大钊，风恋残雪的博客都讲了很多，配合source去看就能留意到各种细节，这些细节堆积是好性能的根源。
3.我觉得吧，游戏引擎这种大工程就别提什么C++er的任性看法了。不过当然，ue4这种做法也比较非主流..
我自认不是什么C++高手，但是引擎项目是分很多层的，工程项目里C++也就是工具之一(当然对游戏引擎内核来说，这是最核心的工具)，后面还有脚本层什么的，展开来讲基本可以说上三天三夜了。
实事求是的说，gameplay没有GC，单纯靠RAII是很难写的。一个游戏引擎，要做到好用，除了GC以外还需要提供更多更多的特性，仅靠C++那点设施，是远远不够的。
在GamePlay的世界里，GC和脚本都是基础设施罢了，要实现自己天马行空的想象，又要考虑内存回收，没有人愿意这么做的。
事实证明，ue4现在做的还不够，搞了个蓝图阉割了文本化的脚本，导致写gameplay体验极差。这也是很多人觉得突兀的根源，不是因为C++中出现GC突兀，是因为没有脚本才突兀... 是准确式的，目前来看各个被广大开发者中知晓的商业或开源引擎中，除了某同为U字辈的以外都已经在用精确GC了。精确GC的绝对耗时不一定会有多么大的优势，但是可以极大的减少Hiccup，避免瞬间顿卡，而游戏中许多时候并不是CPU Bound，可能是GPU Bound甚至IO Bound，情况更为综合，因此精确式GC的优势就表现出来了，比如当CPU等GPU的时候，有没有GC实际对于帧数没有直接影响。
至于独到之处，大概是通过手动标记而不是靠Build Tool自动标记能够让不需要GC的指针对象不会平白增加性能消耗和造成内存管理Bug？虽然各种UPROPERTY和GENERATE_BODY这种宏看起来丑的一比，还会导致IDE甩脸子，但是从工程角度来说很难找到更佳的方案，这一点实属无奈。通过手动标记的方法也保证了一些性能敏感而变动不大的部分可以以原生C++的运行效率完成，比如渲染层等，这也是综合性能上没有因为GC带来太大问题的原因之一。
“C++ er 大多反对使用GC”这句话的歧义必须指出，首先，什么是C++er，其次，什么是大多，然后，什么是GC？
关于C++er，就我所知，贵乎哪怕是一个完全不相关的语言用户从事完全不相关的行业也可能跳出来指点江山，甚至有语不惊人死不休的“游戏开发最大的性能热点也就是个GC Pause”和“Shader不就是个菲涅尔吗”这种话出现（当然究竟是谁说的这里留个面子就不艾特了），所以这个C++er究竟是不是做游戏开发的？如果是究竟是对引擎底层有一定研究还是仅仅局限于只会用？究竟其岗位是客户端程序还是服务端程序亦或是渲染程序？经过这么层层剥离，可能发现，真正剩下的能够一起讨论这个问题的，没几个C++er了，无非是因为这门语言覆盖的行业太多，而偏偏许多人喜欢对自己并不了解的领域指点江山，导致了这种误会出现。
“大多”也是一个不好判断的点，因为身边许多资深的前辈们可能很少在社交网络发声，而发声的更多是我这种没什么工程经验的新人，虽然没有经验但是本人自以为还是心有B数的，毕竟真正明白工程中有没有这样需求的可能还是这些不发声的真正的大多数，而只要是脱产的理论怎么说都可以有道理。
GC的定义也很有意思，Garbage Collector，这个词是否可以理解成只要是自动回收不需要的对象的都属于GC呢？那RAII也是自动回收内存垃圾，是否也属于GC？这就是个很玄学的问题了。同样叫GC，80年代在C语言上跑的保守GC的算法和现在常用的精确GC的算法几乎没有任何关系，除了作用类似和都叫GC以外没有什么相似点。所以没有必要一棍子打死或者纠结于什么技术，只要能解决工程中出现的问题，而且带来的成本比问题本身要小，那就是好东西。 第三个先问是不是
页:
[1]