MacWorld.com Lampoons Grand Central
Author: Drew McCormack
MacWorld.com has reprinted a piece from InfoWorld by Neil McAllister. The basic premise of McAllister’s article is that while technologies that promise greater parallel performance, like Snow Leopard’s Grand Central, are useful on web servers, they will do nothing to change our experience on the Desktop, and will be considered by most developers too difficult to bother adopting.
McAllister writes:
Adding cores and trumpeting greater CPU power through concurrency is great marketing for hardware vendors like Intel—and Apple—but the truth is that today’s high-end PCs have long since exceeded the performance needs of casual users. It’s little wonder that netbooks are the hot hardware trend. Forget multiple cores; customer demand is even driving clock speeds downward. Complex processing is moving outward, into the cloud.
While it is true that mail clients and word processing apps will probably experience the least benefit from the new approach to concurrency, there are plenty of commonly used apps that will. Probably the most important app in our arsenal, the web browser, is an obvious candidate. The opportunities for improvements through concurrency are many and varied.
Netbooks may be ‘hot’ at the moment, but they are still a relatively small part of the total PC/Mac market. Most people use their computers for media apps like iTunes, iMovie, iPhoto, and GarageBand. If all you do on your computer is open email and tweet in your Twitter client, you don’t need multi-core or Grand Central, but if — like me — you are transcoding H.264 video, these technologies can’t come soon enough. The potential for concurrency in any data intensive app is enormous.
Rather than demonstrating that multi-core is marketing hype, McAllister has just shown the fundamental difference between Mac and Windows users. Mac users create more than spreadsheets and textual documents on their computers. They want to edit video, transcode it, and post it to YouTube. They want to index the facial features of thousands of photos, and have their computer automatically pick out individuals it recognizes. They want to create a screencast in full HD. You name it, there are countless examples of applications where more grunt would improve our experience as users.
McAllister also unwittingly points to another major difference between the Mac and Windows communities: the developers.
That’s all well and good, but it still implies a sea change away from programming practices that have served the developer community well for the last 20 years or more. Grand Central will make it easier to write parallelizable software, but it’s not any kind of fairy dust that will allow existing software to take advantage of multiple cores when it couldn’t before. Developers will still need to change the way they think to write good concurrent software, including picking up practices from the world of functional programming (such as closures). As the saying goes, you can lead an old dog to water, but you can’t make it ride a horse.
In my experience, the developers he is talking about are not Mac developers. I have absolutely no doubt that Mac developers can and will adopt Apple’s new approach to concurrency. In Leopard, Apple introduced a few new classes into its Cocoa frameworks that work much the same way as Grand Central, but at a higher level of abstraction. Those classes have been adopted to simplify the concurrency in many apps.
McAllister is just spouting the same nonsense that has always been leveled at performance improvements. I could edit and print a great looking document on the original Mac 25 years ago; have all of the performance gains that followed been for naught? Of course not. Tasks like text editing require next to no computational resources, but there are plenty of tasks that do.
If anything, the number of applications for which a user would need high performance is increasing, rather than decreasing. Ten years ago, very few people edited video, or even had a digital photo collection. Consumer media is an area that is still far from the point of performance saturation, when improvements to hardware no longer benefit the user. Think about that the next time you are waiting for your computer to import your latest video footage.
Comments
Spot on Drew
Neil McAllister is displaying a remarkable lack of imagination here. There are things which we do on our computers today which we could only dream of five years ago. Yet these things are indispensable now (think of Spotlight). Perhaps in another 5 years we'll routinely be converting our home videos to 3D in real time. Sure it'll take some smart developers, but you can guarantee that it won't be done on a single core.
Gavin MacLean
http://www.openplanetsoftware.com
:)
Good for a laugh
Dejavu
Yes. And while servers may benefit from large amounts of memory, we all know that 640 kilobytes are enough for the desktop user ;)
Compute where your data are
Great point, Gavin. How long do you want to wait for that home movie to upload to the cloud before you start editing video? :-)
Scientific data sets are also getting so large that it's becoming more efficient to just perform the computation where the data are. Cloud computing is a great idea, but if I've got my own 500k SNP chip results, I have to upload them to the server, compute and then download the results. Is your network fast enough to bridge the gap in efficiency between your local Mac and the cloud computing engine?
It's sad when a self
It's sad when a self proclaimed "expert" writes a really dumb article but it's even sadder when a respected site goes and reprints it. Intel and the industry as a whole has been saying for years now that you need to move towards parallel processes because you are not going to get much more speed improvements like you used to 10 years ago. Engineers are working on improving efficiency and adding more cores because they have pretty much ran into the physical limitations of the current technology. You need a breakthrough the likes of which is not really on the horizon.
I have no idea why McAllister doesn't know this but every major development company has been working on way of making multithreaded programming easier. Apple is actually the late comer this time and attacking them when they are simply following the industry is really stupid and uninformed. Just to point out a few examples MS has been working on multi threaded programming for well over 5 years now. Intel for even longer. Java 7 is going to have a whole bunch of new classes and a framework for the same purpose and the list keeps growing.
I am not even going to start with the uneducated statement about grid computing.
Oh and cloud computing IS actually grid computing for the most part. And it is hardly the future of computing. It is a solution for some problems but the personal computer is not going anywhere anytime soon. It took us 20 years for to leave the mainframe and we are not going back anytime soon ( i can guarantee you that much ).
There is one thing that McAllister points out that is true and still manages to amaze me. There is a difference between Windows and Mac users. Windows users seem to have accepted that computers are hard to use and they shouldn't expect too much of them. Mac users on the other hand seem more creative and developers seem to create programs that overall achieve the same goals as their windows counterparts but often get there in a lot more graceful way. It all ads up to a better user experience and you are a happier person overall. I personally tend to say that Windows kills my inner child ... but that's just me.
Are we talking about Grand Central?
It seems like Neil and Drew are talking about the usefulness of desktop parallelism to developers and their customers, rather than Grand Central itself. Given that, I agree with Drew that desktop needs for parallel computing, whatever the form, is growing. I'd say Drew's last example about video import demonstrates bandwidth saturation, something that hardware makers haven't fully addressed, but often good software can workaround that.
However, I must agree with Neil's conclusion that Grand Central itself is unlikely to be widely adopted, but for none of the reasons he says. The benefits of Grand Central don't outweigh the benefits of using existing cross-platform APIs. If a developer goes to the work of dividing their code into atomic processing tasks appropriate for Grand Central, why not just use, say, POSIX threads? I doubt a developer who already uses POSIX threads for parallelism would migrate to Grand Central, because their code already works. Sure Grand Central does it more elegantly as we'd expect from Apple, but I'm not convinced that's enough here. Apple seems to be repeating the story of QuickDraw GX, whose role today is filled by OpenGL.
I'd like to see Apple make Grand Central open source or an open standard, like they did with OpenCL (which I applaud). Only then I could see Grand Central having a real chance of adoption, maybe helping to quash a Tower of Babel effect from Microsoft Axum and Sun Fortress. But I think Apple has already made their decision, while many of us parallel compute another way.
Re: Are we talking about Grand Central?
I think Apple's target with Grand Central are not the people already programming parallel systems like clusters and supercomputers. Apple is targeting the vast majority of developers that have never programmed in parallel.
POSIX threads and other technologies (eg OpenMP) have a bunch of problems, which explains why most developers steer clear. Probably the biggest problem with multithreading in general is that it is actually hard to get right, and very easy to get wrong. What's worse is that, when you get it wrong, you often don't even realize it. Grand Central simplifies things by moving to a 'packet' based approach.
Another problem with traditional threading models is simply that they are computationally expensive. Sure, you can do it right, but most people do not take the time, and spawning and tearing down threads is an expensive operation. An advantage that Grand Central has is that it maintains a pool of threads for you, and doesn't incur the overhead of constantly spawning and killing them.
Grand Central will succeed, whether developers outside of Apple use it or not, because it is to be integrated into the Cocoa frameworks. Next time you sort a large array in a Cocoa app, you will likely do it in parallel, because it is so easy to do so. I do not think Grand Central is akin to QuickDraw GX or any other doomed technology.
Fact is, there is no existing technology that Apple should be using for this problem that it is not already using. You've already got posix threads and openmp, neither of which do a good job of solving the problem at hand.
I am pretty sure Grand Central will get widely adopted in the Apple developer community, by people that have never used parallelism in their apps before. Probably more than you can say for technologies from MS and Sun, which are almost guaranteed to remain academic exercises. Apple is the only one that is actually delivering solutions at this time.
Drew
---------------------------
Drew McCormack
http://www.maccoremac.com
http://www.macanics.net
http://www.macresearch.org
Not really!
"Apple is actually the late comer this time and attacking them when they are simply following the industry is really stupid and uninformed. Just to point out a few examples MS has been working on multi threaded programming for well over 5 years now. Intel for even longer."
I have to disagree with that. Apple was certainly the first one to see the importance of multithreading and multiprocessing when at the same time Intel and Microsoft were focused on the processor frequency as the main solution for improving performance.
I can't forget the time when Apple was basically the only one that was talking about efficiency rather than frequency in a world where the Pentium 4 was racing after the frequency numbers. Back to 2001, Apple was the first to introduce general purpose multi-processing machines based on the G4, and at the same time Apple started to speak to its developers community on the importance of taking advantage of multithreading and multiprocessing (i know it because i was to the WWDC following the introduction of the multiprocessing machines). Back then, Microsoft did not have any whatsoever concern about taking advantage of multiple processing cores. Intel back then already had some solutions for developing for multiprocessing machines, but it was not easier to use than to use posix and it was limited
Apple already at that time then has started to introduce multithreading support in its Accelerate framework, a while later, Core Image and Core video were already able to take advantage of multi-cores if the GPU was not enough. So Apple is certainly not late on taking advantage of multiprocessing and it has gradually introduced technologies that take advantage of it. Of course the problem gets harder as it became evident that the multiplication of cores is the only future, something that was not evident even for Apple back to the beginning of this century.
Now, the new trend is to be able to create technologies that can scale for thousand cores and to give developers a way to program them easily. And i can't see why Apple is late on this one, because Apple has much more experience on the problem as it has faced the problem well before Microsoft which was late to jump on the idea that multicores are the future. And as Apple started to talk about optimizing for multithreading to its developers much earlier than windows developers, it is evident that developers on Mac are much more receptive on being asked to use technologies for taking advantage of multicores.
Basically, you can say that Apple has been concerned on the problem for about 9-10 years, and again we already saw results of Apple's development.