[RESOLVED] Parallel condition evaluation

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Message
Author
User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [PATCH] Parallel condition evaluation

#91 Post by Geoff the Medio »

cami wrote:Updated the patch. Runs stable on my machine.
Still gives me compile errors, at the same place as before:

Code: Select all

c:\freeorion_vs2010_sdk\freeorion\universe\RunQueue.tcc(35): error C2780: 'const _Ty &std::min(const _Ty &,const _Ty &,_Pr)' : expects 3 arguments - 2 provided
          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2113) : see declaration of 'std::min'
          c:\freeorion_vs2010_sdk\freeorion\universe\RunQueue.tcc(19) : while compiling class template member function 'void ThreadQueue<WorkItem>::operator ()(void)'
          with
          [
              WorkItem=`anonymous-namespace'::StoreTargetsAndCausesOfEffectsGroupsWorkItem
          ]
          C:\FreeOrion_VS2010_SDK\Boost\include\boost_1_51\boost/smart_ptr/detail/shared_count.hpp(95) : see reference to function template instantiation 'void boost::checked_delete<Y>(T *)' being compiled
          with
          [
              Y=ThreadQueue<`anonymous-namespace'::StoreTargetsAndCausesOfEffectsGroupsWorkItem>,
              T=ThreadQueue<`anonymous-namespace'::StoreTargetsAndCausesOfEffectsGroupsWorkItem>
          ]
          C:\FreeOrion_VS2010_SDK\Boost\include\boost_1_51\boost/smart_ptr/shared_ptr.hpp(184) : see reference to function template instantiation 'boost::detail::shared_count::shared_count<Y>(Y *)' being compiled
          with
          [
              Y=ThreadQueue<`anonymous-namespace'::StoreTargetsAndCausesOfEffectsGroupsWorkItem>
          ]
          c:\freeorion_vs2010_sdk\freeorion\universe\RunQueue.tcc(61) : see reference to function template instantiation 'boost::shared_ptr<T>::shared_ptr<ThreadQueue<WorkItem>>(Y *)' being compiled
          with
          [
              T=ThreadQueue<`anonymous-namespace'::StoreTargetsAndCausesOfEffectsGroupsWorkItem>,
              WorkItem=`anonymous-namespace'::StoreTargetsAndCausesOfEffectsGroupsWorkItem,
              Y=ThreadQueue<`anonymous-namespace'::StoreTargetsAndCausesOfEffectsGroupsWorkItem>
          ]
          c:\freeorion_vs2010_sdk\freeorion\universe\RunQueue.tcc(49) : while compiling class template member function 'RunQueue<WorkItem>::RunQueue(unsigned int)'
          with
          [
              WorkItem=`anonymous-namespace'::StoreTargetsAndCausesOfEffectsGroupsWorkItem
          ]
          ..\..\universe\Universe.cpp(1469) : see reference to class template instantiation 'RunQueue<WorkItem>' being compiled
          with
          [
              WorkItem=`anonymous-namespace'::StoreTargetsAndCausesOfEffectsGroupsWorkItem
          ]
c:\freeorion_vs2010_sdk\freeorion\universe\RunQueue.tcc(35): error C2782: 'const _Ty &std::min(const _Ty &,const _Ty &)' : template parameter '_Ty' is ambiguous
          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2105) : see declaration of 'std::min'
          could be 'volatile unsigned int'
          or       'unsigned int'
Dilvish wrote:
Geoff the Medio wrote:Most turns, I hit the turn button an have to wait ~15 seconds for the AIs to finish playing with my turn button greyed out. During that time, various AI clients are using > 25% CPU. I don't think it's limited by the human client CPU use, which is generally at 25% or less doing single-threaded rending of the map.
Hmm, without knowing how many AIs you had in that game & how it compares to without the patch...
As noted above, it was default settings, so 6 AIs. In the SVN version, the AIs seem to play their turns in about 1 second at the start of a game. A randomly selected AI timing log is:

Code: Select all

2013-12-26 13:58:38,248 DEBUG AI : AI Module Time Requirements:
2013-12-26 13:58:38,248 DEBUG AI :                     PriorityAI:       32 msec  
2013-12-26 13:58:38,248 DEBUG AI :                  ExplorationAI:        1 msec  
2013-12-26 13:58:38,249 DEBUG AI :                 ColonisationAI:        1 msec  
2013-12-26 13:58:38,249 DEBUG AI :                     InvasionAI:        0 msec  
2013-12-26 13:58:38,249 DEBUG AI :                     MilitaryAI:        0 msec  
2013-12-26 13:58:38,249 DEBUG AI :               Gen_Fleet_Orders:        6 msec  
2013-12-26 13:58:38,249 DEBUG AI :             Issue_Fleet_Orders:        3 msec  
2013-12-26 13:58:38,249 DEBUG AI :                     ResearchAI:        5 msec  
2013-12-26 13:58:38,249 DEBUG AI :                   ProductionAI:       39 msec  
2013-12-26 13:58:38,249 DEBUG AI :                    ResourcesAI:        0 msec  
2013-12-26 13:58:38,249 DEBUG AI :                        Cleanup:        0 msec  
2013-12-26 13:58:38,249 DEBUG AI : AIInterface::DoneTurn()
2013-12-26 13:58:38,249 DEBUG AI : PythonAI::GenerateOrders order generating time: 134

User avatar
cami
Space Dragon
Posts: 411
Joined: Tue Sep 20, 2011 10:32 pm
Location: Halle (Saale)

Re: [PATCH] Parallel condition evaluation

#92 Post by cami »

Updated patch. Maybe MSVC treats "volatile unsigned" and "unsigned" as types that need casting. removed the volatile by explicit cast, now it's all plain unsigned int, if that still doesnt work, will explicitly specify the template parameter (want to avoid this as it will silence all complaints).

I also modified Schedule() to avoid rescheduling when it doesnt make sense, as the code caused busy wait for work by rescheduling <16 workitems, resulting in the scheduling thread to sometimes get no work, and schedule again. Also made Schedule() quit immediately when work has been scheduled for the thread (e.g. by some other thread) in the meantime.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]

Yesterday, we were still on the brink. Fortunately, today we have come one step further.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: [PATCH] Parallel condition evaluation

#93 Post by Dilvish »

Geoff the Medio wrote:As noted above, it was default settings, so 6 AIs. In the SVN version, the AIs seem to play their turns in about 1 second at the start of a game.
Ah, I had overlooked the default settings part, and also made the poor assumption you meant at the start of loading a game, rather than at the start of a new game, since I wasn't seeing anything like that amount of time being take under the patch at the start of a new game. Something very odd is going on there for sure if an AI is taking 15-20 seconds per turn at the start of a default settings game.

As for the AI spending a lot of time on productionCost and productionTime, I agree with Geoff that since the AIs are all on separate threads already it probably wouldn't help a lot to parallelize those (though in late-game with only 1 or 2 big AIs it might). If we wanted to try that, though, I do think I know which of the calls to these functions are consuming the most time, and it would be easy enough to change that to work with a vector of planetIDs. I also think there is a fair bit of room for improvement within the python code to reduce this burden-- for example, once an empire has researched Laser 4 it could throw out all designs that use Laser 3. (I seem to recall it might be *possible* to script up content that could take tech away from an empire, but I think it would be reasonable to leave dealing with that for later.)
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [PATCH] Parallel condition evaluation

#94 Post by Geoff the Medio »

cami wrote:Updated patch.
It builds OK now, but the result isn't very playable. First quickstart, it hung at generating universe. I killed it, tried again, and it got into the game, but hung after pressing turn once. Third try, it hung on the second press of turn. None of the processes are using any CPU except the human client, which is doing normal rendering work, a bit under using one core fully.

Log attached.
freeoriond.log
log for attempted game
(239.47 KiB) Downloaded 99 times
Will also retry with a fully clean rebuild.
Edit: Same result... Pressed turn button on first turn. AIs and server are using 0 CPU. Client is rendering, using a core, or 0% when minimized.

User avatar
cami
Space Dragon
Posts: 411
Joined: Tue Sep 20, 2011 10:32 pm
Location: Halle (Saale)

Re: [PATCH] Parallel condition evaluation

#95 Post by cami »

This should kill off the deadlock, but might reinstantiate part of the pointless schedule runs.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]

Yesterday, we were still on the brink. Fortunately, today we have come one step further.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [PATCH] Parallel condition evaluation

#96 Post by Geoff the Medio »

Can I safely ignore the server connect timout change you've included in the patch?

User avatar
cami
Space Dragon
Posts: 411
Joined: Tue Sep 20, 2011 10:32 pm
Location: Halle (Saale)

Re: [PATCH] Parallel condition evaluation

#97 Post by cami »

Yes, of course, sorry, that was only for valgrind and I forgot about it.
Yesterday, we were still on the brink. Fortunately, today we have come one step further.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: [PATCH] Parallel condition evaluation

#98 Post by Dilvish »

I've started new threads for the discussion of the main python cpu cycle consumers:

getBestShipRatings
and
evaluatePlanet
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [PATCH] Parallel condition evaluation

#99 Post by Geoff the Medio »

The l patch seems to run OK. I was using the latest SVN AI updates Dilvish committed (6587), but there was neither deadlock nor unusually long AI processing times during the 12 turns I ran to test. Whether it helps or hinders processing time for larger games, I haven't tested.

User avatar
cami
Space Dragon
Posts: 411
Joined: Tue Sep 20, 2011 10:32 pm
Location: Halle (Saale)

Re: [PATCH] Parallel condition evaluation

#100 Post by cami »

Then I suppose your long AI times were due to the many Schedule() calls. They should be reduced sigificantly in the last patch (or at least, much cheaper in pointless calls)
Yesterday, we were still on the brink. Fortunately, today we have come one step further.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [PATCH] Parallel condition evaluation

#101 Post by Geoff the Medio »

Anybody else tested the l version?

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: [PATCH] Parallel condition evaluation

#102 Post by Vezzra »

Geoff the Medio wrote:Anybody else tested the l version?
Just did a more extensive test. Building and running works fine, played until turn 152. So far most things seem ok, but there is something amiss with resource meters. I've attached three savegames, for turns 150 - 152. I noticed several planets where huge "unkown" bonus/malus amounts for the industry meter randomly appear and disappear. Look at the planets in the Sadr and the Sargas systems. Maybe there are even more, I didn't check every planet every turn, but these I noticed. This definitely doesn't look right.
Attachments
FreeOrion_Vezzra_Terran_0152_20131230_153155.sav.zip
Savegame for turn 152
(440.13 KiB) Downloaded 100 times
FreeOrion_Vezzra_Terran_0151_20131230_152210.sav.zip
Savegame for turn 151
(432.64 KiB) Downloaded 85 times
FreeOrion_Vezzra_Terran_0150_20131230_151708.sav.zip
Savegame for turn 150
(429.81 KiB) Downloaded 93 times

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [PATCH] Parallel condition evaluation

#103 Post by Geoff the Medio »

I'm seeing similar-looking seemingly-random changes to resource meters of an AI planet while playing as an observer. No changes to focus settings, but the target research / production meter values are bouncing around by huge amounts from each turn to the next.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: [PATCH] Parallel condition evaluation

#104 Post by Dilvish »

ok cami, now that we finished helping Geoff fix up his containment patch, it seems like we should get back to this one. It won't quite fully apply for me now, though, I was hoping you could update the patch to the current SVN...
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [PATCH] Parallel condition evaluation

#105 Post by Geoff the Medio »

Dilvish wrote:It won't quite fully apply for me now, though, I was hoping you could update the patch to the current SVN...
I was able to apply the l patch to the latest SVN without problem...

Attached is the same, but generated against the lastest SVN.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]


Post Reply