# For each object or for each component?

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

## Recommended Posts

I'm architecturing a 3D game engine with a couple of components (Graphics, physics, sound etc) where each of those wants to iterate the objects in the world. Currently each component will iterate the list of objects them self. Would I benefit from doing like this: Pseudocode:
For each object
doPhysics(ptr)
doRender(ptr)
doSound(ptr)
loop

Will the overhead from calling those functions be larger than the overhead with the multiple iterations (one for each component)? I don't have to worry about that the rendering and physics wanting different objects, I have a clever scene manager that fixes that =)

##### Share on other sites
Typically you can't render until you know the position which means all physics updates are done. i.e. just because you update the physics on one object doesn't mean the position is final. another object may come along and collide, and cause both to move later. in which case your rendering of object1 is now invalid.

Generally:

1) update all logic
2) render

Otherwise for logic components it's really about what makes more sense to you (unless you're on a platform like the 360 which hates fetching from memory, in which case you want to iterate the objects as few times as possible).

-me

##### Share on other sites
Ok, assuming we have some components that can run parallel, like sound and physics, which approach would have the lowest overhead?

EDIT: Also assuming collision sound may be played one frame late.

##### Share on other sites
I constructed a simple benchmark to measure the overhead on IA32, (ran on Athlon XP). I thought I would present the results. It's by far much more overhead when calling functions with each object like that compared to letting all the components iterate them self. The only way I was able to beat it was was to inline the functions but I only gained 0.9% performance. When I didn't inline I lost 17%.

My three components did construct strings (with slow sprintf's), did calculations (with lots of data dependency and branch misspredictions), and just waste resources.

Conclusion: At least on IA32, let each component iterate the objects themself. Too much overhead when calling functions that many times. But I also guess this is rather dependent on the cost of fetching from memory so there might be some platforms that gains from it.

##### Share on other sites
Quote:
 Original post by eXt_Ok, assuming we have some components that can run parallel, like sound and physics, which approach would have the lowest overhead?

Depends on... well, just about everything - from hardware to the complexity of the operations and the number and size of objects. If you can do either easily (you should be able to), try both methods and profile.

But I'd go with the "for each component" approach by default, since highly orthogonal operations like that, suprisingly enough, are well suited to running on different threads (to take advantage of multiple cores/processors). Or so I've heard.

##### Share on other sites
I guess loop unrolling matters a lot too but the problem is the unknown numbers of objects, what objects and the size of them.

I didn't try those methods in my engine which is mostly in the architectural stage right now, but I did create a smaller test scene. You reminded me of threading and that will be easier with running the components like that.

However, don't use a thread for each component like that, it ruins the scheduling. Imagine when 3 components takes 10ms each to calculate and one that takes 50ms, it would still take 50ms to run all components. Divide it into small parts (maybe dependent on other parts) and send it to a job scheduler that shares the work equally on the threads, processes, cores whatever. Using the earlier example the total time might become 30ms instead. The job scheduler is a bit complex thought but definitely worth the job. One day I will write an article about this topic.

I guess I stick with the "for each component" approach.

1. 1
2. 2
frob
15
3. 3
4. 4
5. 5
Rutin
12

• 12
• 12
• 58
• 14
• 15
• ### Forum Statistics

• Total Topics
632115
• Total Posts
3004198

×