JosEPh_II
TBS WarLord
And I've got an AI next door with 112 units in his border city. Just waiting for the right opportunity to attack me. 
JosEPh
C2C SVN Changelog
- Thread starter Dancing Hoskuld
- Start date
And I've got an AI next door with 112 units in his border city. Just waiting for the right opportunity to attack me. JosEPh
Updates:
-Added the Criminal unit mechanics I proposed in the Promotions thread
-Small unit tweaks.
@AIAndy:
IIRC you added the multi-threaded spawn option a year ago, but it was never turned on. That said, if it was done in the same way as the property solver threading was, then it would probably be a good idea to change it's memory allocation as well, as I suspect it would give the same crashes.
-Added the Criminal unit mechanics I proposed in the Promotions thread
-Small unit tweaks.
@AIAndy:
IIRC you added the multi-threaded spawn option a year ago, but it was never turned on. That said, if it was done in the same way as the property solver threading was, then it would probably be a good idea to change it's memory allocation as well, as I suspect it would give the same crashes.
It was similar but far less refined. So I'd want to rewrite that part anyway.
Currently I consider using a thread cached memory pool that only allocates via a lock if it runs out of appropriate memory in its thread pool.
Hard to do in much of the code due to widespread use of STL objects, and the fact that many of those STL objects flow across the API to the EXE with the potential for allocation and deallocation to occur on different sides of the boundary. Would work fine for highly self-contained code (where the STL objects never leave some fairly tight scope), but not going to be a general solution that would allow us to start multi-threading a wider variety of the codebase.
Just pushed to SVN (3772):
These two tweaks are in response to where I see the AI failing in my current game, based on analysis of the BBAI logs/stats.
The first one turns out to be a bug (essentially), in that when the tags prereqOrBuildingClasses was added to buildings (AND/ROM??), whoever did it never wrote any AI code to evaluate it. As a result the AI was totally blind to building requirements expressed with this tag - this has recently become MUCH more important with all the V26 dependencies on 'storage pit' OR 'barter post' OT 'trading post', and the result was that the AI was not building these buildings anywhere near early enough (and so missing out on the large number of nice cheap buildings they enable)
The second one was because the AI capped the amount of weight given in tech evaluation to civic enablement at too low a ceiling value, with the result that things like monarchy were not being researched with as much priority as they should have been.
- Fixed AI blind spot with pre req OR building requirements
- Increased the maximum weight given to civic enabling in AI tech evaluation
These two tweaks are in response to where I see the AI failing in my current game, based on analysis of the BBAI logs/stats.
The first one turns out to be a bug (essentially), in that when the tags prereqOrBuildingClasses was added to buildings (AND/ROM??), whoever did it never wrote any AI code to evaluate it. As a result the AI was totally blind to building requirements expressed with this tag - this has recently become MUCH more important with all the V26 dependencies on 'storage pit' OR 'barter post' OT 'trading post', and the result was that the AI was not building these buildings anywhere near early enough (and so missing out on the large number of nice cheap buildings they enable)
The second one was because the AI capped the amount of weight given in tech evaluation to civic enablement at too low a ceiling value, with the result that things like monarchy were not being researched with as much priority as they should have been.
You can give STL objects an allocator (although having an allocator with a state is not covered by the standard iirc).
If we move onwards to a lot of multi-threading then a mutex for allocation/deallocation is good and you would still be able to use the thread cached memory for when only one thread would use a certain object.
At work i have to use the Intel Threading Building Blocks for a Project. The Library contains a tbbmalloc_proxy that replaces all MSVC memory management in an Application with Intels threading optimized memory-allocator.
From the Documentation
The Library is Open Source with a GPL v2 Licence maybe you can use it. see at http://threadingbuildingblocks.org/
Yeh, I realize that. That works for o jects whose lifetime and scope is controlled and you can be certain is only being manipulated by your code (which is obviously true of the property system), I just meant that when we come to multithread wider partsof the code, which tends to have a rather sprawling call tree, it will be harder to be sure we only deal with obects that meet that criteria.
Yes, but I don't think there is any way around those considerations anyway (as you need to be sure that they are not written while you read and similar stuff).
Hydromancerx
C2C Modder
Updates
- Tweaked Housing (Homeless), Lean-Tos, Bone Huts and Treehouses.
- Tweaked Flour and Grain resources.
- Added Wheat Gatherer, Barley Gatherer, Rice Gatherer and Corn Gatherer.
- Tweaked Quern.
- Tweaked Housing (Homeless), Lean-Tos, Bone Huts and Treehouses.
- Tweaked Flour and Grain resources.
- Added Wheat Gatherer, Barley Gatherer, Rice Gatherer and Corn Gatherer.
- Tweaked Quern.
I was planning on rendezvousing any AI threads such that they are only doing work while the game main thread is held inside CvGame::update(), so you know that the only concurrency is between our own threads at that point. Every now and again they all rendezvous and pause and we give the main thread a timeslice to exit from CvGame::update(). Other threads never call into the DLL anyway.
I have looked into the memory code a bit and it seems like only the debug version uses the memory manager in the exe, the final release version uses the normal new which should be resolved by the linker to calls into the C Runtime msvcr71.dll, which is the multi threaded version including a thread safe memory allocation.
So I am not sure why we get problems.
That sounds wrong. We are always allocating things like CvStrings and giving them to the EXE, which uses and then deletes them. If we are using a different memory manager than the EXE is, that normal behaviour (irrespective of threading) should be crashing us. Are you sure we aren't trapping 'new' back to the core allocator (in non-debug builds)?
We are using the same memory allocator, just not like in the debug build with calls to the interface of the EXE, but instead using calls to the runtime DLL directly.
Exactly - so if the EXE is using the single-theaded runtime, and we are using the multi-threaded one, that's different allocators (they **MAY** use the same heap structures and hence we get away with it if they are not used concurrently, but I'd not want to stake my life on that)
Unlikely, why would they have placed the DLL with the multi-threaded runtime in the Civ directories and then link against a static one.
Hydromancerx
C2C Modder
Updates
- Tweaked Cement Mill, Chemical Plant, Filling Factory, Ironworks, Rubber Plant, Rubber Factory, Fertilizer Plant, Department of Water, Bureau of Farm Management and Department of Energy.
- Added Healing Clay, Mud Bath, Sweat Lodge, Soap Maker and Soap Factory.
- Tweaked Cement Mill, Chemical Plant, Filling Factory, Ironworks, Rubber Plant, Rubber Factory, Fertilizer Plant, Department of Water, Bureau of Farm Management and Department of Energy.
- Added Healing Clay, Mud Bath, Sweat Lodge, Soap Maker and Soap Factory.
Ah, I'd missed this. Are you saying the DLL has always built with the multi threaded runtime? (as provided by Firaxis). In that case then totally agree with you (and it's obviously good news).
