Instant Action DLL Mod - Unit Control Multi-Threading?

[Natty Bumppo]

I am thinking about creating a new Instant Action DLL modification that will separate action control logic to individual units.  The intent is to make the units somewhat autonomous.  They will make their own decisions about what they do in any given situation.  I also expect to be able to set up a kind of self-organizing "swarm intelligence" to make the units work more cooperatively as a group by taking advantage of their individual decision-making.

To make this idea work well I am hoping to be able to take advantage of multi-threading.  In short a thread would be created for each unit as it is added that would persist until the unit is removed.  In effect, each unit would be "thinking" and responding to events on its own, and would be able to respond to requests and commands from other units.

I've searched the boards here for information related to multi-threaded capabilities in the BZ2 DLLs and not found anything so far to the point.  Can anyone tell me whether there are any impediments to implementing this idea, or if anyone has actually coded something like this for BZ2?

[GSH]

I think the easiest -- and safest -- thing to do would be some sort of cooperative multitasking that you manage. Basically, in C++, you could make all your objects derive from some base class, call it DLLObject. Each object has an 'Execute()' function. When the DLL's Execute() is called, it just calls Execute() on each DLLObject. It does 1/10 of a second of thinking. That's more or less how BZ2 runs.

I don't like threads for the following reasons: (1) Windows doesn't do so hot with 50+ threads running and chewing up cycles. (2) Debugging multithreaded is 10x harder, especially when you go from 1-core machines to 2-4 core machines. (3) Getting true threads to Save() and Load() their state is a lot harder than things that . (4) Running with threads in MP is going to be really hard to synchronize their state -- possibly the same as #3.

-- GSH

[OvermindDL1]

The python scriptor I made did exactly what you want to do, you make lots of little tasklets (like threads, but not OS level, vastly more efficient) where each does a tiny little task.  If you want to try to learn it I can help teach it.

But yes, if you want to stay in C++, do not use real threads.  You might just do what GSH said and just update once per tick...
Generated by OvermindDL1's Signature Auto-Add Script that OvermindDL1 did manually since Greasemonkey does not work in Firefox 3.1 yet...

[Natty Bumppo]

Thanks for the quick responses! 

GSH, I was hoping you would offer some advice in particular.  You pretty much confirmed some of the things I suspected and was considering.  I was concerned that having dozens of threads running might be a performance issue, and didn't relish the idea of having to debug the them, especially since I'll be developing this on multi-core machines.  Ultimately I would like to work this into the MPI DLL and knew state synchronization would be a real bear.  Managed cooperative multitasking per your suggestion seems doable to me, and much more easily portable to MPI.  It's not far off from one of the alternatives I had in mind.  The main thing I'm worried about is trying to do too much during a single Execute.  Do you have any tips on how to avoid that and how to detect when you've gone overboard?

OvermindDL1, I appreciate the offer.  Learning something about how your Python scriptor works might help to solidify what I have in mind, whether I borrow some of your ideas or not.  I'll be happy to take a look at whatever instructive material you have.

[Red Devil]

GotoTaskHasLeader = false might help do the same thing you might be looking to accomplish.  It allows them to follow their own paths instead of waiting for the 'leader of the pack' to break through the crowd, making all packs more responsive, especially Walkers and tracked units.

[OvermindDL1]

I think he is actually wanting to control them in detail by dll, which far bypasses those odf commands, so that would not matter.

My Scriptor just uses a lot of microthreads to control everything, you just new up a new one whenever you want, they can sleep, you can pause, etc... just like lots of threads.  It is on my site if you want to download it and look at the couple of example scripts.  Get me on IM if you want to chat.
Generated by OvermindDL1's Signature Auto-Add Script that OvermindDL1 did manually since Greasemonkey does not work in Firefox 3.1 yet...

[Nielk1]

What GSH I like.
I will look into that.

Oh how nice it will be to get back to code in the style of the Marine Biology Case Study from AP Computer Science.

Fish Class will in this case be the unit super class, the the different kinds of fish the sub controlled types.

I will be sure to use this in a map I am planning that uses a DLL for custom resource management.

[GSH]

The main thing I'm worried about is trying to do too much during a single Execute.  Do you have any tips on how to avoid that and how to detect when you've gone overboard?

Frankly, BZ2 does so much on the CPU already that it'd be hard to see the DLL chewing up that much more CPU time to be noticeable. As to detecting things, I'd say that the easiest way to test it is to have the testers scream when it's slow. You could also grab http://developer.amd.com/cpu/CodeAnalyst/codeanalystwindows/Pages/default.aspx (free, works on non-AMD chips, just requires an email account registered w/ them) and run BZ2 and your DLL during some 'busy' times. If your DLL starts showing up in the top 20-odd functions according to the profiler-- which I think would take some real work-- then it's probably time to investigate optimizing.

Finally, and most accurately, might be to put in a micro-wrapper in your Execute() function that measures how long it's taken, and complain if it's gone too long. Don't use GetTickCount() -- it's not accurate enough. Here's some source code that'll work on any modern CPU. (It probably won't work on 486s, or AMD K5s. BZ2 1.3pb4a requires a CPU w/ SSE, so you're guaranteed that if running on pb4a or newer, this code'll work.)

#include <Windows.h>

double s_Period1000; // convert time diff to ms (1/1000 of a second). Fill in at DLL Init() time, do NOT save/load this!
void InitTimer()
{
  LARGE_INTEGER freq;
  BOOL Ret = QueryPerformanceFrequency(&freq);
  if(!Ret)
{
// CPU is way too ancient. In trouble!
}
else
{
s_Period1000 = 1000.0 / (double) freq.QuadPart;
}
}

Then, rename your original Execute() function to something like RealExecute(), and make this your Execute function:

void Execute(void)
{
  LARGE_INTEGER entryCount, exitCount;
  QueryPerformanceCounter (&entryCount);

  RealExecute(); // do all my work

  QueryPerformanceCounter (&exitCount);
  __int64 Diff;
  Diff = exitCount.QuadPart - entryCount.QuadPart;
  double elapsedMS = Diff * s_Period1000;
  if(elapsedMS > 5.0)
{
AddToMessagesBox("Uhoh.. RealExecute() taking too long\n");
}
}

Basically, I'd be surprised if your code takes 5ms to run. That's a LOT of cycles on modern CPUs. At 30fps, each frame has (on average), 33.3 ms to execute. DLLs are executed (by default) 10x per second, so if it takes 5ms each time, that's 50ms total. Doing the math, that means framerate would drop to approx 28.5fps (i.e. 950ms / 33.3ms).

-- GSH

[Nielk1]

Oh the horror of what I sometimes have execute doing.

[Commando]

I'm glad to see you are still around Natty.  I haven't heard from you since September.  If you need someone to upload your maps to a temporary location, I can.

I hope everything worked out for the best regarding what happened earlier this year.

[TheJamsh]

sounds like a real challenge...