[RESOLVED] Parallel condition evaluation

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

Moderator: Committer

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

Re: [PATCH] Parallel condition evaluation

#76 Post by cami »

Please delete RunQueue.h, RunQueue.tcc, TemporaryPtr.tcc and EnableTemporaryFromThis.tcc before applying the patch. I only added one call to std::min, and I'm certain I parenthesed it. If deletion doesn't help, I may have accidently attached an old patch, in that case, please be patient, I'll regenerate it asap.
Yesterday, we were still on the brink. Fortunately, today we have come one step further.

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

Re: [PATCH] Parallel condition evaluation

#77 Post by Vezzra »

I've downloaded the latest patch and given it a try. I applied it against rev 6569 (as this is the revision it is based upon), no problems building.

I ran into my usual hassles getting an observer game running (see my post here), but finally got past that. Game settings were 5 AI, irregular galaxy, 150 systems, high planet density, everything else on default. Crash on turn 243, but that might be related to me being dragging around the map at that time. Because I started I second game, with more "demanding" settings (to try push the limits a bit, after all, this patch is supposed to speed things up ;)), 10 AI, elliptical, 500 systems, rest default. Just did some map dragging in the beginning to get a good view of at least a portion of the map, then didn't touch the FO window again.

This second game is still running as I write this post. Current turn is 315! (EDIT: game finally crashed on turn 399, crash occurred in the server process) The one test game I ran with an unpatched build that didn't crash has been quit on turn 303, and that game had less demanding settings. So I think this latest version of the patch is ok as far as OSX is concerned. Speed gains seem to be considerable!

One strange thing I'm observing in this test game: There are some white ships showing up. What are these?!

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

#78 Post by Geoff the Medio »

cami wrote:Please delete [stuff] before applying the patch.
Ah yes. I likely neglected to do that. Rebuilding...

Edit: Didn't help; I don't think the errors are related to that macro issue.

I'm having a hard time figuring out what to change though... I added a template parameter to the std::min call to specify that the output is unsigned int, but the remaining error message still says

Code: Select all

RunQueue.tcc(35): error C2664: 'const _Ty &std::min<size_type>(const _Ty &,const _Ty &)' : cannot convert parameter 2 from 'volatile unsigned int' to 'const size_type &'
... I don't know why it's trying to convert to size_type.

It's happy if I replace the (schedule_queue_size + 1)/2 with 50u...

Trying storing the X+1/2 in a separate variable of type unsigned int... ... Seems to like that.

Could you declare the variables "unsigned int" rather than just "unsigned" for clarity? Doesn't help the problem, but is preferable to me.

Edit more: attached version built OK
RunQueue.zip
version that built for me, cleaned up whitespace a bit
(1.68 KiB) Downloaded 89 times
Edit again: With those changes, it will build and run. The main change I note is that AIs are taking a lot longer to play their turns: something like 20 seconds at the start of the game with default settings.

From AI_1.log:

Code: Select all

2013-12-24 11:42:35,717 DEBUG AI : AI Module Time Requirements:
2013-12-24 11:42:35,717 DEBUG AI :                     PriorityAI:     3973 msec  
2013-12-24 11:42:35,717 DEBUG AI :                  ExplorationAI:        1 msec  
2013-12-24 11:42:35,717 DEBUG AI :                 ColonisationAI:        1 msec  
2013-12-24 11:42:35,717 DEBUG AI :                     InvasionAI:      530 msec  
2013-12-24 11:42:35,717 DEBUG AI :                     MilitaryAI:        0 msec  
2013-12-24 11:42:35,717 DEBUG AI :               Gen_Fleet_Orders:       29 msec  
2013-12-24 11:42:35,717 DEBUG AI :             Issue_Fleet_Orders:      468 msec  
2013-12-24 11:42:35,717 DEBUG AI :                     ResearchAI:        5 msec  
2013-12-24 11:42:35,717 DEBUG AI :                   ProductionAI:     1384 msec  
2013-12-24 11:42:35,717 DEBUG AI :                    ResourcesAI:    10601 msec  
2013-12-24 11:42:35,717 DEBUG AI :                        Cleanup:        0 msec  
2013-12-24 11:42:35,717 DEBUG AI : AIInterface::DoneTurn()
2013-12-24 11:42:35,717 DEBUG AI : PythonAI::GenerateOrders order generating time: 18022
Also, apparently it's spending an oddly long time to update 0 objects' meters:

Code: Select all

