Opened 10 years ago
Last modified 5 years ago
#2322 closed task
Move all AI players to one global — at Version 2
Reported by: | Yves | Owned by: | |
---|---|---|---|
Priority: | Should Have | Milestone: | Alpha 16 |
Component: | UI & Simulation | Keywords: | Spidermonkey |
Cc: | Patch: |
Description (last modified by )
The new SpiderMonkey will not support multiple global objects per compartment anymore. This means that it's no longer possible to share the shared AI state between multiple AI players the same way it's done now.
I tried using wrappers or cloning first, but it looks like this has a significant impact on performance. Another solution is having all AI players in one global object.
Advantages of this approach:
- No overhead for cloning or wrapping
- It should require less memory because scripts are only loaded once per AI player type. If you have 4 Aegis bots, it should only load the folders aegis and common-api-v3 once. the current SVN version loads common-api-v3 5 times (once for the shared part, once per player) and aegis 4 times (once per player).
- The JIT compiler should be able to analyze the code quicker because the scripts are only loaded once and because this version of the loaded scripts gets used more often.
Known disadvantages of this approach:
- It adds another way one AI script/player can affect another one. But even with the current approach we have quite a few ways this can happen. IMO it shouldn't be a big problem.
- It makes the code a little bit more verbose. Each file needs two additional lines in the beginning and at the end and you access objects like "API3.Map" instead of just "Map".
- ... maybe more coming up during testing
What I have at the moment is a WIP patch showing how all aegis bots can share the same global object. I've tested a 2vs2 AI game on Oasis 4 until a bit over 10'000 turns and got the same hash as the unmodified SVN version. I still have to figure out how different bots can share the same global. I also have to test if the theoretical performance advantages can be confirmed and how big the difference is (memory and CPU).
Change History (7)
by , 10 years ago
Attachment: | AI_in_one_global_WIP_v0.1.diff added |
---|
by , 10 years ago
Attachment: | AI_in_one_global_WIP_v0.2.diff added |
---|
This version of the patch now also supports qbot but still not qbot and aegis together
by , 10 years ago
Attachment: | AI_in_one_global_WIP_v0.3.diff added |
---|
This version of the patch moves common-api-v3 to a module using the module export pattern with Augmentation described here: http://www.adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html
comment:1 by , 10 years ago
Before different AI scripts can work together in a game, I need to move aegis, common-api-v2 and qbot to a module as I already did it for common-api-v3.
comment:2 by , 10 years ago
Description: | modified (diff) |
---|
by , 10 years ago
Attachment: | AI_in_one_global_WIP_v0.4.diff added |
---|
This version also moves Aegis to its own module
by , 10 years ago
Attachment: | AI_in_one_global_v1.0.diff added |
---|
first version ready for review. It only moves aegis and common-api-v3 to a module. This means two other AI players like testbot and qbot don't work together in the same game. I think that's acceptable and wraitii wants to remove other AIs anyway.
WIP patch showing how multiple Aegis bots can share one global object