FreeOrion

Forums for the FreeOrion project
It is currently Mon Dec 18, 2017 6:38 pm

All times are UTC


Forum rules


Always mention the exact version of FreeOrion you are testing.

When reporting an issue regarding the AI, if possible provide the relevant AI log file and a save game file that demonstrates the issue.



Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Aug 10, 2016 4:09 am 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3295
I'm playing a big game, one of the largest maps I've played for years, and set on Medium planets, not Low.

It's turn 220, my fleet now contains 199 vessels and I've over 200 colonies and outposts. A year ago, those numbers would've seen me scrapping ships frantically and considering whether to end the game because lag was making it almost unplayable. I'm not now. This is really cool.

A chunk of recent changes, including the way supply propagation is worked out/displayed and changes to population scripts making them substantially more efficient appears to have had, for me, a substantial reduction in lag—manual focus changes and queuing of production items still has lag, but at nowhere near the "go and make a coffee" level it was, until recently, causing at this stage in a game.

I'm on a quad-core Linux box with passable integrated graphics, I'm curious if others have noticed improvements on their systems, especially in the last few weeks, and/or if there are some systems where t hasn't really made any difference?

I also want to specifically thank our relatively new contributors, LGM-Doyle and Dbenage-CX, it's largely (but not exclusively—Geoff specifically suggested some of the changes would help) been their work that's made these improvements and as lag has been something that virtually everyone (especially me) has been complaining about for years such a significant improvement is definitely worth commenting on. Thanks guys.

So, on an unrelated note, I'm in the mood to play a really big map with challenging settings that I've not been able to do for ages. I'm thinking probably a large spiral, what do people think would make the most challenging setup (for a player) on a really big galaxy?

_________________
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.


Top
 Profile  
 
PostPosted: Thu Aug 11, 2016 11:40 pm 
Offline
Krill Swarm

Joined: Mon Aug 08, 2016 3:24 am
Posts: 10
I mostly play on a wimpy little laptop, and the latest test builds are definitely better than the official v0.4.5 release from 2015-09-01, which I was playing until just recently. The UI still starts to get a bit laggy in late game, but it's not as bad as it was. Good work!


Top
 Profile  
 
PostPosted: Fri Aug 12, 2016 1:30 pm 
Offline
Dyson Forest
User avatar

Joined: Sun Feb 28, 2016 9:56 pm
Posts: 202
Location: Sweden
Good to hear that computing time has improved, indeed.
I'd say "clusters" all the way - very hard to anticipate where the game is going! :mrgreen:

_________________
| i7 2600K quad@3.40Ghz | GTX 560 Ti | RAM: 16GB | PSU: 750w | W7 x64 | LG1680x1050+Acer 1280x1024 |


Top
 Profile  
 
PostPosted: Sun Aug 14, 2016 5:37 am 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3295
K, by the end of the game (see Timed that one nicely for a screenshot), production was at 30K with a 38K target, I had 3042 planets and 331 ships.

Lag was at a point that it was annoying me, but I've played on with much higher lag levels on much smaller games.

The problem isn't solved, but it is reduced so much that it's no longer something I'd consider game-breaking at higher levels. This is a really good thing.

Of course, I now wonder where else we can find efficiencies in the scripts to improve performance. I'm especially wondering if there's any way we can improve ship/fleet handling, as killing all my ships after victory did speed things up a bit the next turn.

However, that sort of thing is beyond me and it's mostly guesswork—any ideas from the better coders?

_________________
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.


Top
 Profile  
 
PostPosted: Sun Aug 14, 2016 7:02 am 
Offline
Dyson Forest
User avatar

Joined: Sun Feb 28, 2016 9:56 pm
Posts: 202
Location: Sweden
Thanks for the report!

Does FO use all available cores when computing turns? I guess so.
A fast computer does help, but of course the aim should be to make FO playable on slower machines as well.

FYI, I have never considered the lag, not even at turn >500. However, I have only run 3 AI's at moderate difficulty and ca 150 systems. Ending turn takes ca 2-3 seconds.
Unless the code can be further optimized, the solution is perhaps to limit the number of AI? In this case, "less is more" :mrgreen:

_________________
| i7 2600K quad@3.40Ghz | GTX 560 Ti | RAM: 16GB | PSU: 750w | W7 x64 | LG1680x1050+Acer 1280x1024 |


Top
 Profile  
 
PostPosted: Sun Aug 14, 2016 9:11 am 
Offline
Juggernaut

Joined: Mon Feb 04, 2013 10:15 pm
Posts: 759
Bromstarzan wrote:
Does FO use all available cores when computing turns? I guess so.


Each AI has it's own thread.


Top
 Profile  
 
PostPosted: Sun Aug 14, 2016 9:14 am 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4314
Location: Sol III
Bromstarzan wrote:
Does FO use all available cores when computing turns?
Unless you count the AI client processes (see Andrews reply), nope. The server (which is the component that does the turn processing) is essentially single-threaded.


Top
 Profile  
 
