Comments on: Changing C++ for DOD If that happens, you've chosen the wrong dividing line between what should be OOP and what should be DOD! IMHO, the choice should not be based on what system you're in, but how many of those operations will be done per frame. If it's 100, then you should probably use DOD. In-between those it depends on the particular case. Sometimes an operation that you think is infrequent can become frequent due to a difference between your hypothetical design and real world use cases, or the engine is used for a sequel that places different requirements on it. Then you can absolutely be burnt by going strong OOP. In fuzzy cases like that a blended mode could have merit. If that happens, you’ve chosen the wrong dividing line between what should be OOP and what should be DOD!

IMHO, the choice should not be based on what system you’re in, but how many of those operations will be done per frame. If it’s 100, then you should probably use DOD. In-between those it depends on the particular case.

Sometimes an operation that you think is infrequent can become frequent due to a difference between your hypothetical design and real world use cases, or the engine is used for a sequel that places different requirements on it. Then you can absolutely be burnt by going strong OOP. In fuzzy cases like that a blended mode could have merit.

]]>
By: Neil Purvey/2011/02/18/changing-cpp-for-dod/#comment-972 Neil Purvey Thu, 24 Feb 2011 11:00:28 +0000 The problem with that though is there will come a point in development where you realise that actually it's the game logic/AI/whatever holding something up - due to a couple thousand empty and redundant virtual function calls per frame(etc), or some traversal which is thrashing the caches. As you say though, the pure DOD way will win out easily in a performance standpoint. It's all about a realistic middle ground. The problem with that though is there will come a point in development where you realise that actually it’s the game logic/AI/whatever holding something up – due to a couple thousand empty and redundant virtual function calls per frame(etc), or some traversal which is thrashing the caches. As you say though, the pure DOD way will win out easily in a performance standpoint. It’s all about a realistic middle ground.

]]>
By: Marshall Robin/2011/02/18/changing-cpp-for-dod/#comment-952 Marshall Robin Wed, 23 Feb 2011 23:40:23 +0000 I'm not sure why you'd want to use a blend of DOD and OOP... it seems that a DOD approach is better for tasks that require high performance where you don't mind sacrificing some flexibility and iteration time (i.e. rendering) and an OOP approach is good for tasks that require quick iteration and don't affect performance that much (i.e high-level game logic). Why not use the appropriate tool for the job, rather than trying to find a single tool that can do all jobs? I’m not sure why you’d want to use a blend of DOD and OOP… it seems that a DOD approach is better for tasks that require high performance where you don’t mind sacrificing some flexibility and iteration time (i.e. rendering) and an OOP approach is good for tasks that require quick iteration and don’t affect performance that much (i.e high-level game logic). Why not use the appropriate tool for the job, rather than trying to find a single tool that can do all jobs?

]]>
By: TomF/2011/02/18/changing-cpp-for-dod/#comment-921 TomF Tue, 22 Feb 2011 05:50:39 +0000 Hmm... this is a very interesting idea. I don't think you would really need to change the language at all to do at least some of this - just add a layer on top... for example, for several games I've worked on we've used a custom preprocessor to autogenerate code for game objects (glue code for scripting, serialisation, etc), and this extends to generating the header files for the classes and appropriate access methods for each member. Hence it would be <i>really</i> trivial to reorder the members, and only slightly more work to completely restructure them (into SoA form, for example). The most tricky bit is figuring out metrics you can use to derive the ideal layout, I suspect. Of course, that's not really DoD as such but just data optimisation within an OOP framework... but it seems like a step towards the middle ground you mentioned. Hmm… this is a very interesting idea.

I don’t think you would really need to change the language at all to do at least some of this – just add a layer on top… for example, for several games I’ve worked on we’ve used a custom preprocessor to autogenerate code for game objects (glue code for scripting, serialisation, etc), and this extends to generating the header files for the classes and appropriate access methods for each member. Hence it would be really trivial to reorder the members, and only slightly more work to completely restructure them (into SoA form, for example). The most tricky bit is figuring out metrics you can use to derive the ideal layout, I suspect.

