Some of the points he makes are not really accurate.
For example, he states:
"as machines get 4 cores (processors) and then 8 and then 16, apps written for Snow Leopard and beyond will continue to be faster and faster, with no changes, while Windows programmers are going to be struggling to make their apps work at all"
This statement isn't true.
Windows, more specifically the .NET framework (and the associated compilers), has had support for thread pools, and cross-thread dispatch since 2003, and support for closures since 2008. Those features are, effectively, equivalent to grand central dispatch on the mac.
The Apple non-developer docs do indicate that there may be some scheduling improvements that might make GCD more efficient, but without any actual benchmarks between the two technologies, that claim doesn't have any basis in fact.
I'm not trying to be a shill here, but its important to point out that not everything he claims is true.
I think this less akin to thread pools, but closer to .net parallel extensions. A simple thread pool is still rather difficult to deal with, this also more fine grain work.
(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.
Sun Microsystems, Intel, AMD and Microsoft have all been pushing multi-core/multi-CPU for years. His statement might be correct from a UI perspective, but it sounds a bit naive from a system perspective. Windows is much more fragmented than OS X in the UI layer. WPF, WinForms, Win32, Qt, Swing, Adobe, Softimage, Maya, Autodesk, etc etc.
For example, he states:
"as machines get 4 cores (processors) and then 8 and then 16, apps written for Snow Leopard and beyond will continue to be faster and faster, with no changes, while Windows programmers are going to be struggling to make their apps work at all"
This statement isn't true.
Windows, more specifically the .NET framework (and the associated compilers), has had support for thread pools, and cross-thread dispatch since 2003, and support for closures since 2008. Those features are, effectively, equivalent to grand central dispatch on the mac.
The Apple non-developer docs do indicate that there may be some scheduling improvements that might make GCD more efficient, but without any actual benchmarks between the two technologies, that claim doesn't have any basis in fact.
I'm not trying to be a shill here, but its important to point out that not everything he claims is true.