GCD 入门（二）多核性能

#Original (English)

Source: https://www.mikeash.com/pyblog/friday-qa-2009-09-04-intro-to-grand-central-dispatch-part-ii-multi-core-performance.html

Welcome back to Friday Q&A. Last week I discussed the basics of Grand Central Dispatch, an exciting new technology in Snow Leopard. This week I’m going to dive deeper into GCD and look at how you can use GCD to take advantage of multi-core processors to speed up computation. This post assumes that you’ve read last week’s edition, so be sure to do that if you haven’t already.

Concepts In order to take advantage of multiple CPU cores within a single process, it’s necessary to use multiple threads. (I’m ignoring multi-process concurrency, because it’s unrelated to GCD.) This is just as true in the GCD world as it is in the purely threaded world. At the low level, GCD global dispatch queues are just abstractions around a pool of worker threads. Blocks on those queues get dispatched onto the worker threads as they become available. Blocks submitted to custom queues end up going through global queues and into that same pool of worker threads. (Unless your custom queue is targeted at the main thread, but you would never do that for speed purposes!)

There are essentially two ways to extract multi-core performance out of GCD: by parallelizing a single task or a group of related tasks onto one of the global queues, and by parallelizing multiple unrelated or loosely related tasks onto multiple custom queues.

Global Queues Imagine the following loop:

1
    for(id obj in array)
2
        [self doSomethingIntensiveWith:obj];

1
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
2
    for(id obj in array)
3
        dispatch_async(queue, ^{
4
            [self doSomethingIntensiveWith:obj];
5
        });

Of course code isn’t always this nice. Sometimes you have code which manipulates an array like this, but then has to perform some work with the result:

1
    for(id obj in array)
2
        [self doSomethingIntensiveWith:obj];
3
    [self doSomethingWith:array];

One way to solve this problem is by using dispatch groups. A dispatch group is a way to group together multiple blocks, and either wait for them to complete or be notified once they complete. They are created using dispatch_group_create, and the dispatch_group_async function allows submitting a block to a dispatch queue and also adding it to the group. We could then rewrite this code to use GCD like so:

1
    dispatch_queue_t queue = dispatch_get_global_qeueue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
2
    dispatch_group_t group = dispatch_group_create();
3
    for(id obj in array)
4
        dispatch_group_async(group, queue, ^{
5
            [self doSomethingIntensiveWith:obj];
6
        });
7
    dispatch_group_wait(group, DISPATCH_TIME_FOREVER);
8
    dispatch_release(group);
9

10
    [self doSomethingWith:array];

1
    dispatch_queue_t queue = dispatch_get_global_qeueue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
2
    dispatch_group_t group = dispatch_group_create();
3
    for(id obj in array)
4
        dispatch_group_async(group, queue, ^{
5
            [self doSomethingIntensiveWith:obj];
6
        });
7
    dispatch_group_notify(group, queue, ^{
8
        [self doSomethingWith:array];
9
    });
10
    dispatch_release(group);

For the synchronous case, GCD provides a nice shortcut with the dispatch_apply function. This function calls a single block multiple times in parallel and waits for it to complete, just like what we wanted:

1
    dispatch_queue_t queue = dispatch_get_global_qeueue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
2
    dispatch_apply([array count], queue, ^(size_t index){
3
        [self doSomethingIntensiveWith:[array objectAtIndex:index]];
4
    });
5
    [self doSomethingWith:array];

1
    dispatch_queue_t queue = dispatch_get_global_qeueue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
2
    dispatch_async(queue, ^{
3
        dispatch_apply([array count], queue, ^(size_t index){
4
            [self doSomethingIntensiveWith:[array objectAtIndex:index]];
5
        });
6
        [self doSomethingWith:array];
7
    });

The key to this approach is identifying code which is performing identical work on many different pieces of data at once. If you ensure that the work performed is done in a thread safe manner (beyond the scope of this post) then you can replace your loops with calls to GCD in order to achieve parallelism.

In order to see a performance gain, you need to be performing a fairly substantial amount of work. GCD is lightweight and low-overhead compared to threads, but it’s still somewhat costly to submit a block to a queue. The block has to be copied and enqueued, and the appropriate worker thread somehow notified. Submitting a block for every pixel in an image is probably not going to be a win. On the other hand, submitting a block for each image when converting a collection of images is probably going to be a win. The point where GCD ceases to be profitable falls somewhere in the middle. When in doubt, experiment. Parallelizing applications is an optimization, and as such you should always measure before and after to make sure that your changes helped. (And to make sure that you’re making the changes in the right place!)

Subsystem Parallelism The previous section talked about taking advantage of multiple cores in a single subsystem of your application. It can also be useful to do this across multiple subsystems.

For example, imagine an application which opens a document containing metadata. The document data itself must be parsed and converted into model objects for display, as must the metadata. However, the document data and the metadata don’t interact. You could create a dispatch queue for each one, then run both in parallel. The code for each piece of data parsing would be entirely serial within itself, and thread safety is not a concern (as long as you don’t have shared data between them), but they will still run in parallel.

Once the document is open, the program needs to perform tasks in response to user actions. For example, it may need to perform spell checking, syntax highlighting, word counting, autosave, and other such things. If each one of these tasks is implemented using a separate dispatch queue, they will all run in parallel with respect to each other without many of the difficulties of multithreaded programming.

By using dispatch sources, something I’ll cover next week, you can have GCD deliver events directly to a custom dispatch queue. A part of your program that monitors a network socket, for example, could be given its own dispatch queue which will then allow it to run in parallel with respect to the rest of the application. And again, by using a custom queue, this module will run serially with respect to itself, simplifying programming.

Conclusion This week we saw how to use GCD to increase the performance of your applications and take advantage of modern multi-core systems. Although care must still be taken when writing parallel applications, GCD makes it easier than ever to take advantage of all available computing power.

That wraps up this week’s Friday Q&A. Come back next week for the next part in the continuing series on GCD, when I will talk about dispatch sources, GCD’s mechanism for monitoring internal and external events. As always, if you have a suggestion for a topic to cover, please post it in the comments or e-mail it directly to me.