Bug 766684

Sorry for bumping this one, i understand that this issue is not of highest priority with release of F17 being finalized, but will it get any attention any time soon? It is impossible to play chess, CPU fan is about to blow fire :).

Although top showed me that gnuchess was taking 100% of CPU i think it is a Knights issue. When i stated glchess (gnome chess programm, comes with gnome-games package) on my friends computer, which uses gnuchess as backend, cpu didn't jump to 100%.
So i guess gnuchess is not a problem here, but Knights.

There's a new update in updates-testing, please test this against that and if this helps, give positive karma.

https://admin.fedoraproject.org/updates/FEDORA-2012-15311/knights-2.5.0-1.fc17

Hi Jon,
Just installed and it still takes 100% cpu load. Well, it takes over one thread out of 4, but still. I realise that way down in the game chess engine would require lots of cpu, but i just start the program, and even then i'm not that good of a contender to make my cpu work that hard :). 
Again top shows me gnuchess taking 100% of cpu....
And i just installed gnome-games-extra (provider of glchess) and cpu load jumped to 100% again...so, maybe Knights is not at fault here after all. Maybe it is a gnuchess - hungry for clock ticks.
But then, should it require whole cpu thread so yearly in the game? even at start up before i make my first move.
Thnx for your swift response anyway Jon.

Chess moves require a lot of math, it might not be a bug. . .

Since Christopher is on leave, I'll still look at this. . .

I've put builds of 6.0.2 in my fedorapeople repo, see if it helps.  Please also test and see if you think it's using the book file, I think it might not be needed anymore.

http://fedorapeople.org/~limb/repo/17/

hm...i could swear i did commented on your last request Jon...strange really. But anyway, with new build gnuchess have occupied 100% of two out of four threads (instead of one thread in older version). I can only assume that new version is became even more powerful engine and to repeat myself i realize that chess engine requires lots of cpu ticks.
My question is if it have to be this "cpu clock hangry" from very first moment when application (knights in this case) only starts up without even  making first move.

Not a question I can easily answer.  I could understand it being memory hungry due to loading the book, or CPU hungry from the time of the AIs first move, but that early I'm not sure.

6.0.2 is in rawhide.

Not a problem with knights, according to the upstream maintainer the heavy cpu usage is normal behavior for gnuchess.  Here is a thread on the bug-gnu-chess mailing list that refers to this problem - http://lists.gnu.org/archive/html/bug-gnu-chess/2012-10/msg00000.html.  It does mention that he was going to look into it in the future.

I didn't remember this being a problem in older fedora releases. I decided to try out gnuchess-5.07 and found that is not cpu intensive when in easy mode.  I think it takes a break in between turns or something along those lines.  When put in hard mode the cpu usage does goes up.

gnuchess versions 5.08 and 6.02 are both cpu hungry.

gnuchess is designed to play as effectively as possible, so when it is searching, it's reasonable to use all available processing power to search as deep as it can.

By default gnuchess is set to "ponder," which means search even on the opponent's turn.  (This is important in competitions between chess engines; I suspect it's overkill against normal humans.) Setting gnuchess to "easy" mode disables pondering. According to the documentation, that seems to be all "easy" mode does, so if CPU usage is an issue for you then you should turn on "easy" (even if you want a tough game -- use the "depth" option to control difficulty).

Knights should consider starting gnuchess with "easy" if it doesn't already.

Related GNOME bug: https://bugzilla.gnome.org/show_bug.cgi?id=578130#c7

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.