2013-12-24 11:42:36,330 DEBUG AI : PythonAI::GenerateOrders : initializing turn
2013-12-24 11:42:36,331 DEBUG AI : Universe::InitMeterEstimatesAndDiscrepancies
2013-12-24 11:42:37,054 DEBUG AI : Issue times: planet species: 0 ship species: 0 specials: 0 techs: 0 buildings: 0 hulls/parts: 0 fields: 0Evaluation time: 717
2013-12-24 11:42:37,074 DEBUG AI : Universe::UpdateMeterEstimatesImpl on 0 objects time: 743
2013-12-24 11:42:44,304 DEBUG AI : Issue times: planet species: 0 ship species: 0 specials: 0 techs: 1 buildings: 0 hulls/parts: 0 fields: 0Evaluation time: 7221
2013-12-24 11:42:44,319 DEBUG AI : Universe::UpdateMeterEstimatesImpl on 0 objects time: 7244
Possibly that's actually updating all objects' meters, though? (edit: yes, I think that's the case)

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

Re: [PATCH] Parallel condition evaluation

#79 Post by Dilvish »

Cami, now that Geoff has committed the TemporaryPtr patch to SVN, please post a version of this patch relative to current SVN version.
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
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: [PATCH] Parallel condition evaluation

#80 Post by Dilvish »

Geoff the Medio wrote:The main change I note is that AIs are taking a lot longer to play their turns: something like 20 seconds at the start of the game with default settings.
I think it would be necessary to look at the total time taken by all clients (player and AIs) together. The human client has a higher priority than AI clients and can now claim greater resources then before (on my machine I often see it going above it's previous max cpu consumption), which would make the AI clients take a longer elapsed user-time. It seems possible the threading might also affect how time gets apportioned between AI clients.

I'll try to look into the AI issue in more detail.
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

#81 Post by Geoff the Medio »

Dilvish wrote:I think it would be necessary to look at the total time taken by all clients (player and AIs) together.
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.

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

Re: [PATCH] Parallel condition evaluation

#82 Post by cami »

Because the 2 and the 1 are int by default, I guess it converts everything to 64 bit signed to avoid loss of information. there is no template overloar for std::min with a 64 bit signed and a 32 bit unsigned argument. using 2U and 1U as constants probably will fix it.
MSVC seems to be a lot pickier than gcc, but that's a good thing in general. Explicit is better than implicit.



I cannot reproduce the long AI times, theyre up to 2x faster in fact on my machine. Maybe creating threads is very expensive on windows? Or the synchronization implementation is poorly suited for the kinds of algorithms used? Can just guess wildly, but nothing comes to my mind that really makes sense.
Last edited by cami on Tue Dec 24, 2013 11:29 pm, edited 1 time in total.
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

#83 Post by Geoff the Medio »

cami wrote:MSVC seems to be a lot pickier than gcc, but that's a good thing in general. Explicit is better than implicit.
Sometimes, but not always. Frequently I or another MSVC coder will commit things that MSVC compiles fine, but which gcc objects to for (sometimes obscure) reasons. I generally tend to think having multiple compilers being used to build FreeOrion code regularly helps it be better code overall... or at least more technically correct.

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

Re: [PATCH] Parallel condition evaluation

#84 Post by cami »

Dilvish wrote:Cami, now that Geoff has committed the TemporaryPtr patch to SVN, please post a version of this patch relative to current SVN version.
Of course. Tomorrow (well, lets say in about 18 hours, with different timezones tomorrow is a very fuzzy term) I might get a chance to do so.
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

#85 Post by Dilvish »

stability test -- observer mode multiplayer, 300 systems, elliptical, everything medium density, 10 AIs. Running stable for 8 hours now, at turn 620. Without the patch I don't think I could have gotten past 400 turns in this time (and of course the later turns take more time due to so many more ships). Of course, I'm thinking I really need to work on the AI's ability to finish off opponents when it has a big lead...
advanced.png
advanced.png (319.4 KiB) Viewed 1163 times
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
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: [PATCH] Parallel condition evaluation

#86 Post by Dilvish »

Vezzra wrote:One strange thing I'm observing in this test game: There are some white ships showing up. What are these?!
As I recall, we had those appear once before when there was an issue with the visibility code. Double checking the FleetButton code now, I see that a fleet gets colored white when it is flagged as owned by ALL_EMPIRES, but does not contain any ships that test positive via IsMonster(). If you see them again pls get a data dump from the objects window, that might help a little.
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
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: [PATCH] Parallel condition evaluation

#87 Post by Dilvish »

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, I can't really figure out the significance of those numbers (& I still think I'd need to know the total times to really compare).If you have log files for a few turns (a set with the patch and a set without the patch, from the same saved game & same turn range) I'd be happy to look at them. I'll also try to run my own tests tomorrow.
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
cami
Space Dragon
Posts: 411
Joined: Tue Sep 20, 2011 10:32 pm
Location: Halle (Saale)

Re: [PATCH] Parallel condition evaluation

#88 Post by cami »

Updated the patch. Runs stable on my machine.
Attachments

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

Last edited by cami on Wed Dec 25, 2013 4:54 pm, edited 1 time in total.
Yesterday, we were still on the brink. Fortunately, today we have come one step further.

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

Re: [PATCH] Parallel condition evaluation

#89 Post by cami »

Dilvish wrote:
Vezzra wrote:One strange thing I'm observing in this test game: There are some white ships showing up. What are these?!
As I recall, we had those appear once before when there was an issue with the visibility code. Double checking the FleetButton code now, I see that a fleet gets colored white when it is flagged as owned by ALL_EMPIRES, but does not contain any ships that test positive via IsMonster(). If you see them again pls get a data dump from the objects window, that might help a little.
After watching an AI game, it seemed that AI became completely overrun be monsters in late midgame. Seemingly, monsters captured enemy ships or planets producing them, definitely monster fleets somehow obtained ships that have been produced by AI. Such fleets then appear white.
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

#90 Post by Dilvish »

cami wrote:After watching an AI game, it seemed that AI became completely overrun be monsters in late midgame. Seemingly, monsters captured enemy ships or planets producing them, definitely monster fleets somehow obtained ships that have been produced by AI. Such fleets then appear white.
Ah, if you still have that savegame, perhaps you can check if there was a Psionic Snowflake running around? I recall them being able to take over ships & that would result in the white fleets.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Post Reply