About freeorion's performance

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

Moderators: Committer, Committer

Message
Author
OttOXBerlin
Space Krill
Posts: 3
Joined: Fri Nov 21, 2014 6:09 am

Re: About freeorion's performance

#16 Post by OttOXBerlin » Tue Nov 25, 2014 11:12 pm

Vezzra wrote:
OttOXBerlin wrote:Uuh, im from germany and my english was bad...
Nun, wenn's auf Englisch gar nicht geht, dann versuch halt, das Problem auf Deutsch zu erklären. Der eine oder andere hier hat Deutsch als Muttersprache (ich zB), als Notlösung geht das also... ;)
Wäre mir echt lieber, bei mir schwirren halt eher Zahlen als Wörter durch n Kopp XD

Bei zunehmender Spieldauer, und dabei ist es völlig egal wieviele Sternsysteme oder Ki-Spieler dabei sind, lahmt das Spiel in der Nahansicht, also soweit herreingezoomt das eben die Namen der einzelnen Systeme angezeigt werden, so ziemlich.
Das tritt dann gerne mal auf wenn man einen Aufklärungsradius von 300/400 hat...

Und in solchen Fällen ist es zb beinahe unmöglich einer neuen "Raumschiffkreation" einen Namen zu geben (Eingabeverzögerung usw), jedenfalls wenn man da nicht auf einen kleinen Trick zurückgreift.(Copy&Paste)

Das soll auch hier keine Kritik oder Gejammer sein, nur son Fingerzeig...
Mitten.O wrote:Perhaps you should try the latest testing release. Certain rendering performance improvements have landed after 0.4.4 was released. It would be of interest to hear how they affect you.
okey.. i try it...

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

Re: About freeorion's performance

#17 Post by Dilvish » Tue Nov 25, 2014 11:24 pm

Ah, ok, as near as I can tell, this sounds like yet another instance of someone running into trouble with lag in the design name edit box; I will try to follow up with a solution soon.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

OttOXBerlin
Space Krill
Posts: 3
Joined: Fri Nov 21, 2014 6:09 am

Re: About freeorion's performance

#18 Post by OttOXBerlin » Tue Nov 25, 2014 11:34 pm

oh.. very fast peoples here :)

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: About freeorion's performance

#19 Post by MatGB » Tue Nov 25, 2014 11:42 pm

Dilvish wrote:Ah, ok, as near as I can tell, this sounds like yet another instance of someone running into trouble with lag in the design name edit box; I will try to follow up with a solution soon.
I would, definitely, dump the idea of dynamically updating the top title, it's perfectly fine if that only changes when someone hits 'save' for the design and it was definitely part of the problem for me.
Mat Bowles

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

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: About freeorion's performance

#20 Post by Bigjoe5 » Thu Nov 27, 2014 4:36 pm

