Does anyone know if using multi-threaded character AI boosts performance with DX9?

Do you mean purely the 'Artificial Intelligence' side of things? if so, that doesn't necessarily rely on a presentation layer (e.g. D3D9) and can quite happily run in a multi-progamming environment [smile]

Jack

I looked at implementations like pod-bot, etc. Do you feel that it is better to supply AI through internal application support, or as an external executable connecting like a network client?

Quote: Original post by MooMansun
I looked at implementations like pod-bot, etc. Do you feel that it is better to supply AI through internal application support, or as an external executable connecting like a network client?

It depends on how extensible you want your application to be. If you want people to be able to write additional plugins for AI, taking the network client approach could work a bit better. However, there are major security concerns with it that you will have to spend a lot of time addressing. Also, connecting like a network client will cause there to be a bit more overhead and latency from your app to the actual AI code.

Try heading over to the AI forum and look into what those guys have said in the past...they are the real experts on the subject.

Moved to "Artificial Intelligence".

Quote: Original post by MooMansun
Does anyone know if using multi-threaded character AI boosts performance with DX9?

The three really have nothing to do with each others. AI doesn't use DirectX (Unless MS has sneaked out a DirectAI recently without me noticing [wink]), and multithreading doesn't magically give you a faster CPU to run your code on.

Multithreaded AI code is faster than singlethreaded AI code only if your multithreaded code is more efficient. (Of course, on a dual-CPU system, it will often be faster, since you actually have a second CPU you can start using)

But assuming a single CPU, you have the *exact* same hardware no matter how you write your code. Multithreading is mainly a tool to abstract and decouple different tasks. It makes certain things easier to do, but it doesn't magically overclock your CPU or anything like that. It has the potential to run a lot slower (if the threads block each others too often), or it may run as fast as the singlethreaded code.
The only real reason why it'd be faster is that it makes it a lot easier for the programmer to run multiple tasks in parallel, so you might be able to achieve the same CPU utilization with less work. (Of course, it has the potential for some nasty and time-consuming bugs too, which can really ruin that point if you're not careful)

But multithreading doesn't do anything you couldn't achieve in singlethreaded code as well. It just makes some things a bit easier.

The first thing that is good about multithreading is that the code turns out to be simpler if you're doing things right.

However, when coming to consider multithreading, you should ask yourself the following questions:

1. Is your performance tight? If you try managing 100 agents using a single thread, and you end up having 20-30% of your time spent on time scheduling management, or on doing nothing in between, your performance is not tight, and maybe giving up control and letting your OS take care of things.

2. How much real-time action do you need? If you need to be a control freak over time sharing (for example, when fairness means that you need to allocate exactly 1 time unit to each agent [of 100 agents] over a period of 100 time units) - then you simply cannot allow threading to come into the picture, as you'll lose control over your time sharing algorithms.

3. How many resources will be used in between the different threads? Remember that every resource must be protected. Sometimes you can get out of it by using some algorithm that will make sure no collisions will take place (I'm getting really good in coming up with those lately at work :-)), but when you won't have any choice then you'll have locks - and locks mean immediate performance hit, and often a very serious one. If your agents spend to much time sleeping on locks, you'll get your application to its knees.

Bottom line is, I think that whenever you can get good performance with a single-threaded model and you don't need thousands of lines to manage it - stick to it for as long as you can.

Of course, like was said before me, if you plan on making the agents extensible and thus prone to various user abuses, you might want to "isolate" the agents from your main thread, or at least get a strict time scheduling mechanism working on it.

Very solid answers, thanks guys. When it comes to network code, I seem to spend most of my time dealing with potential buffer overflow errors. I find these can creep in during the parsing stage, although I am getting better at avoiding them.

I suppose the next question would be, which is better waypoints, recognition systems or some other form of navigation?

In theory[\i], it is impossible to have a parallel algorithm with an effiency higher than 1.* Thus, when running on a single-core single CPU, and without taking things like hyperthreading into account, a multi-threaded algo cannot have better performance than a well-implemented singlethread version. There are other reasons to make an algorithm multi-threaded tough (like clarity).

So if you are purely looking for improved performance, the thing you should ask yourself is, will I have multiple cpu core available to me more often than not?

Hopes that helps!

Steadtler

---
*Effiency is equal to acceleration divided by the number of CPU. So if you only have 1 CPU, the acceleration cannot be higher than 1, which means no acceleration :P

Quote: *Effiency is equal to acceleration divided by the number of CPU. So if you only have 1 CPU, the acceleration cannot be higher than 1, which means no acceleration :P

I would be inclined to agree with you, however, a network componant can introduce wait states and these cycles can harvested by the main application to prevent lag, or improve application responsiveness.

If I was to implement the AI within the engine itself, I may be tempted to try it under a single thread. I also feel that the fact that the OS is multi-tasking anyway, could be a missed opportunity.

Is there any detailed breakdown of average CPU usage throughout the D3D pipeline?

This may shed some light on which scenario is appropriate.