Opened 10 years ago

Closed 6 months ago

Last modified 6 months ago

#2618 closed enhancement (wontfix)

Run AI logic in a separate thread

Reported by: Josef Kufner Owned by:
Priority: Should Have Milestone:
Component: Core engine Keywords:
Cc: Patch:

Description (last modified by phosit)

Funny thing happened. AI tried to build Civic Center on top of little hill, but there is no way uphill. A few workers got stuck under the clif and game dropped to slideshow with 100% CPU usage. Problem is, that stupid behavior like this, can make game completely unplayable. AI planning should be performed in its own thread with no option to destroy responsiveness of user interface. I don't mind if AI is burning one of my CPUs, but I really don't like to watch unresponsive slideshow. AI bugs causing this problems should be fixed, but first, AI invocation should be moved away from rendering and user interface. I see in top, that there are multiple threads and only one of them is working very hard. So in case that AI is already separated from UI, there is probably bug in communication between these two.

Attachments (3)

screenshot1.png (1.4 MB ) - added by Josef Kufner 10 years ago.
screenshot2.png (1.5 MB ) - added by Josef Kufner 10 years ago.
savegame.0adsave (1.3 MB ) - added by Josef Kufner 10 years ago.
Save of game with workers stuck under the clif. Easy to test how AI turns game into slideshow.

Change History (9)

by Josef Kufner, 10 years ago

Attachment: screenshot1.png added

by Josef Kufner, 10 years ago

Attachment: screenshot2.png added

by Josef Kufner, 10 years ago

Attachment: savegame.0adsave added

Save of game with workers stuck under the clif. Easy to test how AI turns game into slideshow.

comment:1 by historic_bruno, 10 years ago

Priority: Must HaveShould Have
Summary: AI bugs destroy UI responsivenessRun AI logic in a separate thread
Type: defectenhancement

Indeed, the AI was partially designed to support threading (e.g. CmpAIManager uses worker objects), but there are a number of issues to solve before that happens. The AI should be more efficient and do less work, before we even consider threading, which is really pushing the problems to the background and creating new ones.

I will rename this ticket and keep it as an enhancement.

comment:2 by Philip Taylor, 10 years ago

I think running AI in a separate thread won't really solve the observed problem. Firstly it was probably the pathfinding that used all the CPU time, not the AI scripts. And secondly, since we're doing deterministic simulation, we can't simply wait an arbitrary time for a background thread to complete - before we start any asynchronous AI/pathfinding/etc requests, we need to decide when we are going to expect the result (typically one or two turns into the future), and if the result isn't ready then we have no option but to pause the simulation.

In theory we could probably allow the UI to remain partly responsive while the simulation is paused (I guess just change NetTurnManager to ask every component whether it's ready to proceed, before advancing to the next turn). But that's still just masking the real problem, which is that pathfinding and AI need to avoid being slow.

comment:3 by mimo, 10 years ago

In fact, the original problem is already fixed in Petra AI which should never try to build in an inaccessible region. Nonetheless, similar slowdown may still happen when trying to gather inaccessible resources (chicken inside building obstruction or bushes inside mine obstruction for example happen relatively often in random maps).

comment:4 by phosit, 16 months ago

Description: modified (diff)

Can this ticket be closed as won't fix? simulation2/components/CCmpAIManager.cpp:

Line 
60 * The original idea was to run CAIWorker in a separate thread to prevent
61 * slow AIs from impacting framerate. However, copying the game-state every turn
62 * proved difficult and rather slow itself (and isn't threadable, obviously).
63 * For these reasons, the design was changed to a single-thread, same-compartment, different-realm design.
64 * The AI can therefore directly use the simulation data via the 'Sim' & 'SimEngine' globals.
65 * As a result, a lof of the code is still designed to be "thread-ready", but this no longer matters.
66 *
67 * TODO: despite the above, it would still be useful to allow the AI to run tasks asynchronously (and off-thread).
68 * This could be implemented by having a separate JS runtime in a different thread,
69 * that runs tasks and returns after a distinct # of simulation turns (to maintain determinism).

comment:5 by phosit, 6 months ago

Resolution: wontfix
Status: newclosed

I treat that as a yes ;)

comment:6 by phosit, 6 months ago

Milestone: Backlog
Note: See TracTickets for help on using tickets.