On 9/8/2016 1:10 AM, Ethan Watson wrote:
On Wednesday, 7 September 2016 at 22:52:04 UTC, Walter Bright wrote:
Is:
if (resource != null)
resource.destroy();
v.s.:
resource.destroy();
so onerous? It's one TST/JNE pair for a value loaded into a register anyway.
This one has performance implications for game developers. The branch predictor
in the CPU used for the Xbox One and the PS4 isn't the greatest. If, for
example, that destructor gets inlined and you're iterating over a range of
resources and the destroy method is virtual, there's a good chance you will
invoke the wrath of the dense branch predictor. You don't want to deal with the
dense branch predictor.
The thing is, the 'destroy()' function is going to swamp any extra clock cycle,
as will a virtual lookup and dereference.
http://www.agner.org/optimize/microarchitecture.pdf section 3.13 has a bit more
info on the branch predictor. Desktop Intel CPUs tend to hide performance
problems like this thanks to their far-higher-quality branch predictors. Both
chips gain benefits from sorting to how you expect the branch predictor to work,
but there's a lot of code in a game codebase that isn't that low level.
There's another way. Just don't worry about it being null, if you're going to
ensure it is initialized regardless. It'll seg fault if it is dereferenced but
not initialized.
