What is proper thread cost/benefit analysis

Discussion in 'Mac Programming' started by Sydde, Dec 25, 2009.

  1. Sydde macrumors 68020

    Sydde

    Joined:
    Aug 17, 2009
    #1
    I am running this heavy-lifting app (pegging the CPU for the last several hours) and I see it has 21 threads. I realize that it takes a few threads to make proper use of multiple cores, but I wonder what the real advantage is to handling a large amount of data this way. I have worked with minor threading, even where two threads are sometimes clashing over the same data, and it is a real PITA. By what criteria does one decide to fork out parts of the workload, and at what point does one decide these threads are exacting more overhead than the split is worth?
     
  2. GorillaPaws macrumors 6502a

    GorillaPaws

    Joined:
    Oct 26, 2003
    Location:
    Richmond, VA
    #2
    I don't know much about multithreading, but I believe that a big part of the magic of Grand Central Dispatch is that it optimizes these kinds of decisions for you. You break up the job into units of work and it dynamically figures out just how many threads to spawn to get the job done in a manner that's based on what's optimal for the users machine at that point in time.

    This is a good article introducing GCD.
     
  3. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #3
    Basically, you analyze it then measure it.

    If threads contend for any shared or limited resource, then the overhead of resolving that contention may be high. This includes coordination, such as exclusive access, as well as cooperation, such as sharing a network interface.

    If threads operate with independent resources, and only coordinate briefly at start and end of the task, then contention may be low. This is the ideal and most scalable.

    If the task is a sequence of contended and independent work, then analysis and prediction is even harder.

    In general, you make some predictions based on the type of task, the time it takes for the task itself, and the time-varying nature of contention resolution. There's a whole area of Computer Science that deals with contention resolution, timing optimization, and doing work within limits or restrictions. With predictions made, and code written and tested, then you measure the actual code running the actual task and see how close your predictions were.

    Detailed analysis and measurement may be too costly. Then you just code things to not do anything too stupid, then test it under a range of loads, and hope for the best. Optimal isn't needed if Good Enough is present.

    Without knowing exactly what the task is and what it's actually doing, there's no way to tell if 21 threads is a good number.
     
  4. Detrius macrumors 68000

    Joined:
    Sep 10, 2008
    Location:
    Asheville, NC
    #4
    I would say 600 thread count for less than $50 is pretty good.
     

Share This Page