Sign in to follow this  

Prefetching in Data Oriented Designs

This topic is 2487 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

I've been reading about Data oriented design, and I see where the benefits lie, but I've got a couple of questions.


1) Articles usually speak of "prefetching" data to avoid memory accesses when the data is actually needed. How would I fetch another cache line in advance?

2) At what point does storing multiple object's data in large linear chunks go too far? If you have multiple models, would you keep their positions, as well as all vertex positions in one large Vector3 array? Do we even use objects and associated operations anymore?
class Model
{
unsigned int position, //index into vector list
indices[1000]; //indices of vertices


};

class VectorList
{
std::vector<Vector3> vectors;

}

Share this post


Link to post
Share on other sites
Hidden
[quote name='godsenddeath' timestamp='1298323057' post='4777216']
1) Articles usually speak of "prefetching" data to avoid memory accesses when the data is actually needed. How would I fetch another cache line in advance?
[/quote]
Often you won't have to do anything special besides structuring your data in a cache-friendly manner. So code like this:

[code]
class GameObject {
Input input;
Physics physics;
Animation animation;
Visuals visual;
doInput () {
process input
}
doPhysics () {
process physics
}
...
}
...
GameObject game_objects[...];
...
for each obj in game_objects {
object.doInput();
object.doPhysics();
object.doAnimate();
object.doRender();
}[/code]

you would do something like this:

[code]
GameObjects {
Input inputs[...];
Physics physics[...];
Animation animations[...];
Visuals visuals[...];
}
doInput (Input& input) {
process input
}
...
GameObjects game_objects;
...
for each input in game_object.inputs {
doInput(input);
}

for each physics in game_object.physics {
doPhysics(physics);
}
...
[/code]

or something similar. By storing all input objects together, all physics objects together and so on, the processor can automatically prefetch the next object before it is needed by the code. The normal OO approaches generally store too many unrelated things together that are used separately, which in turn makes it hard for the processor to prefetch effectively. Alternatively, you can manually prefetch data through SSE, which you can do in C/C++ using compiler intrinsics like [url="http://msdn.microsoft.com/en-us/library/84szxsww(v=vs.80).aspx"]_mm_prefetch[/url]


[quote]
2) At what point does storing multiple object's data in large linear chunks go too far? If you have multiple models, would you keep their positions, as well as all vertex positions in one large Vector3 array? Do we even use objects and associated operations anymore?
class Model
{
unsigned int position, //index into vector list
indices[1000]; //indices of vertices


};

class VectorList
{
std::vector<Vector3> vectors;

}

[/quote]

I use an entity-system approach where each game object/entity is simply a key used to retrieve its components (wehere a component is anything from Position, Velocity etc to Animation and Renderale or even AggresiveAIBehavior. Each of these types of components are then stored in their own arrays/vectors and are processed in sequence allowing the next one to be prefetched while the current one is being processed. It might seem like a bit much, but it makes good use of caching.

Share this post


Link to post
[quote name='godsenddeath' timestamp='1298323057' post='4777216']
1) Articles usually speak of "prefetching" data to avoid memory accesses when the data is actually needed. How would I fetch another cache line in advance?
[/quote]
Often you won't have to do anything special besides structuring your data in a cache-friendly manner. So code like this:

[code]
class GameObject {
Input input;
Physics physics;
Animation animation;
Visuals visual;
doInput () {
process input
}
doPhysics () {
process physics
}
...
}
...
GameObject game_objects[...];
...
for each obj in game_objects {
object.doInput();
object.doPhysics();
object.doAnimate();
object.doRender();
}[/code]

you would do something like this:

[code]
GameObjects {
Input inputs[...];
Physics physics[...];
Animation animations[...];
Visuals visuals[...];
}
doInput (Input& input) {
process input
}
...
GameObjects game_objects;
...
for each input in game_object.inputs {
doInput(input);
}

for each physics in game_object.physics {
doPhysics(physics);
}
...
[/code]

or something similar. By storing all input objects together, all physics objects together and so on, the processor can automatically prefetch the next object before it is needed by the code. The normal OO approaches generally store too many unrelated things together that are used separately, which in turn makes it hard for the processor to prefetch effectively. Alternatively, you can manually prefetch data through SSE, which you can do in C/C++ using compiler intrinsics like [url="http://msdn.microsoft.com/en-us/library/84szxsww(v=vs.80).aspx"]_mm_prefetch[/url]


[quote]
2) At what point does storing multiple object's data in large linear chunks go too far? If you have multiple models, would you keep their positions, as well as all vertex positions in one large Vector3 array? Do we even use objects and associated operations anymore?
class Model
{
unsigned int position, //index into vector list
indices[1000]; //indices of vertices


};

class VectorList
{
std::vector<Vector3> vectors;

}

[/quote]

I use an entity-system approach where each game object/entity is simply a key used to retrieve its components (wehere a component is anything from Position, Velocity etc to Animation and Renderale or even AggresiveAIBehavior. Each of these types of components are then stored in their own arrays/vectors and are processed in sequence allowing the next one to be prefetched while the current one is being processed. It might seem like a bit much, but it makes good use of caching.

Share this post


Link to post
Share on other sites

This topic is 2487 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this