For each object or for each component?

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

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.

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.

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.

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.