Apple Open Sources Grand Central Dispatch 342
bonch writes "Apple has open sourced libdispatch, also known as Grand Central Dispatch, which is technology in Snow Leopard that makes it easier for developers to take advantage of multi-core parallelism. Kernel support is not required, but performance optimizations Apple made for supporting GCD are visible in xnu. Block support in C is required and is currently available in LLVM (note that Apple has submitted their implementation of C blocks for standardization)." Update: 09/11 15:32 GMT by KD : Drew McCormack has a post up speculating on what Apple's move means to Linux and other communities (but probably not Microsoft): "...this is also very interesting for scientific developers. It may be possible to parallelize code in the not too distant future using Grand Central Dispatch, and run that code not only on Macs, but also on clusters and supercomputers."
What? (Score:3, Interesting)
Can somebody explain what this "blocks" is? I mean, C being a block-structured language, I thought it already supported them...
Re:What? (Score:5, Informative)
Blocks are sections of program that can be passed around between functions as arguments. They basically allow 'functional' programming in C.
Re: (Score:2, Informative)
Blocks are the closest C will probably ever get to first-class functions. They're close enough that you can reap most of the benefits of first class functions.
Re:What? (Score:5, Informative)
Re: (Score:2)
To me it looked something like a nameless function, which shares same stack with the functions where it is defined.
Even if it's a dumb nameless function, it could be already very useful. E.g. perl's 'sort {$a op $b} @list' can be more or less directly translated to C's 'qsort( .... ^(const void *a, const void *b){ return a op b; } )'. At least I hope so.
Re:What? (Score:4, Interesting)
They're basically lambda functions [wikipedia.org] which are a part of C++0x.
Re:What? (Score:4, Informative)
They're an alternate implementation of lambda-like technology. Apple's Chris Lattner wrote the first public announcement on blocks and noted: "To head off the obvious question: this syntax and implementation has nothing to do with C++ lambdas. Blocks are designed to work well with C and Objective-C, and unfortunately C++ lambdas really require a language with templates to be very useful. The syntax of blocks and C++ lambdas are completely different, so we expect to eventually support both in the same compiler."
If only due to type inference, I'd prefer the syntax of C++ lambdas, but Blocks aren't half bad at what they do within the frame of the C model.
Re: (Score:2)
Actually, C is not a block-structured language. You can't declare functions inside other functions.
How ignorant and lazy you are (Score:5, Insightful)
I'm honestly surprised how ignorant and lazy the regular slashdotter has become with the years.
Any self-respected geek should be already keeping up to date with Apple advancements which are and will be impacting techology in the years to come.
If you people haven't noticed already, Apple has been consistently releasing libraries and server software as open source projects for the rest to pick up , use and modify, with liberal licenses.
A friend of mine used to say (can't remember exactly... paraphrasing:)
* Microsoft wants all software to be theirs
* GNU wants all software to be free
* BSD wants all software to be better
And releasing GCD, gentlemen, is another master stroke by Apple, just like WebKit, Bonjour, LLVM, the list goes on, to share knowledge and advance technology by merit, not by forcing it down your throat thanks to the monopoly you have been handed.
The term "block" is familiar to Ruby programmers. It's an old concept which Ruby has made easy to use and hence popular and actually useful.
And here's another lesson which OpenBSD, Apple and Ruby have been putting to work without you noticing guys: any technology that is difficult to use, no matter how good it is, will not be used if gets in your way; the technology must be easy to deploy/use and unobstrusive to be actually used and useful.
Just remember SELinux and how many people just disable it, no matter how good it is (which I don't think it is, but that's for another rant). Then compare it with the technology that OpenBSD has been implementing for memory protection which is unobstrusive and ready to use with no extra configuration. Same with Ruby blocks, which more programmers are using and a lot of software is benefitting from it now, even though higher order functions and closures have been around for ages.
Having Ruby-like blocks in C and Objective-C is so COOL, you must appreciate that if you think you're serious at programming. Apple has already submitted it to be a standard. I believe MacRuby will benefit from this too, which is Ruby written in Objective-C, which implements Ruby classes as Objective-C classes, achieving incredible speed, taking advantage of Objective-C and LLVM technologies.
Now, I want my late '90s Slashdot back please, where you could more easily find insightful and informative comments. There's a lot of garbage and Microsoft apologists nowadays.
Re: (Score:3, Insightful)
And releasing GCD, gentlemen, is another master stroke by Apple, just like WebKit, Bonjour, LLVM, the list goes on, to share knowledge and advance technology by merit, not by forcing it down your throat thanks to the monopoly you have been handed.
Or because all of those things were originally developed outside of Apple, and even they don't have enough magic fanboy dust to deflect the bad karma that comes from appropriating open source software without giving it back.
So who was it that originally developed GCD and the code to Bonjour?
Awesome! (Score:5, Interesting)
I'm not too well versed in Cocoa development. I pushed some code that should have been in a separate thread into GCD, which requires you to use a block. All in all, I had to add an include, 1 line of code and a closing bracket.
Apple has made some seriously cool stuff here.
Re:Awesome! (Score:4, Insightful)
Having done some multiprogramming, I have to tell that it is really an end-user technology. Less a tool for developer.
One of the biggest problems on multi-CPU/core systems if to split appropriately CPUs between applications. That requires quite amount of testing and benchmarking. Then you simply configure max number of threads each application allowed to use. Obviously changing anything at later time when problem was found requires some effort too.
With GDC that all now is much easier. Available CPU resources are presented to applications in a fashion of real-time batch queue. One doesn't need to configure thread pools per application anymore.
That was never a problem from software development point of view - we just provide the 'max threads' parameter. But that was always problem from user/operator point of view who has to actually fill in the parameter.
Re:Awesome! (Score:5, Informative)
GCD is entirely a developer technology. It's a library for crying out loud! The end-user never does anything with it.
The whole point is to make multi-processing easy for the developer.
I pity the fools who have to use the code you've written.
Re: (Score:2)
No, it just looks like you are trusting the OS to do that for
you and to get it right without any input from you. If the OS
can do that for you as a developer then why can't you do that
in your own code?
Re: (Score:2, Insightful)
For the usual reason that OSs handle resources. Because the OS is in a position to share out resources between applications in a reasonable way. If each app does it's own thing, then it's either a free for all, and pretty much guaranteed to be inefficient.
It also of course has the other usual benefit of libraries. It means that programs don't have to reinvent the wheel every time they write an app. GCD makes writing multi-threaded code using thread pools vastly simpler than before.
Re: (Score:2)
The question is... how is this different to Intel's Thread Building Bocks, or OpenMP, both of which are better supported and more widely available to non-Mac developers.
I guess having their own implemntation (for the mac) makes sense, as they can integrate it throughout the OS. I don't know anything about GCD either, but could it be used in Linux to make that a more parallel-friendly OS with less developer effort, and more standardisation of parallel execution?
Linux is always playing catch-up with Windows f
Re:Awesome! (Score:5, Insightful)
The question is... how is this different to Intel's Thread Building Bocks, or OpenMP, both of which are better supported and more widely available to non-Mac developers.
If I'm not mistaken the technologies are for an application.
GCD can coordinate all applications running on the same system.
I guess having their own implemntation (for the mac) makes sense, as they can integrate it throughout the OS. I don't know anything about GCD either, but could it be used in Linux to make that a more parallel-friendly OS with less developer effort, and more standardisation of parallel execution?
Theoretically yes.
Apple here is in unique position.
Most software developers care solely about their own application. Old example from the desktop. On Windows I have 7-zip archiver installed. I have dual core CPU and this 7-zip is configured to use the 2 cores. From prospective of software developers it's all what they can do: let users tell how much cores/CPUs can be used. But I also have a video encoding application installed - and also configured to use two cores. If I try to run them both in parallel, that would cause erroneous amount of context switching harming performance of both the tasks. In worst case that might make my desktop completely unresponsive. As user I'm also lazy to reconfigure every time applications how many CPUs they should use.
Apple itself now produces number of applications which can utilize multiple CPUs (iTunes audio conversion, iMovie/QuickTime/FC video conversion, etc) and obviously they run into the problem that when applications left on their own to decide how much CPU resources they should use, system would overload leading to all the effects. Requiring user to reconfigure all the applications all the time is also kind of stupid.
Since Apple is in control of the OS and applications - and their own software might suffer from the problem, they went out and implemented the solution: system-wide batch queue with a thread pool. They are still threads - local to the process - but they are scheduled on system-wide basis. You do not need to configure applications how many CPUs they should use - nor applications have to think about: they simply put tasks (to be threads) of the queue of GCD.
I'm using the 'batch queue' term because this is the closest what exists now. Though classical UNIX batch queues are different in nature: those are processes and they are executed at some unknown point of time. GCD is real-time in its nature and its threads run immediately, unlike traditional batch queues which wait for system to be idle.
Re: (Score:2)
Having done some multiprogramming, I have to tell that it is really an end-user technology. Less a tool for developer.
With GDC that all now is much easier. Available CPU resources are presented to applications in a fashion of real-time batch queue. One doesn't need to configure thread pools per application anymore.
I'm so glad GDC is available for general use. I can't count the amount of times I've had to help my grandma configure thread pools for each app. She's totally gonna dig 10.6 now that her mul
Re: (Score:2)
~200 lines of code required to implement thread pool for an application is hardly an effort. Three-four hours of coding at most.
Configuring bunch of applications, each with a thread pool, to utilize system optimally to extract maximum performance out of it - is an effort which has to take every time one deploys the software anew. And in my experience people spend considerable time (weeks) to configure thread pools properly: avoid overload and maximize performance.
I've seen that many times before. I'm
Apache and a threading framework (Score:2, Redundant)
the question is:
What license? Apache v2.0
What the fuck is GCD [wikipedia.org]?
Grand Central Dispatch (GCD), named for Grand Central Terminal, is used to optimize application support for multicore processors. It is an implementation of task parallelism based on the thread pool pattern .NET Framework developed by Microsoft.
GCD works by allowing specific tasks in a program that can be run in parallel to be demarcated as blocks.[2] To this end, it extends the syntax of C, C++, and Objective-C programming languages.[2] At runtime, the blocks are queued up for execution and depending on availability of processing resources, they are scheduled to execute on any of the available processor cores[2] (referred to as "routing" by Apple).[3]
see also
# Task Parallel Library - comparable technology in the
# Java Concurrency - comparable technology in Java (also known as JSR 166).
Re: (Score:2)
Thanks. Now I imagine this might be more useful in BSD, except I'm not sure BSD can incorporate code under an Apache license. Perhaps someone can enlighten me there.
Honestly, I'm more interested in whether or not this can benefit Linux, but I'm assuming it would take a major rewrite to fit the Linux kernel.
Re: (Score:2)
Re:Apache and a threading framework (Score:4, Informative)
pthreads and fork/exec are the equivalent of assembly language for parallelism compared to GCD. The API makes it easy to create anonymous methods that can be parallelized, have dependencies, be put in serial or parallel queues, etc. Then the OS implementation can prioritize at a finely-grained level based on dynamic resource availability, relative process priority, etc., on a system-wide basis. (The OS implementation of GCD was already open-sourced as part of 10.6's Darwin xnu kernel release last week.)
It's pretty nifty stuff. And it's good to see Apple continue MacOS X's tradition of openness and support of open source.
Re:Apache and a threading framework (Score:4, Insightful)
It's an old tech. But it's different this time around.
Old thread pools are per process. This is a thread pool for the whole system. And that's new.
IOW, with GCD you do not need to configure every application how much threads it should start. Applications do not need to bother with it anymore too: they simply queue batch tasks as they arrive and GCD guarantees that they will be executed. Without overloading system.
Shortly, GCD is a system-wide replacement for old per-application thread pool configuration. Makes applications simpler and also doesn't force end-user to understand all oddities of multi-programming to get most out of their boxes.
Blocks and GDC (Score:5, Informative)
Blocks:
In Snow Leopard, Apple has introduced a C language extension called "blocks." Blocks add closures and anonymous functions to C and the C-derived languages C++, Objective-C, and Objective C++.
Perhaps the simplest way to explain blocks is that they make functions another form of data. C-derived languages already have function pointers, which can be passed around like data, but these can only point to functions created at compile time. The only way to influence the behavior of such a function is by passing different arguments to the function or by setting global variables which are then accessed from within the function. Both of these approaches have big disadvantages
Full Read: http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/10
Directly in line with blocks is Grand Central Dispatch (and this is, where blocks become really usefull):
GDC is a a technology to resolve the concurrency conundrum by giving programmers a very easy way to split tasks into multiple sub-tasks which can then be loaded onto different threads/cpu. All this also works with normal threading, but GDC makes the process far easier, with the intention to prepare OSX for future multicore machines:
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12
It does so by using blocks as separate tasks:
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/13
"When I first heard about Grand Central Dispatch, I was extremely skeptical. The greatest minds in computer science have been working for decades on the problem of how best to extract parallelism from computing workloads. Now here was Apple apparently promising to solve this problem. Ridiculous.
But Grand Central Dispatch doesn't actually address this issue at all. It offers no help whatsoever in deciding how to split your work up into independently executable tasksâ"that is, deciding what pieces can or should be executed asynchronously or in parallel. That's still entirely up to the developer (and still a tough problem). What GCD does instead is much more pragmatic. Once a developer has identified something that can be split off into a separate task, GCD makes it as easy and non-invasive as possible to actually do so.
The use of FIFO queues, and especially the existence of serialized queues, seems counter to the spirit of ubiquitous concurrency. But we've seen where the Platonic ideal of multithreading leads, and it's not a pleasant place for developers.
One of Apple's slogans for Grand Central Dispatch is "islands of serialization in a sea of concurrency." That does a great job of capturing the practical reality of adding more concurrency to run-of-the-mill desktop applications. Those islands are what isolate developers from the thorny problems of simultaneous data access, deadlock, and other pitfalls of multithreading. Developers are encouraged to identify functions of their applications that would be better executed off the main thread, even if they're made up of several sequential or otherwise partially interdependent tasks. GCD makes it easy to break off the entire unit of work while maintaining the existing order and dependencies between subtasks." (source = above url)
Re: (Score:2)
GCD -vs- OpenMP (Score:4, Informative)
It looks like GCD [wikipedia.org] is very similar to OpenMP [wikipedia.org]. I am always biased toward using an open standard, when possible. Since many compiler vendors support OpenMP, why didn't apple just implement that for Objective-C, instead of creating their own threading solution? Judging from the examples, GCD looks much cleaner and simpler. But that often comes with a price.
Re: (Score:2)
It looks like GCD is very similar to OpenMP.
Who many lines in OpenMP to implement something like "do this task in a background thread at low priority, and when it's done, do that task in the UI thread"? In GCD it is two lines.
Re:GCD -vs- OpenMP (Score:5, Informative)
GCD and OpenMP have very little in common. OpenMP is a language extension. It requires the programmer to understand what environment their program is going to run in, what variables can be shared and how, etc. GCD merely asks you to identify blocks of code that are independent and it handles parsing them out to threads, variable replication, etc. It's the difference between providing detailed blueprints of a car (the OpenMP way) and just saying "I want a car" (the GCD way). You can *almost* think of GCD as a user-friendly frontend for OpenMP.
Re: (Score:3, Insightful)
"Judging from the examples, GCD looks much cleaner and simpler. But that often comes with a price."
I think you answered your own question. Apple is kind of fanatical for cleaner and simpler and not just in their user interfaces. It's nice. Apple APIs are some of the best I've ever used.
Erlang Anyone? Anyone? (Score:2)
I know the C-like language geniuses won't jump on Erlang immediately, but the multi-core support is awesome. I'm pretty sure there's a port for every platform too.
Re: (Score:2)
Now, libxgrid... (Score:2)
What I really want to see next is libxgrid so that I can use my debian/windows boxes as Xgrid nodes.
My university had around 20 computer labs, some were packed, but some were completely empty. I understand that it'd use more energy, but if you could turn those into a cheap 'super computer' and loan/rent out time to groups on campus.
I've been working with it in C (Score:5, Informative)
I've come to really like GCD; I haven't played with it much in Cocoa (Obj-C) but I've been moving some of the stuff I wrote a long time ago in C to use it and I think I can say that what it does is *really* *really* awesome. It helps when writing code to be run in parallel; it does is not help you in determining *what* should be done in parallel. By putting your work into queues, by way of closures (yeah, blocks, whatever...I'm sticking with the closure name), it's up to the underlying OS to determine what thread gets what work, and on what processor. Having worked with multithreaded stuff on Windows, and calling GetThreadAffinityMask or whatever it was, and being told that it's just a *hint* to the OS, which is free to ignore you, which it always did, GCD really does spread out the work evenly among my 16-proc MacPro, and then turns around and does it just as well on the dual-core mini.
I've wanted something like this for years; a really decent OS thread scheduler that divides up the work on the other processors in a sensible fashion. I was even looking into how much effort it would take to write something like this from scratch for Linux, and now I don't even have to. Sweet!
Caveats: This is in OS X only, so no iPhone GCD (at least, not yet...not really necessary until we have multi-core iPhones), and while I've lived with additions to C++ through the years (templates mostly), the idea of adding, well, anything to C seems strange, let alone something as run-time dependent as closures.
Re: (Score:3, Insightful)
it does is not help you in determining *what* should be done in parallel.
I'd disagree slightly on that point; agreed, the technology doesn't actually make certain code blocks suddenly go "me! me! me!" but it does significantly ease the burden on the developer in making those decisions. I can throw something into the parallelization engine with a couple lines of code to see what difference that makes.
The key example would be something like this one here [github.com], which Slashdot's filter doesn't like (it says please don't use so many junk characters, bah).
That's a nice and simple change to
Re: (Score:2)
16-proc MacPro
O RLY? Where can I get me one of them?
That aside, this is a pretty decent description of what GCD is good for.
How about just callable objects? (Score:2)
I don't mind progress, and new standards and all that, and the idea of a "user-friendly scheduler" is really nice, but how hard would it be to make this work with just generic callable objects? it's not that hard to implement a closure in C, and it's been done for years for things like boost and libsigc++ (any signal/callback system that doesn't have upvalues is useless to me at this point). And it's not like these "blocks" are actually compiled and linked at run time, it's just a pointer to a static functi
Re: (Score:2)
The Key new feature of Grand central is (Score:5, Informative)
Grand central dispatch has many innovations, but the key feature it provides is that thread pooling is now handled by the OS not the program. This means that in a dynamic environment you don't have each application stepping on each other when they ask for too many threads --all total-- than the multi-core system can optimally handle. So if Mail asks for fifty threads and Firefox asks for fifty threads and CPU you are running on can realistically only handle 10 threads then GCD figures out how to manage things so you don't get a spinning beachball.
It turns out a lot of tricks were required to do this including a lot of things like just in time compiling LVM and this C-Blocks stuff, but that's way over my head.
Re:The Key new feature of Grand central is (Score:5, Informative)
GCD is task parallelism (Score:5, Informative)
Re:Use Cilk (Score:5, Insightful)
Re: (Score:2)
Re:Use Cilk (Score:5, Informative)
GCD is designed for small, short-running blocks of code. Read the Ars article on Snow Leopard for examples. Naturally, it will also handle longer-running threads gracefully.
Whoever modded you informative is as ignorant as you.
Re: (Score:2)
I wouldn't be surprised if a lot of the way it was designed is to work with Objective-C, due to it being OS X's primary language.
Re:Use Cilk (Score:5, Informative)
No, GDC is purely a "C with block extensions" API. The blocks are essentially anonymous methods you can pass directly in to functions. It's integrated at a much lower level than Objective-C, which is only used for the higher-level application framework in MacOS.
Apple open-sourced the GDC API with this announcement, block extensions to C with LLVM implementation last week, and the OS support necessary as part of the xnu kernel Darwin release for 10.6.
Re:Use Cilk (Score:4, Insightful)
That's exactly my point. With cooperative multitasking, if you know everything that's going on, it can be more efficient than preemptive multitasking. Just like manually managing your threads can be more efficient than something like GCD.
At the most fundamental level, cooperative is more efficient (if well programmed), just as manually managing threads (if well programmed) is more efficient.
It's that "if well programmed" that's the killer. If your environment is completely known, *and* you are skilled, you have the potential to do a better job by hand. But in the real world, were your software is going to run on all sorts of computers with all sorts of different software and processing capabilities, you can't fine tune your program, so letting the system handle it works better.
Looking at it differently, with cooperative multitasking or manually controlling threads, *if* you have complete knowledge of the system *and* you are sufficiently skilled, you can approach 100% efficiency. With cooperative multitasking, or thread management similar to GCD, you might reach only 90% efficiency. But if you have to build a cooperative multitasking or manually manages threads in a program, that is going to run on all sorts of computers, you may only manage perhaps an overall average 70% efficiency.
And the fact that you can get that 90% efficiency with much less effort than you have to put in to get maybe around 70% (or whatever) efficiency, the benefits here are obvious.
RTFA (Score:5, Informative)
Introducing Blocks and Grand Central Dispatch
Concurrency Programming Guide
Grand Central Dispatch (GCD) Reference"
Re: (Score:2)
And since it seems you're so damned lazy to click links, the first "Introduction to Blocks and Grand Central Dispatch" says
"The central insight of GCD is shifting the responsibility for managing threads and their execution from applications to the operating system. As a result, programmers can write less code to deal with concurrent operations in their applications, and the sy
Re: (Score:3, Insightful)
I like how you refer to a "cult" but lash out with some disproportionate animosity to something, which you fully admit, you don't know anything about.
Sounds like pretty cult-like behavior.
Re:OK, I give up...what is it? (Score:4, Informative)
There's a decent article [wikipedia.org] on wikipedia about it. Basically, it's Apple's multithreading algorithms.
Re:OK, I give up...what is it? (Score:5, Informative)
From the first paragraph:
Grand Central Dispatch (GCD) is a revolutionary approach to multicore computing that is woven throughout the fabric of Mac OS X version 10.6 Snow Leopard. GCD combines an easy-to-use programming model with highly-efficient system services to radically simplify the code needed to make best use of multiple processors. The technologies in GCD improve the performance, efficiency, and responsiveness of Snow Leopard out of the box, and will deliver even greater benefits as more developers adopt them.
libdispatch is the open source implementation of GCD.
Re:OK, I give up...what is it? (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2, Informative)
It is operating system infrastructure that allows programmers to harness modern programmable graphics hardware and regular CPUs as a single anonymous "multi-threaded" resource.
The idea being that now GPUs are becoming double precision capable they are looking increasingly like super computers from yester-year and Grand Central Dispatch allows programmers to easily capitalise on this advance.
Re:OK, I give up...what is it? (Score:5, Informative)
You should check out this astounding OpenCL demo here: http://www.macresearch.org/opencl_episode1 [macresearch.org]
Re: (Score:2)
Everyone who reads slashdot isn't an OSX ween and has no idea what "Grand Central Dispatch" is.
Yeah, I thought Google bought Grand Central and was trying to figure out how their call routing tech had made it into Apple's hands.
Re:OK, I give up...what is it? (Score:5, Informative)
ArsTechnica always does a pretty thorough and reasonably technical review of each OSX release, and the latest one gives a pretty good explanation of GCD as well as Blocks.
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars [arstechnica.com]
The GCD stuff in particular starts on page 12, but the previous couple pages give a little bit of useful background on why it's important.
Re:OK, I give up...what is it? (Score:5, Insightful)
"Apple has open sourced libdispatch, also known as Grand Central Dispatch, which is technology in Snow Leopard that makes it easier for developers to take advantage of multi-core parallelism."
First line of THE SUMMARY.
I know it's not hip to RTFA, but it's at least a minimum requirement to read the very next line after the title, even while scrolling down eagerly to make a comment.
Re:OK, I give up...what is it? (Score:5, Insightful)
Everyone who reads slashdot isn't an OSX ween and has no idea what "Grand Central Dispatch" is. Perhaps a sentence or two describing why it is important/useful would save users from following the link which doesn't provide that info either.
Look I'm as annoyed by poor summaries as anyone, but it seems almost reflexive to complain about them these days. The summary clearly said it, "makes it easier for developers to take advantage of multi-core parallelism". I don't care if you've never heard of OS X and no nothing about it. That sentence right there tells you what effect it has and why it's useful. After that it's just details as to where and if it is applicable to some other project. I guess what I'm saying is, I thought this was a pretty decent summary, enough to know if you should read about it.
Re:OK, I give up...what is it? (Score:5, Funny)
also known as Grand Central Dispatch, which is technology in Snow Leopard that makes it easier for developers to take advantage of multi-core parallelism.
They kinda' snuck that one in.
Re: (Score:2)
This [arstechnica.com] and the next 3 pages in that review explain it all very well.
Google (Score:2)
Re: (Score:2)
"which is technology in Snow Leopard that makes it easier for developers to take advantage of multi-core parallelism."
That's a hell of a lot better than you get from the usual Slashdot summary.
Re: (Score:2)
I came here to say exactly this.
A lot of "web two point oh" people seem to love these sorts of silly names. For some reason, Apple does too...
It's very frustrating as a non-mac-cultist to see things like "Snow Leopard", or "Grand Central Dispatch" and have no clue what it means. Version numbers guys, use them!
Re: (Score:3, Funny)
Re: (Score:3, Informative)
What sort of explanation would you like?
A general overview for the layman? [gizmodo.com]
A more thorough overview for the OS enthusiast? [arstechnica.com]
A detailed overview from a developer's perspective? [apple.com]
Re:...what is it? Check the apple web site... (Score:5, Interesting)
Shoot, I already noticed the difference on my 2.5 yr old Mac Pro (1.1). First boot on 10.6 and I was like "wow, feels like a new machine again". All of the bundled apps have been recompiled (64 bit) and cleaned up (and apparently take advantage of GCD everywhere possible). I really didn't think I would see that much of a difference with 10.6 and really only upgraded because I could for $29 (I mean at that price, why not right?) I am very happy with my $29 purchase thus far. I've only had to work through a couple app incompatibilities (and as I have been able to work around them just fine, I am happy.) This is of course just my experience thus far with 10.6. I have no hard benchmark numbers for you. But I noticed right away the smoothness it brought to my older Mac Pro. And it was an easier upgrade than going from 10.4 --> 10.5.
Re:...what is it? Check the apple web site... (Score:5, Insightful)
What if you're running two applications that both are capable of monopolizing all your cpu time? How will your app know that it's only going to get 50% of the available cpu time form the OS, so it should only start threads for half the cpus?
GCD decides how many threads a collection of tasks should be split across. If an app running on an 8-core machine wants to run 100 tasks, then they could be spread across anywhere from 1 to 8 threads, depending on what else is running. Since it's the OS that knows what else is running, it can make more intelligent decisions about how many threads should be running.
Re: (Score:2, Informative)
Abstraction is the main theme in progression in programming. Blocks (Language change) and the rest of the package provide such an abstracted view.
GCD also does not need kernel changes as written in the sumary.
Re: (Score:2)
I'd say crippled is too strong of a word here. Form the libdispatch project main page [macosforge.org], linked in the blurb above:
While kernel support provides many performance optimizations on Mac OS X, it is not strictly required for portability to other platforms.
Re: (Score:3, Insightful)
Re: (Score:2)
Why parallel programming has to be tied to a kernel change and to a language spec change, when a good library (OpenMP, anyone?, but I'm sure there are others) will suffice...
GCD is not tied to the kernel and a parallel programing library (like OpenMP) won't suffice, because none of the ones that I've seen so far is as easy to use as GCD backed blocks.
Good support for OpenMP or any of the existing shared memory parallel programming libraries would have been much cleaner and portable.
GCD is pretty clean and, since both libdispatch and llvm are open source (and under BSD-like licenses), it and the code written against it are infinitely portable.
Re: (Score:2)
Apple has a long tradition to make things its own way, not always in the cleanest way under the hood.
I grew out of being purist and now I can reply you: to keep the sh1t in one place.
Otherwise you can go Linux way: keep tech under the hood clean, but as collateral force every program to swallow some of the sh1t and pass it on to end user.
And we all know that in the end the approach doesn't work. Struggles of Linux on desktop is the best evidence of that.
Re: (Score:2)
> And we all know that in the end the approach doesn't work. Struggles of Linux on desktop is the best evidence of that.
No it isn't really.
The Linux desktop as it is today didn't exist in 1997. It hadn't even been started yet.
On the other hand, Windows and MacOS had over 10 years of product releases. Despite the fact that MacOS was VASTLY SUPERIOR in by any metric except for "price" and "compatability" it continued to have it's ass handed to it time and time again in the market by MS-DOS of all things.
"B
Re: (Score:2, Interesting)
Why parallel programming has to be tied to a kernel change and to a language spec change, when a good library (OpenMP, anyone?, but I'm sure there are others) will suffice...
OpenMP requires "language changes" - it introduces new compiler keywords, and the compiler must support it, it's not "a library".
Get yourself a clue.
Re: (Score:3, Informative)
Note that OpenMP is supported in Mac OS X, and has been for a while. It's just not as user-friendly, you have to think a lot more about variable scope and dependencies.
With Grand Central Dispatch, you basically only have to flip a boolean flag and it's running in parallel (in ObjC at least).
Re: (Score:2)
If everyone did everything one way there would never be any progress. Apple uses many open standards and open source code, while making their own alternatives when they need something better. Nothing wrong with that.
Re: (Score:3, Insightful)
Good support for OpenMP or any of the existing shared memory parallel programming libraries would have been much cleaner and portable.
This seems to be one of the common complaints in this discussion ("why not contribute to an existing project instead?") and others involving Apple's open-source participation, and certainly it has merit. But open-source developers write their own more-or-less redundant tools all the time with no better justification than "I didn't like how tool X handled the specific case Y, so I wrote my own tool from scratch" - SourceForge is littered with them. So (I'm responding generally, not to the parent) I don't see
Re:GPL violation? (Score:5, Informative)
Well, I can see the logic of your concerns but Apple do actually seem to be fairly good at open sourcing infrastructure-related things. Sure they maintain a tight control on the user-facing stuff that makes Apple products distinctive - on the iPhone they even maintain a tight control on applications. But bear in mind they're working on an open source kernel, employ developers to work on the LLVM compiler (open source), open sourced an init-ish daemon (launchd) they developed, etc etc. On stuff that's "for geeks" they seem fairly enlightened wrt open source.
It's quite surprising from a company like Apple but the fact that they manage to make surprising decisions like that looks like a strong technical management team at work, to me.
Re: (Score:3, Informative)
Don't forget they've contributed a lot to WebKit, which now seems to be used by every new browser that comes out.
Re:GPL violation? (Score:4, Insightful)
It's quite surprising from a company like Apple...
Companies are defined by what they do. If a person surprised Apple is releasing technologies as open source projects, that just means that person has an inaccurate image of what kind of company Apple is and should pay more attention to what Apple does and less to espoused, unsupported opinions from astroturfers and zealots.
Re:GPL violation? (Score:5, Insightful)
Re:GPL violation? (Score:4, Insightful)
Apple actually owns CUPS now. But, yes, they still make it available under an OSS license.
Re:GPL violation? (Score:4, Informative)
P.S. As in interesting tidbit, you'll notice that clamAV is posted there as well. Hmm, makes you wonder.
Re: (Score:2)
As in interesting tidbit, you'll notice that clamAV is posted there as well. Hmm, makes you wonder.
It's used in OS X server, where it integrates with the mail service in order to filter/block emails containing known viruses.
Re: (Score:3, Insightful)
If they were violating the GPL they probably wouldn't have released it under the Apache 2.0 license..
Re: (Score:2)
Re: (Score:2)
Absolutely true, but I want to point out that Apple's just trying to make simple things easy -- they're not trying to say that they've finally solved truly capital-h Hard concurrency problems.
Re: (Score:2)
There is no tech that can help you with that. Maybe Apple should solve the solvable problems first (making parallelizing easy) before tackling the unsolvable ones?
Re:Kamikaze development (Score:5, Insightful)
You are posting in a thread about the fact that Apple made their implementation open source and you are claiming vendor lock-in?
Are you one of those rabid Apple-haters we see so often around here? Or are you just amazingly stupid?
Re: (Score:2)
Not the whole problem, but actually, yes, some of the problem is with languages.
And some problems are not hard to multi-thread, and yet reasonably competent programmers end up sometimes screwing it up anyway. They make mistakes not because they're stupid, but because (for example) they're in a hurry. (All professional programmers are in a hurry. Sh
Re: (Score:2)
I agree. Furthermore, these "high level language" things are just dangerous toys that let overconfident children shoot themselves in the feet more quickly. It should be the law that if you want to program a computer you have to use a real language - Assembly.
Re: (Score:3, Insightful)
So you're saying gcc is being used for vendor lock in?
Re: (Score:2)
The vender's (Apple's) compiler? You realize that you're talking about gcc, right?
Re: (Score:3, Interesting)
SMP = Symmetric Multi-Processing. GCD, in theory, will also allow access to Asymmetric Multi-Processing as well since you can take advantage of GPU resources and cores as well.
Re: (Score:2)
GCD doesn't support using GPUsâ" that's what OpenCL is for. That said, there were some nice demos at WWDC where, for example, a solar-system modelling tool (tracking the gravitational movements of a zillion objects in real-time) was rewritten by adding first GCD then OpenCL. Using GCD to offload calculations to other threads in parallel made quite a difference, then OpenCL just blew the lid off. It was SCARY just how much difference it made. And the nice part was that GCD gave a nice performance boost
Re: (Score:2)
multi-core != SMP. see: PS3.
Re: (Score:3, Informative)
That's great and all, but systems have been doing this for years. When I launch a thread on Linux I don't care where it ends up. The scheduler takes care of it. Same with Perl, pthreads, OpenMP and pretty much every other threading technology I've ever used.
What's new here?
With GCD, you don't "launch a thread". You "start a task", and how it is scheduled in a thread pool is up to the library. You don't muck around with locks, either - you define dependencies between tasks, and they're scheduled accordingly.
Why don't you just look at some examples of GCD use, and see for yourself? It really is much clearer to see the code in this case.
Microsoft has a very similar thing, by the way - Parallel Patterns Library [microsoft.com] - except that one is for C++ only, and uses C++0x lambdas rather than
Re: (Score:3, Informative)