Hi,

Until very recently, I was using OpenMP-enabled builds of trunk to work on 
Wesnoth and user-made content. My main focus all this time was performance and 
not CPU usage, since the latter doesn't usually cause a significant difference 
with my current laptop and kernel configuration (Linux 2.6.38 can 
automatically balance load to keep the system responsive); for this reason, I 
didn't even look at the CPU usage until I stumbled upon it by accident some 
nights ago.

You can see my surprise in the March 29th #wesnoth-dev IRC log [1] around 
09:04:54 when I discovered that Wesnoth was using more than 100% CPU 
(according to top's process-based output) while idling in the gamemap view of 
a scenario with no more than 4 units visible at a time, and no complex 
standing animations.

I later restricted my test case to HttT scenario 1 with the view centered on 
player 1's initial keep (thus, only two units visible), with all kinds of 
animations disabled in Preferences (unit/standing, unit/idle, animated 
terrains and halos).

In all cases, Wesnoth would idle with one of its four threads (apparently the 
main one) using around 99% of CPU time according to a thread-based output.

I am not sure how to collect further diagnostic information, but if I had to 
guess I'd say Wesnoth is wasting its time waiting for something during the 
idle loop. Naturally, this does not affect the default builds with OpenMP 
disabled.

The system in question runs Debian GNU/Linux 6.0.1 x86_64, thus the default 
compiler is GCC 4.4.5 using libgomp (GCC OpenMP support lib) 4.4.5.

[1]: http://wesnoth.org/irclogs/2011/03/%23wesnoth-dev.2011-03-29.log

-- 
Regards
  Ignacio Riquelme Morelle <shadowmaster>

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev

Reply via email to