When foldit should be idle, consuming vast amounts of cpu time on Windows

Case number:845833-991947
Topic:Game: Display
Opened by:Tlaloc
Status:Closed
Type:Suggestion
Opened on:Wednesday, February 22, 2012 - 21:01
Last modified:Tuesday, June 5, 2012 - 22:27

I have several machines that I run foldit on, but I am particularly conscious of this on my 4-core laptop because the cpu fans sound like jet engines when running at high speed. The desktop machines have much quieter fans, but on my 2-core desktop I get the same effect.

I have monitored this with the Windows Performance Monitor (a tool you can find in the administrator's tools in the Windows control panel).

Environment: Windows 7, 64 bit operating system

I run foldit, and open a science puzzle. I am not running any of the tools, just viewing the protein in the Window. If foldit is minimized, the four processors are all running at 0 to 15% capacity. But if I maximize foldit, one of the processors is constantly running at about 80% to 90% capacity. Because it is using so much cpu time, it heats up and the cpu fan spins faster to cool it off. There must be some thread that runs when stuff is being displayed that is in a tight loop consuming cpu time.

One the two core desktop, one of the cores runs hot when foldit is maximized, but goes to almost 0 when minimized.

This is not a new bug. I have noticed this since I got this laptop last April, but it has risen to one of the top things I'd like you guys to fix after you get the stability problems done. Let me know if you need any more details on reproducing the bug.

(Wed, 02/22/2012 - 21:01  |  16 comments)


Joined: 06/17/2010
Topic: Game: Tools » Game: Display

This is there from like always. GUI is eating one full core on idle. Reported many times...

spmm's picture
User offline. Last seen 40 weeks 2 days ago. Offline
Joined: 08/05/2010
Groups: Void Crushers

Yes please fix - Win7, 64bit, 4 core, 8MB RAM, i7x 7200 and it screams if I open a puzzle; the screaming doesn't get any worse if I actually do anything to the protein, like run a script, but it can't be doing my laptop much good as I run foldit nearly 24x7. I also have 1GB graphics RAM but that doesn't seem to help except to provide a nice picture.
Appreciate you need to sort out the penguins first but if we could be next or in parallel that would be great :)

brow42's picture
User offline. Last seen 1 day 5 hours ago. Offline
Joined: 09/19/2011
Groups: None

I'd just like to say that the fewer cores I have dedicated to drawing, the more multistarts I can be folding! Diversity!

Also, some possibly related things to maybe look at at the same time:

GUI thread blocked by puzzle (track) load,
GUI thread blocked by long Lua calls (wiggle/shake iteration running long?),
GUI thread blocked by network,
GUI thread blocked....

jflat06's picture
User offline. Last seen 2 days 5 hours ago. Offline
Joined: 09/29/2010
Groups: Window Group
Status: Open » Open
Type: Bug » Suggestion

This isn't really a bug. Those resources that you see the game taking up are a result of the render and update loops running. These loops have to be running in order for the screen to properly update while it isn't minimized. Things like the clash/exposed/hydrogen bond animations require this update loop to be running, along with many other things. In the end, Foldit really is a graphics application, like any other game. Pretty much any mainstream game will take a large amount of resources while it is running.

One could imagine an option which would remove any animations or features that make running the update/render loops necessary. Or possibly a framerate limiter so that the render loop will take up a smaller amount of resources. However, if the program is indeed idle, why not just close it?

bertro's picture
User offline. Last seen 6 weeks 3 days ago. Offline
Joined: 05/02/2011
Groups: Beta Folders

When minimized, the client takes far less resources yet still execute the recipes or actions currently requested. It would be usefull sometimes to mimic this behavior while the client is still visible/maxmimized.

jflat06's picture
User offline. Last seen 2 days 5 hours ago. Offline
Joined: 09/29/2010
Groups: Window Group

The reason why this works when minimized is because it isn't having to run the render loop.

When things are being displayed on screen, it has to update these things to make sure all animations and screen information is up to date. So you cant just turn off the render loop while the game is visible/maximized.

Just mimicking the behavior while the client is visible/maximized would result in either a blank screen, or a screen which is just a still image.

What I suggested is that there be a mode which disables things like animations, which make just using a still image not work. Again, I'm not totally sure why this is an issue if the client is idling, as you can just close it if you're not working on anything.

