Results 1 to 4 of 4

Thread: To CPU or not to CPU, that is the question

  1. #1
    Gold Member
    Slicker's Avatar
    Join Date
    October 25th, 2010
    Location
    South of Cheeseland
    Posts
    1,253

    To CPU or not to CPU, that is the question

    I noticed the other day how much higher the RAC was for one of my computers than another when it had a slower GPU installed. The reason? The CPU tasks were keeping the GPU from running at full speed. As an experiment, I turned off ALL CPU project crunching for a couple days. The result? Over 500K increase in RAC!!! So, now I have to decide whether to take the time to create an app_config.xml for every GPU project so each can have 100% of a CPU regardless of what the project estimates the CPU load to be for its GPU apps, or whether to just crunch GPU projects. By chance, does anyone have an all encompassing app config that has ALL the GPU projects in it? (Yeah, I know. The same file can be used on all machines so the work only need be done once, but since I'm lazy, if someone else has already done it....)
    Spring 2008 Race: (1st Place)

  2. #2
    Administrator
    Bryan's Avatar
    Join Date
    October 27th, 2010
    Location
    CO summer, TX winter
    Posts
    6,457

    Re: To CPU or not to CPU, that is the question

    Quote Originally Posted by Slicker View Post
    I noticed the other day how much higher the RAC was for one of my computers than another when it had a slower GPU installed. The reason? The CPU tasks were keeping the GPU from running at full speed. As an experiment, I turned off ALL CPU project crunching for a couple days. The result? Over 500K increase in RAC!!! So, now I have to decide whether to take the time to create an app_config.xml for every GPU project so each can have 100% of a CPU regardless of what the project estimates the CPU load to be for its GPU apps, or whether to just crunch GPU projects. By chance, does anyone have an all encompassing app config that has ALL the GPU projects in it? (Yeah, I know. The same file can be used on all machines so the work only need be done once, but since I'm lazy, if someone else has already done it....)
    If I'm understanding what you are wanting; increase the number of cores/threads reserved for the GPU and limit the CPU tasks from interfering with GPU tasks, then the answer is to use ProLasso. With that program you can assign both priority and affinity for each executable regardless of what BOINC tries to do. For example, I could be running 8 CPU tasks (BOINC scheduler) and have them run on 4 threads of the processor.

    So, figure of argument, you want to reserve 4 threads for the CPU and 4 threads for the GPU, you would "right" click on the CPU executable name and then select "affinity". Then assign the threads the CPU can use. Then right click on the GPU executable name and assign the threads for the GPU. You can also select the "priority" (this really does matter big time). Since the CPU tasks and GPU tasks won't be using the same cores you can set them both up to "above normal". The benefit to using ProLasso is that the GPU tasks and CPU tasks aren't using the same cores and having to do a memory swap every time it wants to service the executable.

    You only have to make the affinity/priority setting one time and ProLasso remembers your setting for that executable. In the future if you change your GPU tasks and don't need as many threads reserved then you can right click on the CPU executable and give it more threads.

    If you decide to use this on an 8 thread machine, then if you have reserved 4 threads for the CPU then you should set BOINC "use processors" so that it is using 50% PLUS (GPU default cpu requirement * number of instances). ie the GPU (from project) request .5 cpu and you are running 4 instances simultaneously then you would set BOINC PROCESSORS to 4 + 2 (6) so the BOINC scheduler would run 4 CPU tasks. Obviously, with affinity set the CPU tasks won't interfere with the GPU, but if running 6 instances of the CPU on 4 threads then the CPU tasks become less efficient since it is doing memory swap every time it services an executable.

    It isn't as difficult as my description sounds ... it is intuitively obvious once you install and take a look at ProLasso.

    ProLasso is free for 30 days and then some of the features go away. HOWEVER, the stuff you care about (affinity and priority) are always available!
    Last edited by Bryan; 09-19-13 at 04:35 PM.


  3. #3
    Gold Member
    shiva's Avatar
    Join Date
    November 9th, 2010
    Location
    Quinter, Kansas
    Posts
    1,389

    Re: To CPU or not to CPU, that is the question

    Bryan has had me using this for over a year now, and this makes it sound hard to me. try it you just might like it. just remember to change it when you change projects.
    https://signature.statseb.fr/sig-1240.png[/url]

  4. #4
    Diamond Member
    zombie67's Avatar
    Join Date
    October 24th, 2010
    Location
    Reno, NV
    Posts
    7,269

    Re: To CPU or not to CPU, that is the question

    Not all GPU projects under-allocate CPU threads. MW, for example, goes flat out with no additional threads reserved. So if you reserved more, you are only hurting your CPU output.

    Any time I change GPU projects on a machine, I always fiddle with reserving a thread or two, while monitoring the load on the GPU and CPU. Takes about 5 minutes to get it dialed in.
    "Don't confront me with my failures, I had not forgotten them" - Jackson Browne

    Avatar source


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •