(disclaimer: I'm not a .NET programmer so maybe I'm talking out of my ass. Feel free to correct.) One major difference between .NET thread pools and GCD is tha

(disclaimer: I'm not a .NET programmer so maybe I'm talking out of my ass. Feel free to correct.) One major difference between .NET thread pools and GCD is that the former are used in a high-level, garbage collected language, while the latter are built on top of C. Call me old fashioned, but if I'm CPU bound then I'm going to explore moving the bottlenecks to C first, and THEN look into parallelism if they still aren't fast enough. GCD follows that order, .NET has it backwards. (Although I hear the JIT is pretty good, and VS supports OpenMP which is nearly as good as GCD.) There's an argument to do things the other way: stay in the high-level regime, make things parallel and buy more hardware, but this strategy is more prevalent (and useful) on the server, rather than the desktop, and in that case going to threads is just postponing the inevitable, you need to go fully distributed. There will always be value in good, fast serial code, and nothing is going to beat C at that in the foreseeable future.