Microsoft's asynchronous approach is a good substitue for the most common of the purposes for multithreaded programming: improving responsiveness with respect to IO tasks.
However, it's important to realize that the asynchronous approach is not capable of improving performance at all, or improving responsiveness with respect to CPU intensive tasks.
Multithreading for Responsiveness
Multithreading for responsiveness is the traditional way to keep a program responsive during heavy IO tasks or heavy computation tasks. You save files on a background thread, so that the user can continue their work, without having to wait for the hard drive to finish its task. The IO thread often blocks waiting for some portion of a write to finish, so context switches are frequent.
Similarly, when performing a complex calculation, you want to allow regular context switching so the UI can remain responsive, and the user doesn't think the program has crashed.
The goal here is not, in general, to get the multiple threads to run on different CPUs. Instead, we're just interested in getting context switches to happen between the long-running background task and the UI, so that the UI is able to update and respond to the user while the background task is running. In general, the UI won't take up much CPU power, and the threading framework or OS will usually decide to run them on the same CPU.
We actually lose overall performance due to the extra cost of context switching, but we don't care because performance of the CPU wasn't our goal. We know that we usually have more CPU power than we need, and so our goal with regard to multithreading is to get a task done for the user without wasting the user's time.
The "Asynchronous" Alternative
The "asynchronous approach" changes this picture by enabling context switches within a single thread. This guarantees that all of our tasks will run on a single CPU, and may provide some modest performance improvements in terms of less thread creation/cleanup and fewer real context switches between threads.
Instead of creating a new thread to await the receipt of a network resource (e.g. downloading an image), an async
method is used, which await
s the image becoming available, and, in the meantime, yields to the calling method.
The main advantage here is that you don't have to worry about threading issues like avoiding deadlock, as you aren't using locks and synchronization at all, and there's a bit less work for the programmer setting up the background thread, and getting back on the UI thread when the result comes back in order to update the UI safely.
I haven't looked too deeply into the technical details, but my impression is that managing the download with occasional light CPU activity becomes a task not for a separate thread, but rather something more like a task on the UI event queue, and when the download completes, the asynchronous method is resumed from that event queue. In other words, await
means something akin to "check whether the result I need is available, if not, put me back in this thread's task queue".
Note that this approach would not solve the problem of a CPU-intensive task: there's no data to await, so we can't get the context switches we need to happen without creating an actual background worker thread. Of course, it might still be convenient to use an asynchronous method to start the background thread and return the result, in a program that pervasively uses the asynchronous approach.
Multithreading for Performance
Since you talk about "performance", I'd also like to discuss how multithreading can be used for performance gains, something that's entirely impossible with the single-threaded asynchronous approach.
When you're actually in a situation where you don't have enough CPU power on a single CPU, and want to use multithreading for performance, it's actually often difficult to do. On the other hand, if one CPU isn't enough processing power, it's also often the only solution that could enable your program to do what you'd like to accomplish in a reasonable timeframe, which is what makes the work worthwhile.
Trivial Parallelism
Of course, sometimes it can be easy to get real speedup from multithreading.
If you happen to have a large number of independent computation-intensive tasks (that is, tasks whose input and output data are very small with respect to the calculations that must be performed to determine the result), then you can often get significant speedup by creating a pool of threads (sized appropriately based on the number of available CPUs), and having a master thread distribute the work and collect the results.
Practical Multithreading for Performance
I don't want to put myself forward as too much of an expert, but my impression is that, in general, most practical multithreading for performance that happens these days is looking for places in an application that have trivial parallelism, and using multiple threads to reap the benefits.
As with any optimization, it's usually better to optimize after you've profiled your program's performance, and identified the hot spots: it's easy to slow down a program by deciding arbitrarily that this part should run in one thread and that part in another, without first determining whether both parts are taking up a significant portion of CPU time.
An extra thread means more setup/teardown costs, and either more context switches or more inter-CPU communication costs. If it's not doing enough work to make up for those costs if on a separate CPU, and doesn't need to be a separate thread for responsiveness reasons, it will slow things down for no benefit.
Look for tasks that have few interdependencies, and that are taking up a significant portion of the runtime of your program.
If they have no interdependencies, then it's a case of trivial parallelism, you can easily set up each with a thread and enjoy the benefits.
If you can find tasks with limited interdependence, so that locking and synchronization to exchange information doesn't slow them down significantly, then multithreading can give some speedup, provided you're careful to avoid the dangers of deadlock due to faulty logic when synchronizing or incorrect results due to not synchronizing when it's necessary.
Alternatively, some of the more common applications for multithreading aren't (in a sense) looking for speedup of a predetermined algorithm, but instead for a larger budget for the algorithm they're planning to write: if you're writing a game engine, and your AI has to make a decision within your frame rate, you can often give your AI a bigger CPU cycle budget if you can give it its own CPU.
However, be sure to profile the threads and ensure that they're doing enough work to make up for the cost at some point.
Parallel Algorithms
There are also a lot of problems that can be sped up using multiple processors, but that are too monolithic to simply split between CPUs.
Parallel algorithms have to be carefully analyzed for their big-O runtimes with respect to the best available non-parallel algorithm, as it's very easy for the inter-CPU communication cost to eliminate any benefits from using multiple CPUs. In general, they must use less inter-CPU communication (in big-O terms) than they use calculations on each CPU.
At the moment, it's still largely a space for academic research, in part because of the complex analysis required, in part because trivial parallelism is quite common, in part because we don't yet have so many CPU cores on our computers that problems which can't be solved in a reasonable time frame on one CPU could be solved in a reasonable time frame using all of our CPUs.