Jump to content
  • Advertisement
Sign in to follow this  
Vanderry

Data oriented design

This topic is 1363 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey you cool code crunchers!

 

I'm trying to wrap my head around data oriented design. There are many good explanations and examples out there, but I would love to verify that my understanding is correct before making changes to my old code.

 

So far I have been trying to keep my data simple by avoiding inheritance and using only pods, std::vectors and nested structs. As a very simplified example:

 

struct State
{
  struct Unit
  {
    I32 maxHealth;
    I32 health;
    Float rotationAngle;
    Vector3 position;
  };
 
  struct Player
  {
    std::vector<Unit> units;
  };
 
  std::vector<Player> players;
};

 

My first intuition would be to redefine the data like this:

 

struct State
{
  struct Unit
  {
    I32 maxHealth;
    I32 health;
    I32 positionVector3Index;
    Float rotationAngle;
  };
 
  struct Player
  {
    std::vector<I32> unitIndices;
  };
 
  std::vector<Player> players;
  IndexedVector<Unit> units;
  IndexedVector<Vector3> vector3s;
};

 

IndexedVector is just an std::vector that secures element indices by flagging vacant slots (unless there's a sequence at the end, at which point deallocation occurs). I'm sure there exists a refined variation somewhere.

 

Does this look right, or should I separate even pods of different types but equal memory sizes, such as 32 bit integers and floats? It seems to me like when an index would occupy the same or more memory than the referenced data type, separation wouldn't be a good idea. Thank you very much for any tips!

 

Ps. I managed to close my browser while writing this, so the post had to be restored from memory. Sorry if I lost some point along the way.

 

- David

Share this post


Link to post
Share on other sites
Advertisement

You have the idea down, yes. Though you should try not to worry so much about how to separate your data before you try things out. It will be more important to have your code stay simple, readable, and easy to modify in the future.

 

Once you start coming into performance problems in practice you can apply a Data Oriented way of thinking to try to find and fix the problem. This will give you valuable experience you can draw on the next time you write code, helping you to plan ahead more appropriately. But for now since you may not have that experience it can possibly be a big waste of time to try and "guess" exactly how to organize your data.

Share this post


Link to post
Share on other sites

Hello Randy! I simplified one behemoth of a structure for the purpose of this post. In reality it is part of a quite elaborate (and mostly finished) project that I got some critique for when I passed a code sample to a potential employer. I suppose it might be a good start to unite objects contained in vectors and apply the changes step by step, not necessarily going "all the way".

Share this post


Link to post
Share on other sites

Hodgman is right. In order to give more specific advice the details of the problem need to be known. If how the data is going to be used is known, then it can be more clear how to perform data transformations.

 

You can start by asking "when does this data need to be accessed", "what transformations do I need to perform on this data", "what kind of output do these transformations create". Then you can start to really reason about what pieces of data should be packed together, or processed separately.

 

In general you just want the code to loop over arrays. The loops would ideally have no branching and not create too much register pressure. On top of this, you want to use (ideally) 100% of every single cache line brought in from memory.

Edited by Randy Gaul

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!