PostPosted: Sun Aug 14, 2016 12:58 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12046
Location: Munich
Vezzra wrote:
The server (which is the component that does the turn processing) is essentially single-threaded.
Effects processing on the server (and clients) is multi-threaded by default. Whether this makes any substantial difference to processing times, I'm not sure.


Top
 Profile  
 
PostPosted: Sun Aug 14, 2016 7:29 pm 
Offline
Programmer

Joined: Mon Feb 29, 2016 8:37 pm
Posts: 205
MatGB your post pushed me over the hurdle to finish PR #863, to address lag when splitting large fleets.

Since you asked to help, I will make two requests.

The first is, if you still have the saved game handy, can you do a before and after test of PR #863. Load the save game and measure the time to merge and split your largest fleet. That would give another data point about how the PR performs.

The second is do you have any specific examples of performance problems from late in the large game.

Everything getting faster after you destroy all of your ships is not concrete enough for me to address.

An example might clarify what I mean.

When I started work on PR #863, I started with one fleet button that took a long time to split. I wrote increasing sophisticated profiling code around that one event, until I figured out exactly why it was slow. Then I fixed what I could.

Thanks in advance.

p.s. Edited to fix the PR number.


Last edited by LGM-Doyle on Sun Aug 14, 2016 8:27 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Aug 14, 2016 7:37 pm 
Offline
Vacuum Dragon

Joined: Wed Aug 26, 2015 6:15 pm
Posts: 508
AndrewW wrote:
Bromstarzan wrote:
Does FO use all available cores when computing turns? I guess so.


Each AI has it's own thread.

I thought they were separate processes.


Top
 Profile  
 
PostPosted: Sun Aug 14, 2016 8:05 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4314
Location: Sol III
LGM-Doyle wrote:
MatGB your post pushed me over the hurdle to finish PR #862, to address lag when splitting large fleets.
Um, I assume you actually mean PR#863 here (and the other two links too)? I was a bit confused when I clicked that link and issue #862 opened, which is about something entirely different...


Top
 Profile  
 
PostPosted: Sun Aug 14, 2016 10:02 pm 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3295
LGM-Doyle wrote:
MatGB your post pushed me over the hurdle to finish PR #863, to address lag when splitting large fleets.

Since you asked to help, I will make two requests.

The first is, if you still have the saved game handy, can you do a before and after test of PR #863. Load the save game and measure the time to merge and split your largest fleet. That would give another data point about how the PR performs.

Merge and split before and after wasn't that bad on a fresh load up—I've noticed in the past that lag gets worse as you play multiple turn, and it always reduces if you load a frech game.

However, there was a noticeable improvement. Merging and splitting the doomstack of ~240 ships in orbit around the Experimentors took just less than a second on my previous compile, having compiled that branch it was almost lag free, so fast I couldn't time it manually.

Having said that, I noted yesterday when scrapping the fleets that the fleet-scrapping time had been substantially reduced as well, it used to take an age to scrap a large fleet but it was a negligible time for the large fleets using Master. I have no idea when this improved or why but whatever did it is also welcome (I've been in the habit recently of just finishing a game when I know I've won, so fleet scrapping has been something I've done less of).
Quote:
The second is do you have any specific examples of performance problems from late in the large game.

Everything getting faster after you destroy all of your ships is not concrete enough for me to address.

Specifically, things like queuing a production item, especially a ship, and changing a build order to increase the number of ships or to add repeats, always substantially laggy, and still a problem.

Also, changing focus with the sidepanel open—using the Objects menu context option for multiple changes is always very quick, unless the sidepanel is open with one of the changing planets displayed, at which point it slows to a substantial crawl.

Queuing a large number of buildings on different planets via Objects can take a LONG time to process—substantially faster than going into each system and doing it manually but the lag is still noticeable and into the several seconds point: I normally only do this for terraform or Gaia transform orders (in this game I had virtually every planet turned into a paradise because I had the resources).

Being able to queue from Objects is brilliant, and overall it's substantially faster, but if you try to queue multiple planets at once (I did batches of about 20 planets) then it takes awhile.

I've uploaded a savegame as an issue on my personal git profile, there's almost certainly a better way to do it but...
Large savegame double victory with huge fleet · Issue #1 · MatGB/FO-shared-files

_________________
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.


Top
 Profile  
 
PostPosted: Mon Aug 15, 2016 6:49 am 
Offline
Programmer

Joined: Mon Feb 29, 2016 8:37 pm
Posts: 205
MatGB thanks for the testing reports.

Do you build for Release or Debug?

Thanks for the observation about the sidepanel greatly slowing down the game. I had not noticed that.

That is specific enough for me to replicate.

I will not guarantee an improvement, but I will look at the issue.


Top
 Profile  
 
PostPosted: Mon Aug 15, 2016 7:48 am 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3295
I think I build for Release, but I never intentionally changed or set the settings and am not sure I'd know how, I was walked through how to compile on Linux just after I got this box on here and haven't done anything to change setup since then.

_________________
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.


Top
 Profile  
 
PostPosted: Mon Aug 15, 2016 10:10 am 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4314
Location: Sol III
Looking at the cmake files indicate that the default build type is release, so unless you set it to debug (and your answer implies you did not) you get a release build.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: Hyperant and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group