MatGB wrote: I would, definitely, dump the idea of dynamically updating the top title, it's perfectly fine if that only changes when someone hits 'save' for the design and it was definitely part of the problem for me.
There's no reason to dump that idea, IMO - that kind of thing shouldn't be causing noticeable lag for anyone. If it is, something is terribly wrong.
(I'm assuming you mean the title is updated to match the text in the name field.)
Warning: Antarans in dimensional portal are closer than they appear.

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

Re: About freeorion's performance

#21 Post by Dilvish » Thu Nov 27, 2014 5:21 pm

Bigjoe5 wrote:There's no reason to dump that idea, IMO - that kind of thing shouldn't be causing noticeable lag for anyone. If it is, something is terribly wrong. (I'm assuming you mean the title is updated to match the text in the name field.)
I'm pretty sure that is indeed the problem; the previous iteration didn't do the dynamic page update and didin't have this lag problem. At first it had been even much worse, but I reorganized it a bit & got it so that it worked fine for most people. But there might still be some flaw I overlooked. One thing that comes to mind as a likely culprit is that changing the title causes the pedia page to be completely updated, which in this case causes a new ship to be created & Effects updated to get the new stats. Perhaps those stats need to be saved so that they could be reused if only the name changes rather than having to redo all that. I'm short on time these days so if you want to look into that it would be great.
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: About freeorion's performance

#22 Post by Dilvish » Fri Nov 28, 2014 11:45 pm

I implemented a 'hidden' option to control this; the default is to remain dynamic.

Code: Select all

r7774 | dilvish-fo | 2014-11-28 15:41:13 -0800 (Fri, 28 Nov 2014) | 1 line
added a UI.design-pedia-dynamic option to control  in the Design Window whether or not the design detail pedia page will be dynamically updated as the design name is edited (causes lag on some machines).  No current options page UI widget; can be changed on command line or by editing config
To change in the config file just search for "design-pedia-dynamic" and change its value (default '1') to a '0'
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
Vezzra
Release Manager, Design
Posts: 5186
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: About freeorion's performance

#23 Post by Vezzra » Sun Nov 30, 2014 1:10 pm

OttOXBerlin wrote:Bei zunehmender Spieldauer, und dabei ist es völlig egal wieviele Sternsysteme oder Ki-Spieler dabei sind, lahmt das Spiel in der Nahansicht, also soweit herreingezoomt das eben die Namen der einzelnen Systeme angezeigt werden, so ziemlich.
Das tritt dann gerne mal auf wenn man einen Aufklärungsradius von 300/400 hat...
Das ist ein altbekanntes Problem. Für Version 0.4.4 wurden da schon einige Optimierungen vorgenommen, um diesen Late-Game-Lag zu reduzieren, frühere Versionen waren diesbezüglich noch um einiges schlimmer. Es gibt aber sicher noch eine Menge Potential für weitere Optimierung, das Ganze ist halt recht aufwendig und nicht das einzige auf der Todo-Liste der Programmierer ;)

Sprich, da müssen wir uns noch in Geduld üben. Es kann noch eine ganze Weile dauern, bis wir da weitere Fortschritte machen.
Und in solchen Fällen ist es zb beinahe unmöglich einer neuen "Raumschiffkreation" einen Namen zu geben (Eingabeverzögerung usw), jedenfalls wenn man da nicht auf einen kleinen Trick zurückgreift.(Copy&Paste)
Auch das ist bereits mehrfach bemängelt worden, Dilvish scheint jetzt einen Versuch unternommen zu haben, zumindest dieses Problem ein bißchen zu lindern. Wenn ich das recht verstanden habe, muß man dazu aber mit einem Texteditor eine entsprechende Option in der config.xml einschalten. Montag (also morgen) habe ich vor, neue Test Builds zu produzieren, die werden diesen Fix bereits enthalten.

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

Re: About freeorion's performance

#24 Post by Vezzra » Sun Nov 30, 2014 1:13 pm

Dilvish wrote:Ah, ok, as near as I can tell, this sounds like yet another instance of someone running into trouble with lag in the design name edit box
Yep, he pointed that out in particular, but he also mentioned the increasing lag during late game in general. Which, of course, is a long term project...

pheldens
Pupating Mass
Posts: 96
Joined: Fri Mar 15, 2013 12:54 pm

Re: About freeorion's performance

#25 Post by pheldens » Wed Jun 24, 2015 11:15 am

I think the general slowness, even when not doing anything, is caused by cpu load, not GPU load.

Text rendering seems slow, when testing it in the researchtree, zoom out till text is gone ; fps rises , zoom slightly back in till text appears ; 75% fps hit from 50 to 10 fps

All the while the Graphics GPU performance meter in radeontop never goed above 50%
But the CPU is always maxing out 1 3.4GHZ core.


When I strace the game and am at the opening screen menu doing nothing (but also anywhere else in the game), I get a constant stream of this;
futex(0xbaf864, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xbaf860, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xbaf838, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc45e6c, FUTEX_WAIT_PRIVATE, 11321, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0xc45e40, FUTEX_WAKE_PRIVATE, 1) = 0
ioctl(8, 0x40086464, 0x7ffcfe469d90) = 0
ioctl(8, 0xc008646a, 0x7ffcfe469cc0) = 0
futex(0xbaf864, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xbaf860, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xbaf838, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc45e6c, FUTEX_WAIT_PRIVATE, 11323, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0xc45e40, FUTEX_WAKE_PRIVATE, 1) = 0
ioctl(8, 0x40086464, 0x7ffcfe469d90) = 0
ioctl(8, 0xc008646a, 0x7ffcfe469cc0) = 0
futex(0xbaf864, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xbaf860, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xbaf838, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc45e6c, FUTEX_WAIT_PRIVATE, 11325, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0xc45e40, FUTEX_WAKE_PRIVATE, 1) = 0
ioctl(8, 0x40086464, 0x7ffcfe469d90) = 0
ioctl(8, 0xc008646a, 0x7ffcfe469cc0) = 0
futex(0xbaf864, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xbaf860, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xbaf838, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc45e6c, FUTEX_WAIT_PRIVATE, 11327, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0xc45e40, FUTEX_WAKE_PRIVATE, 1) = 0
ioctl(8, 0x40086464, 0x7ffcfe469d90) = 0
ioctl(8, 0xc008646a, 0x7ffcfe469cc0) = 0
futex(0xbaf864, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xbaf860, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xbaf838, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc45e6c, FUTEX_WAIT_PRIVATE, 11329, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0xc45e40, FUTEX_WAKE_PRIVATE, 1) = 0
ioctl(8, 0x40086464, 0x7ffcfe469d90) = 0
ioctl(8, 0xc008646a, 0x7ffcfe469dc0) = 0
futex(0xbaf864, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xbaf860, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xbaf838, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc45e6c, FUTEX_WAIT_PRIVATE, 11331, NULL) = 0
futex(0xc45e40, FUTEX_WAKE_PRIVATE, 1) = 0
ioctl(8, 0x40086464, 0x7ffcfe469e90) = 0
ioctl(8, 0x40086464, 0x7ffcfe46b150) = 0
ioctl(8, 0xc008646a, 0x7ffcfe46b050) = 0
futex(0xbaf864, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xbaf860, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xbaf838, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc45e6c, FUTEX_WAIT_PRIVATE, 11333, NULL) = 0
futex(0xc45e40, FUTEX_WAKE_PRIVATE, 1) = 0
poll([{fd=6, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=6, revents=POLLOUT}])
writev(6, [{"\223\1\22\0\24\0\200\1\35\0\200\1\316\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 72}], 1) = 72
recvmsg(6, 0x7ffcfe46afb0, 0) = -1 EAGAIN (Resource temporarily unavailable)
select(7, [6], NULL, NULL, {0, 0}) = 0 (Timeout)
poll([{fd=6, events=POLLIN}], 1, 4294967295) = 1 ([{fd=6, revents=POLLIN}])
recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"#\223\335\3\0\0\0\0\2\0\0\0\27\0\200\1\24\0\200\1\316\2\0\0\35\0\200\1\36\0\200\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 72
ioctl(8, 0xc008646a, 0x7ffcfe46abd0) = 0
ioctl(8, 0xc008646a, 0x7ffcfe46abd0) = 0
ioctl(8, 0xc008646a, 0x7ffcfe46abd0) = 0
ioctl(8, 0xc008646a, 0x7ffcfe469c10) = 0
futex(0xbaf864, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xbaf860, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xbaf838, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc45e6c, FUTEX_WAIT_PRIVATE, 11335, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0xc45e40, FUTEX_WAKE_PRIVATE, 1) = 0
ioctl(8, 0x40086464, 0x7ffcfe469ce0) = 0
ioctl(8, 0xc008646a, 0x7ffcfe469cc0) = 0
futex(0xbaf864, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xbaf860, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xbaf838, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc45e6c, FUTEX_WAIT_PRIVATE, 11337, NULL) = -1 EAGAIN (Resource temporarily unavailable)

pheldens
Pupating Mass
Posts: 96
Joined: Fri Mar 15, 2013 12:54 pm

Re: About freeorion's performance

#26 Post by pheldens » Wed Jun 24, 2015 2:26 pm

Resizing windows (ie the fleet list) is also extremely slow, it makes the program hang and stutter at 1 fps for a while.

I tried profiling the program, but can't find a clear obvious place in the code that causes it, but relatively alot of time was spent in strcmp_sse2

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

Re: About freeorion's performance

#27 Post by Dilvish » Wed Jun 24, 2015 3:27 pm

pheldens wrote:But the CPU is always maxing out 1 3.4GHZ core.
?!? What kind of 3.4GHz core? For me, just checking now on turn 277 of a 500 system game with 14 AIs, the game idles at only 7% of a 3.5GHz core (of an i7 4770K), and the server and the AI processes idle at zero. Pressing next turn causes those all to momentarily jump to 5% to 10%, but they settle back down after a few seconds.
When I strace the game and am at the opening screen menu doing nothing (but also anywhere else in the game), I get a constant stream of this;

futex(0xbaf864, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xbaf860, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xbaf838, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc45e6c, FUTEX_WAIT_PRIVATE, 11321, NULL) = -1 EAGAIN (Resource temporarily unavailable)
<snip>
Is there some part of that that actually looks wrong or surprising to you? The futex calls seem normal to me (though I'm no expert) just because FO is running multithreaded (take a look here for example -- that article is nominally about hanging at futex, which is not what FO is doing really, but it talks about the general issue and also about how to use strace with a multithreaded app like FO).
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Mitten.O
Programmer
Posts: 255
Joined: Sun Apr 06, 2014 4:15 pm

Re: About freeorion's performance

#28 Post by Mitten.O » Wed Jun 24, 2015 6:40 pm

I think the general slowness, even when not doing anything, is caused by cpu load, not GPU load.
GG mostly uses the outdated immediate mode of OpenGL, which makes rendering very CPU bound. It recalculates every vertex every frame and sends them to the GPU one at a time. Changing it would require moving from a "Draw yourself now" model to a "give me a description of your graphical representation that I can use to render you as long as you don't change" model, which would be a big change.
Any code by me in this post is released under GPL 2.0 or later.

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

Re: About freeorion's performance

#29 Post by Dilvish » Wed Jun 24, 2015 6:50 pm

Mitten.O wrote:GG mostly uses the outdated immediate mode of OpenGL, which makes rendering very CPU bound. It recalculates every vertex every frame and sends them to the GPU one at a time. Changing it would require moving from a "Draw yourself now" model to a "give me a description of your graphical representation that I can use to render you as long as you don't change" model, which would be a big change.
On the positive side, it sounds like we have someone who know's how to do what needs to be done :wink:
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

pheldens
Pupating Mass
Posts: 96
Joined: Fri Mar 15, 2013 12:54 pm

Re: About freeorion's performance

#30 Post by pheldens » Wed Jun 24, 2015 7:08 pm

Code: Select all

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                      
13694 user      20   0 1105m 146m  39m R  103  1.8 159:44.00 freeorion
CPU0: AMD Phenom(tm) II X4 965 Processor (fam: 10, model: 04, stepping: 03)

linux 4.1 amd64

this box can play Xonotic at 1920 * 1200 60fps

Post Reply