How to limit number of CPU cores used by a Cocoa app

  • Hi all,

    is there any possibility to limit the number of CPU cores used by the
    threads of a Cocoa application? I could not seem to find any
    documentation on this via Google yet.

    I need to allocate up to a maximum of 2 cores only, even though the app
    schedules many more threads at times (up to a dozen). Can this be
    achieved by configuring the application's properties, or will it require
    more sophisticated hacks?

    Any advice is appreciated.

    Andre
  • Well, you can use the CHUD system preference pane to disable CPU cores.
    Dunno if this addresses your need or not since you haven't explained why
    you want this. If you explained your situation better, we might be able
    to provide better advice. For instance, if your goal is to lower your
    app's priority relative to other apps, there are better ways of doing it
    than arbitrarily capping your CPU utilization.

    Andre Schnoor wrote:
    > Hi all,
    >
    > is there any possibility to limit the number of CPU cores used by the
    > threads of a Cocoa application? I could not seem to find any
    > documentation on this via Google yet.
    >
    > I need to allocate up to a maximum of 2 cores only, even though the
    > app schedules many more threads at times (up to a dozen). Can this be
    > achieved by configuring the application's properties, or will it
    > require more sophisticated hacks?
    >
    > Any advice is appreciated.
    >
    > Andre
  • On Dec 29, 2007, at 9:09 AM, Andre Schnoor wrote:

    > is there any possibility to limit the number of CPU cores used by
    > the threads of a Cocoa application? I could not seem to find any
    > documentation on this via Google yet.
    >
    > I need to allocate up to a maximum of 2 cores only, even though the
    > app schedules many more threads at times (up to a dozen). Can this
    > be achieved by configuring the application's properties, or will it
    > require more sophisticated hacks?

    This is not the way Mach is designed to work.

    Mach's unit of scheduling is the thread, and it will schedule threads
    across all available cores on all available CPUs taking code and data
    affinity into account.

    Why do you think restricting threads to run on only 2 cores will be
    useful?  My first guess is that you may be running into
    synchronization problems with data that's shared between two threads.
    That's a bug in your code and needs to be addressed by ensuring the
    synchronization is correct; just reducing the number of cores
    available for scheduling will probably still exhibit the problems at
    some time.

    In the future, when asking a question like this, it'll be useful to
    describe what your goal is rather than just one way you think you
    might be able to achieve it.  That will lead to better help from the
    list.

      -- Chris
  • Andre,
    You can use the thread affinity tags. This will allow you to group
    threads together. I had to do this since Mac OS X is expensive when
    sharing common data across cpu dies.

    Here is the link to the apple doc.

    http://developer.apple.com/releasenotes/Performance/RN-AffinityAPI/index.ht
    ml


    Hope this helps,
    Chris

    On Dec 29, 2007, at 6:51 PM, Chris Hanson wrote:

    > On Dec 29, 2007, at 9:09 AM, Andre Schnoor wrote:
    >
    >> is there any possibility to limit the number of CPU cores used by
    >> the threads of a Cocoa application? I could not seem to find any
    >> documentation on this via Google yet.
    >>
    >> I need to allocate up to a maximum of 2 cores only, even though the
    >> app schedules many more threads at times (up to a dozen). Can this
    >> be achieved by configuring the application's properties, or will it
    >> require more sophisticated hacks?
    >
    > This is not the way Mach is designed to work.
    >
    > Mach's unit of scheduling is the thread, and it will schedule
    > threads across all available cores on all available CPUs taking code
    > and data affinity into account.
    >
    > Why do you think restricting threads to run on only 2 cores will be
    > useful?  My first guess is that you may be running into
    > synchronization problems with data that's shared between two
    > threads.  That's a bug in your code and needs to be addressed by
    > ensuring the synchronization is correct; just reducing the number of
    > cores available for scheduling will probably still exhibit the
    > problems at some time.
    >
    > In the future, when asking a question like this, it'll be useful to
    > describe what your goal is rather than just one way you think you
    > might be able to achieve it.  That will lead to better help from the
    > list.
    >
    > -- Chris
  • > You can use the thread affinity tags. This will allow you to group
    > threads together. I had to do this since Mac OS X is expensive when
    > sharing common data across cpu dies.

    Note that "thread" affinity is actually cache affinity in this API,
    which doesn't sound like what the OP wanted.  I get the feeling he
    doesn't care what cores are used to run his threads, as long as no
    more than two are running simultaneously.  If that's the case, I
    don't think there's any way to do that other than control your
    threads yourself.

    Wade
  • Thanks everybody for the replies so far. I think I'll have a look at
    thread affinity tags first.

    Chris Hanson wrote:
    > Why do you think restricting threads to run on only 2 cores will be
    > useful?

    I observed problems with GUI threads when running the app on an 8-core
    Mac Pro, while it runs fine on dual core CPUs and PPC.  The fix is
    intented as a temporary workaround only until I found the real cause.

    > My first guess is that you may be running into synchronization
    > problems with data that's shared between two threads.  That's a bug in
    > your code and needs to be addressed by ensuring the synchronization is
    > correct; just reducing the number of cores available for scheduling
    > will probably still exhibit the problems at some time.

    I am aware that something goes wrong in my code, but it's most likely
    related to UI events and threads rather than data synchronization (no
    crashes occur, UI just doesn't respond to mouse events on an 8-core
    Mac). I haven't written all of the code myself and the project is huge
    and complex, so I need to narrow down the issue incrementally.

    > In the future, when asking a question like this, it'll be useful to
    > describe what your goal is rather than just one way you think you
    > might be able to achieve it.  That will lead to better help from the
    > list.
    >
    That's true. If I only knew what my goal was ;-)  I have no idea so far
    as to what my problem is, so the idea was just to "emulate" the dual
    core environment as a temporary fix. My threads are rather light weight,
    so two cores are more than enough anyway.

    Thanks again.

    Andre
  • Chris Driggett wrote:
    > Andre,
    > You can use the thread affinity tags. This will allow you to group
    > threads together. I had to do this since Mac OS X is expensive when
    > sharing common data across cpu dies.
    >
    > Here is the link to the apple doc.
    >
    > http://developer.apple.com/releasenotes/Performance/RN-AffinityAPI/index.ht
    ml

    >

    Thanks. If I got it right, I can assign the same non-null affinity tag
    to all threads and they will be run on the same CPU package, just like
    on a Core 2 Duo. This should do it.

    Obviously there's no way to set the affinity tag for a thread that is
    already running. How is one supposed to set the affinity tag of a thread
    that is about to be started with
    #detachNewThreadSelector:toTarget:withObject: or even for the main
    thread? I assume this is impossible.

    Andre
  • On Dec 30, 2007, at 3:14 AM, Andre Schnoor wrote:

    > Thanks everybody for the replies so far. I think I'll have a look at
    > thread affinity tags first.
    >
    > Chris Hanson wrote:
    >> Why do you think restricting threads to run on only 2 cores will be
    >> useful?
    >
    > I observed problems with GUI threads when running the app on an 8-
    > core Mac Pro, while it runs fine on dual core CPUs and PPC.  The fix
    > is intented as a temporary workaround only until I found the real
    > cause.

    That's your problem. All of your GUI (with a few exceptions) needs to
    be on the main thread.

    Dave
  • Exactly.  You're curing the symptom, not the disease.  This caught me for a
    huge loop in my heavily threaded program.  Then I moved anything that had to
    do with the UI to "performSelectorOnMainThread" and all is wonderful.

    > From: Dave Camp <dave...>
    >
    > That's your problem. All of your GUI (with a few exceptions) needs to
    > be on the main thread.
  • Dave Camp wrote:
    > On Dec 30, 2007, at 3:14 AM, Andre Schnoor wrote:
    >> Chris Hanson wrote:
    >>> Why do you think restricting threads to run on only 2 cores will be
    >>> useful?
    >>
    >> I observed problems with GUI threads when running the app on an
    >> 8-core Mac Pro, while it runs fine on dual core CPUs and PPC.  The
    >> fix is intented as a temporary workaround only until I found the real
    >> cause.
    >
    > That's your problem. All of your GUI (with a few exceptions) needs to
    > be on the main thread.
    >

    I understand. But why is the method that forks a drawing thread called
    #detachDrawingThread:toTarget:withObject: in the first place? IMHO, this
    is misleading.

    If the detached thread (which currently initiates all of my graphics
    output, except window and menu creation) is not allowed to do any UI
    drawing, then it should not be called a "drawing" thread. Apple should
    mention this in the documentation clearly.

    Andre
  • On 5 Jan 2008, at 12:02, Andre Schnoor wrote:

    > Dave Camp wrote:
    >> On Dec 30, 2007, at 3:14 AM, Andre Schnoor wrote:
    >>> Chris Hanson wrote:
    >>>> Why do you think restricting threads to run on only 2 cores will
    >>>> be useful?
    >>>
    >>> I observed problems with GUI threads when running the app on an 8-
    >>> core Mac Pro, while it runs fine on dual core CPUs and PPC.  The
    >>> fix is intented as a temporary workaround only until I found the
    >>> real cause.
    >>
    >> That's your problem. All of your GUI (with a few exceptions) needs
    >> to be on the main thread.
    >>
    >
    > I understand. But why is the method that forks a drawing thread
    > called #detachDrawingThread:toTarget:withObject: in the first place?
    > IMHO, this is misleading.
    >
    > If the detached thread (which currently initiates all of my graphics
    > output, except window and menu creation) is not allowed to do any UI
    > drawing, then it should not be called a "drawing" thread. Apple
    > should mention this in the documentation clearly.

    This is true, but the docs clearly state that that method is just a
    convenience for +detachNewThreadSelector:toTarget:withObject:

    You can do some drawing on a background thread if you wish.
    NSProgressIndicator does it for a start. BUT you have to be VERY
    careful to properly lock the view you are drawing into so that nothing
    goes wrong.

    Mike.
previous month december 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Go to today