Why is await async so slow?

It's important to separate "asynchrony" from "parallelization". await is there to help make writing asynchronous code easier. Code that runs in parallel may (or may not) involve asynchrony, and code that is asynchronous may or may not run in parallel.

Nothing about await is designed to make parallel code faster. The purpose of await is to make writing asynchronous code easier, while minimizing the negative performance implications. Using await won't ever be faster than correctly written non-await asynchronous code (although because writing correct code with await is easier, it will sometimes be faster because the programmer isn't capable of writing that asynchronous code correctly without await, or isn't willing to put the time in to do so. If the non-async code is written well it will perform about as well, if not a tad better, than the await code.

C# does have support specifically for parallelization, it's just not specifically though await. The Task Parallel Library (TPL) as well as Parallel LINQ (PLINQ) have several very effective means of parallelizing code that is generally more efficient than naive threaded implementations.

In your case, an effective implementation using PLINQ might be something like this:

public static int Sum(int[] array){    return array.AsParallel().Sum();}

Note that this will take care of efficiently partitioning the input sequence into chunks that will be run in parallel; it will take care of determining the appropriate size of chunks, and the number of concurrent workers, and it will appropriately aggregate the results of those workers in a manor that is both properly synchronized to ensure a correct result (unlike your threaded example) and efficient (meaning that it won't completely serialize all aggregation).

async isn't intended for heavy-duty parallel computation. You can do basic parallel work using Task.Run with Task.WhenAll, but any serious parallel work should be done using the task parallel library (e.g., Parallel). Asynchronous code on the client side is about responsiveness, not parallel processing.

A common approach is to use Parallel for the parallel work, and then wrap it in a Task.Run and use await on it to keep the UI responsive.

Your benchmark has a couple of flaws:

• You are timing the first run which includes initialization time (loading class Task, JIT-compilation etc.)
• You are using DateTime.Now, which is too inaccurate for timings in the millisecond range. You'll need to use StopWatch

With these two issues fixed; I get the following benchmark results:

Regular Sum:  499946 in 00:00:00.0047378Async Sum:    499946 in 00:00:00.0016994Threaded Sum: 499946 in 00:00:00.0026898

Async now comes out as the fastest solution, taking less than 2ms.

This is the next problem: timing something as fast as 2ms is extremely unreliable; your thread can get paused for longer than that if some other process is using the CPU in the background. You should average the results over several thousands of benchmark runs.

Also, what's going on with your number of core detection? My quad-core is using a chunk size of 333334 which allows only 3 threads to run.