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?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS What is proper thread cost/benefit analysis
- Thread starter Sydde
- Start date
- Sort by reaction score
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.
This is a good article introducing GCD.
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.
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.