Multithreading

[greenman]

I think some of the future bottlenecks will be:

- AI
- Tick (there is a lot potential parallelising this, every tick of every object should be able to work parallel with the other ticks)
- data fetching and processing in network part
- ogre rendering (dont know how feasible this is)

But even if we cannot do multithreaded rendering we should be able to include it later on (in the future ogre might be suddenly mt )

Btw: does anyone know how much overhead mutexes (one, few, a lot) produce?

I think locking whole objects would be a cheap and safe way of preventing data corruption, or am i wrong?

[1337]

Hmm, none of the articles I read talked about using a lot of mutexes. But one mentions overhead ("This monitor is implemented with critical sections, mutexes, and semaphores--sounds slow, but it's not bad, especially if you base the design around low-frequency calls") in the second Ogre forum article I posted previously.

I don't exactly agree on the bottlenecks. AI will be one anyway (pathfinding can be very cpu intensive). But our own tick()? No, because currently we're spending (when shooting) already more than 90% on collision detection in our own tick(). I agree that our tick will be a great deal larger in the future, but as Tim Sweeney said, "You definitely don't want to execute your 150,000 lines of object-oriented gameplay logic across multiple threads."

The smallest bottleneck (the smaller, the worse..) just after rendering will most probably be physics. Of that I'm pretty sure.

An article that talks about mutex and semaphore performance:
http://sendreceivereply.wordpress.com/2 ... rformance/

Some notes about multithreading:
http://blog.flameeyes.eu/articles/2008/ ... -threading

[greenman]

I don't know if you're right saying that the tick will not be a bottleneck
For every object that has a position and is not static we have around 20 (or even more; i have no clue, how many basic operations ogre vector operations take) operations every tick, which makes quite a lot of operations for hundreds of objects. Maybe it's not the most computation expensive part, but isn't it always good to enhance as much as possible (in this case make it parallel) ?

Most developers start out to redesign the engines to run on 2 cores. Others at 3.. etc? The basic principle for the design should be that we should be able to run on any number of cores, and be able to achieve almost linear performance boost on the number of cores. So designs like: There is one rendering thread, one game simulation thread and one physics simulation thread?, are out of the question. I don?t think we should even bother with constant multipliers? I better wait for CPU to double or triple in speed!

I totally agree with the writer. We should not focus on having 4 different threads, but we should try to use as many threads as possible. If we don't then we can start all over again in some years when CPU's will maybe have 8+ or 16+ cores. So our aim should be (as mentioned in one of reto's links) to scale up performance linear (or even quadratic if possible ) with number of cores.

"I should point out that even though Ogre is not thread-safe, there is no reason why your application cannot use threads. It just means that you cannot have multiple threads which deal with Ogre. As long as you make sure that only a single thread handles all your Ogre-related tasks, you are free to run your sound engine or AI scripts in other threads."

does that mean, that while ogre is rendering we may not access our WorldEntities (they all use scenenodes) with any other thread ? Or does it mean we may only READ the objects while rendering ?

[1337]

You shouldn't forget that our tick() has nothing to do with the position of an object that is part of the physical world. That's all up to the physics engine. You only apply forces to an object, because otherwise your physics engine may start doing weird things (ODE FAQ).
But enough of that. I will use every means necessary to prevent us splitting the game logic in our tick(), because otherwise we're most probably occupied finding bugs for more than half a year or so (we will be anyway as soon as we pronounce the word multithreading...).

And about Ogre: I think it should be perfectly safe to read the objects. May a buffer will be required, but that's more of a detail to discuss later.


I would like to say something about N threads (like I've already stated in the summary post): If we were to decide to have an arbitrary number of threads, then I'm off. Because it is my very believe that in order to write something like that it would take at least a few programmers that have many years of experience with multithreaded game or simulation programming. And I can't deliver that. No one of us really can (Beni said something that he had quite some experience..)

Just to remind: We're only students and have little experience... So we should not try to do something that even the best in the world can't do right now (UT3 engine only supports dual core properly as far as I know).

[beni]

Interesting, I haven't thought about that the tick stuff which will all be in the physics afterwards. Also reading the SceneNodes while rendering should be possible, only during the update cycle this would be a very bad idea. Question is, if Ogre does this sequential or not.

Also I agree with the constant number of threads. Of course this makes no sense with scalability, but our resources, knowledge and of course our experience is so much limited, that multi threading will bring this project to a fall instead of helping it. My experience is only with some basic concepts of threads. I do not think I could create an N thread application that easily and without bugs.