3 ms·

I'm not sure I agree with this article. I have been looking at the source code of some open source games and they all make use of a mix of flags and some sort o

by pylua 4y ago

I'm not sure I agree with this article. I have been looking at the source code of some open source games and they all make use of a mix of flags and some sort of polymorphism. At some level, when you get into a low enough level class, there is most certainly a ton of if, else, and flags. Not everything can be normalized elegantly into polymorphism, because there are too many combinations. I wouldn't describe these open source games as having code smell, but rather just being very complex. Using flags seems to be a very effective way of encapsulating the complexity. I have not looked at a popular open source game that has really used the approach described in the article. Does anyone have any references for that?

mostlylurks 4y ago
Games are a bit of an atypical case, since the overhead of runtime polymorphism (allocation, virtual function calls) motivate many to avoid runtime polymorphism due to the importance of performance in games, regardless of if that motivation is justified or not. Thus, polymorphism might still have been the most elegant approach, but its use avoided due to non-stylistic factors.
- pylua 4y ago
  I feel like this is true, but just anecdotally. Is there any good literature on the cost of if/else vs polymorphism? Does branch prediction really work that well in practice vs polymorphism? I figure the approach in the article would potentially have bad cache locality, but I am unsure of how it would perform.
  - tbrownaw 4y ago
    Function pointers / vtables / polymorphism are slow, because they're indirect jumps (harder to predict). Function calls are slow, because there's work to do to save / restore state on the stack. These don't matter much for big heavy functions, but tiny ones can seriously benefit from being inlined. I have heard elsewhere that "game objects are just an index into a bunch of arrays for all the object properties" is fairly common practice, but well I don't write games myself.
  - jlajsdofwwfds 4y ago
    Isn't this essentially comparing switch/jmp table to a vtable? The switch/jmp table can be optimized to be inline, vtable will likely incur a stack frame, plus usually 3 indirections. When you have a closed set of types, then you know all cases for branching, in polymorphism you lose this power -- it's open ended. This is another reason why languages should have exhaustive pattern matching with sum types.

by pylua 4y ago

mostlylurks 4y ago

Games are a bit of an atypical case, since the overhead of runtime polymorphism (allocation, virtual function calls) motivate many to avoid runtime polymorphism due to the importance of performance in games, regardless of if that motivation is justified or not. Thus, polymorphism might still have been the most elegant approach, but its use avoided due to non-stylistic factors.

pylua 4y ago
I feel like this is true, but just anecdotally. Is there any good literature on the cost of if/else vs polymorphism? Does branch prediction really work that well in practice vs polymorphism? I figure the approach in the article would potentially have bad cache locality, but I am unsure of how it would perform.
- tbrownaw 4y ago
  Function pointers / vtables / polymorphism are slow, because they're indirect jumps (harder to predict). Function calls are slow, because there's work to do to save / restore state on the stack. These don't matter much for big heavy functions, but tiny ones can seriously benefit from being inlined. I have heard elsewhere that "game objects are just an index into a bunch of arrays for all the object properties" is fairly common practice, but well I don't write games myself.
- jlajsdofwwfds 4y ago
  Isn't this essentially comparing switch/jmp table to a vtable? The switch/jmp table can be optimized to be inline, vtable will likely incur a stack frame, plus usually 3 indirections. When you have a closed set of types, then you know all cases for branching, in polymorphism you lose this power -- it's open ended. This is another reason why languages should have exhaustive pattern matching with sum types.