Of course, that’s not really DoD as such but just data optimisation within an OOP framework… but it seems like a step towards the middle ground you mentioned.

]]>
By: Mark Lee/2011/02/18/changing-cpp-for-dod/#comment-881 Mark Lee Sat, 19 Feb 2011 18:21:46 +0000 Yes, ple-a-a-a-ase :) I've heard soooo much about DOD benefits but have never seen any really useful code using it(except some very primitive examples) Yes, ple-a-a-a-ase :) I’ve heard soooo much about DOD benefits but have never seen any really useful code using it(except some very primitive examples)

]]>
By: Tony Albrecht/2011/02/18/changing-cpp-for-dod/#comment-870 Tony Albrecht Sat, 19 Feb 2011 04:00:40 +0000 I think ABI issues are very interesting. Compilers are almost completely incapable of changing data layout, and changing layout of a struct is difficult if used outside of a module/library, but solving these issues could be extremely useful. I think one of the best results from your research could be to find a set of useful refactorings for DOD to be applied by tools like Visual Studio. I also wonder if we could (automatically?) tag methods with estimated or maximum allowed costs, then the compiler could disallow calling expensive code in a method if it increases the cost too far. If we can adjust costs based on data layout, memory access efficiency and branch mispredicts then we'd know how expensive a small change like adding a new field to a struct would be. I think ABI issues are very interesting. Compilers are almost completely incapable of changing data layout, and changing layout of a struct is difficult if used outside of a module/library, but solving these issues could be extremely useful. I think one of the best results from your research could be to find a set of useful refactorings for DOD to be applied by tools like Visual Studio.

I also wonder if we could (automatically?) tag methods with estimated or maximum allowed costs, then the compiler could disallow calling expensive code in a method if it increases the cost too far. If we can adjust costs based on data layout, memory access efficiency and branch mispredicts then we’d know how expensive a small change like adding a new field to a struct would be.

]]>
By: David Thall/2011/02/18/changing-cpp-for-dod/#comment-861 David Thall Fri, 18 Feb 2011 19:10:45 +0000 I (also) had some similar thoughts a few years ago: http://www.palgorithm.co.uk/2009/01/c0x-just-about-everywhere/ I expect the C++ standardisation committee will never approve anything that involves breaking significant amounts of existing code. But don't let that be a reason to put you off! Another related idea was to resyntax C++ so it's easy to parse: http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html I really like this idea. The pain of parsing C++ does limit the amount and quality of tools available, so fixing this should improve things even before you consider semantic changes. Cheers, Sam I (also) had some similar thoughts a few years ago:

I really like this idea. The pain of parsing C++ does limit the amount and quality of tools available, so fixing this should improve things even before you consider semantic changes.

Cheers,
Sam

]]>
By: vince/2011/02/18/changing-cpp-for-dod/#comment-858 vince Fri, 18 Feb 2011 14:00:32 +0000

]]>
By: Ashkan/2011/02/18/changing-cpp-for-dod/#comment-857 Ashkan Fri, 18 Feb 2011 13:27:47 +0000 Its and interesting and ambitious idea - much the way people are looking at what other languages can better describe parallel programming, I've not seen anyone look at what other languages can best abstact memory performance issues. If STL like container classes were built into a language, and the concept that the layout of members of a class can be configured, they might be key elements to making something that still is neatly encapsulated like C++ but allows some flexibility with cache performance. Sounds like a PHD thesis if anyone is looking for a subject :) Also, I think component systems by themselves take large steps towards addressing both DOD issues and distributed programming issues while remaining OOP in concept - since they break entities into smaller blocks of memory that can be parallelised and processed in a more SIMD style manner. Its and interesting and ambitious idea – much the way people are looking at what other languages can better describe parallel programming, I’ve not seen anyone look at what other languages can best abstact memory performance issues.

If STL like container classes were built into a language, and the concept that the layout of members of a class can be configured, they might be key elements to making something that still is neatly encapsulated like C++ but allows some flexibility with cache performance.

Sounds like a PHD thesis if anyone is looking for a subject :)

Also, I think component systems by themselves take large steps towards addressing both DOD issues and distributed programming issues while remaining OOP in concept – since they break entities into smaller blocks of memory that can be parallelised and processed in a more SIMD style manner.

]]>
By: codemonkey_uk/2011/02/18/changing-cpp-for-dod/#comment-854 codemonkey_uk Fri, 18 Feb 2011 12:52:33 +0000 [...] This post was mentioned on Twitter by Julien Hamaide, Fabio, Bjoern Knafla, Steve Streeting, y2youhei and others. y2youhei said: RT @mike_acton: Changing C++ for DOD
That idea looks interesting. For many years there have been people who are insisting on perfect OOP in C++ and it seems obvious that this sometimes just doesn't work when it comes to game code. It's hard to convince them, they need some scientific proof. Common sense is unfortunately not working. :D And since I don't care what others say, I've been using a mixed approach for some time now. In spite of what others say, it works great for me. Anyway, good luck with the experiments! That idea looks interesting. For many years there have been people who are insisting on perfect OOP in C++ and it seems obvious that this sometimes just doesn’t work when it comes to game code. It’s hard to convince them, they need some scientific proof. Common sense is unfortunately not working. :D
And since I don’t care what others say, I’ve been using a mixed approach for some time now. In spite of what others say, it works great for me.
Anyway, good luck with the experiments!

]]>