bertro's picture
User offline. Last seen 6 weeks 3 days ago. Offline
Joined: 05/02/2011
Groups: Beta Folders

To summarize, (please correct me if I am wrong)

1) The two loops (update and render) are required when visible/maximized in order for the client to fully represent the current state of the solution and animations.

2) The render loop is stopped when minimized. The update loop is still running to process the action/script currently being performed.

I would like to have a state where the render loop is stopped when visible/maximized but the update loop is still working. That would reduce the CPU load for that client while still running that action/script and leave room for another client running minimized. Some of the time I don't care for the visual aspect of the solution during all actions or scripts, I just want to see the score changes. If no action/script is being processed than stopping the update loop will further reduce the CPU load (it is/could be the case already!).

Definitely, stopping one or both will reduce CPU load as per tlaloc's request.

A client being maximized with the render loop off (as per the user request) could do one render iteration to update the screen and wait for the user to change its mind. That way you can have mutiple clients running and still keep some CPU room for interaction by the user.

Just keep the interaction with the Cookbook, Chat, other windows running where possible.

Hope that makes more sense.

Tlaloc's picture
User offline. Last seen 9 weeks 5 days ago. Offline
Joined: 08/04/2008
Groups: Mojo Risin'

It is frequent that I will run a script which completes. After it completes, the CPU fan on the laptop is still spinning like a tornado. Now I could try to remember to always minimize foldit when I walk away from it, but I know that I'm just not going to remember. I would argue that when no tool is running that the animations just don't need to update as frequently. I'd be happy if it didn't update at all, since I turn off all the things that normally animate in the options.

I would bet that if no tool is running and you put in a small sleep statement in the update thread, say 10 milliseconds, that it would cut the CPU usage by more than half. Furthermore, if all the things that require animation are unchecked in the options, that the sleep could be 100 milliseconds without any major effect on the game. I'm guessing, since I don't know the architecture of that part of the game, but I'm pretty sure *some* optimizations can be done that would cut the CPU usage of that thread.

Over the time I used it, I had to replace 3 CPU fans on my previous laptop at about $100 each, so trying to preserve my laptop fan is a goal of mine. Also if people are also running Rosetta, that CPU time could be doing some work there rather than updating a screen that nobody is looking at.

brow42's picture
User offline. Last seen 1 day 5 hours ago. Offline
Joined: 09/19/2011
Groups: None

This sort of thing is indicative of using a software timer, instead of a hardware timer that lets you pause the thread until it alarms. I've assumed they're using a hardware timer and it just takes a lot of work to draw the spiky balls. A double-check/confirmation can't hurt. I wrote some timing code about 10 years ago for linux/windows, so portability shouldn't be a huge issue.

Joined: 12/06/2011
Groups: None

By the way, the same behavior (high CPU usage when no tool in use) occurs on the MacOS client. Also note that "minimizing" the window does reduce CPU usage of the idle application, but "hiding" the application does not.

Joined: 06/17/2010

It is same in Win7.
If you minimize button and drop to menu bar it is ok, if you use tool like PowerMenu to hide in tray it is still eating CPU.

brow42's picture
User offline. Last seen 1 day 5 hours ago. Offline
Joined: 09/19/2011
Groups: None

I never minimize foldit any more, because it might not come back!!!

Joined: 06/17/2010

Try update your windoze. It not happen to me for about year now. I have 2 clients open almost 24/7 which 23/7 they are minimized :P

Joined: 05/19/2009
Groups: Contenders

Couldn't it be the chat thread ? If multiple clients are running, they will all want to update the screen, but only one of them will have an active chat thread.

This could be tested by starting two clients on two different machines. The first client will have the chat, the other machine will not have chat. Running two clients will have to show a utilization difference between the machines if this theory is correct.

Joined: 06/17/2010

No, it is no matter about IRC connection.
Client that have chat open and client that want to have chat open doing same thing - eating CPU on idle.

tamirh's picture
User offline. Last seen 6 years 17 weeks ago. Offline
Joined: 05/11/2012
Status: Open » Closed

Marking as dupe of http://fold.it/portal/node/990207

Sitemap

Developed by: UW Center for Game Science, UW Institute for Protein Design, Northeastern University, Vanderbilt University Meiler Lab, UC Davis
Supported by: DARPA, NSF, NIH, HHMI, Amazon, Microsoft, Adobe, RosettaCommons