×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Apple Open Sources Grand Central Dispatch

kdawson posted more than 4 years ago | from the waitin'-for-a-train dept.

Programming 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

342 comments

first post (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#29388321)

first post

Re:first post (0)

Anonymous Coward | more than 4 years ago | (#29389387)

This isn't offtopic, it's perfectly accurate. Modded +1

Uh oh (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#29388333)

Cue moronic GNU faggots whining about how it sucks because Stallman didn't come up with it in 5... 4... 3... 2... 1...

Re:Uh oh (0)

Anonymous Coward | more than 4 years ago | (#29388775)

Not. Invented. Here.

Re:Uh oh (0)

jedidiah (1196) | more than 4 years ago | (#29389045)

More importantly... "why bother?".

It has a very "big sounding" name for what it is.

Re:Uh oh (1, Informative)

Anonymous Coward | more than 4 years ago | (#29389233)

I'd say adding anonymous functions to C is more than just 'big sounding'.

You should have been Funny, not Flamebait (0)

Anonymous Coward | more than 4 years ago | (#29389251)

Yup.

OK, I give up...what is it? (1, Insightful)

Ritz_Just_Ritz (883997) | more than 4 years ago | (#29388361)

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.

I want those 5 seconds back! :)

GCD is task parallelism (5, Informative)

tepples (727027) | more than 4 years ago | (#29388391)

It's a library for task parallelism using a thread pool, introduced in Mac OS X 10.6 (Snow Leopard). Wikipedia tells all [wikipedia.org].

Happy Birthday America!!! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29388685)

-Saddam

Use Cilk (0)

pikine (771084) | more than 4 years ago | (#29388687)

Just looked at libdispatch source code. It is apparently very Mac OS X specific, and will take a lot of work to be ported cross platform. The queue implementation also looks like it imposes a lot of overhead, so it is not very useful for parallelizing short-running "blocks" of code.

Why not use something like Cilk [mit.edu] which has proven its salt? The only caveat of Cilk is that it requires any parallel code to be compiled with the Cilk compiler (which will generate C code), and unless you're willing to kickstart the Cilk runtime manually, any caller of the parallel code needs to be compiled with Cilk too, which includes main(). The technical reason is Cilk does a continuation passing style transformation (requiring a different calling convention) which allows a function caller to be stolen by the work-stealing scheduler while the function waits for the callee to finish, allowing the critical path to focus on work instead of manipulating the task queue. The result is a highly efficient and scalable parallel execution runtime, the best I've seen.

Re:Use Cilk (5, Insightful)

PacoCheezdom (615361) | more than 4 years ago | (#29389025)

You don't think that libdispatch will be very genial to widespread usage, as it has a lot of OS-specific calls, which is an understandable position to take. But as an alternative you offer something whose "only caveat" is that it needs an entirely different compiler to build. A compiler whose most recent activity dates from two years ago.

... How is that a superior alternative?

Re:Use Cilk (1)

Rogerborg (306625) | more than 4 years ago | (#29389055)

The usual way: anything that I know how to use is obviously far superior to everything that you know how to use.

Re:Use Cilk (4, Informative)

Dog-Cow (21281) | more than 4 years ago | (#29389041)

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:Use Cilk (0, Troll)

Anonymous Coward | more than 4 years ago | (#29389421)

Maybe someone who already read can post an illustrative example? I'm bitter and cynical and don't care to chase after every ball a marketing dweeb throws my way, and am simply curious where this fits in the constellation of parallelism that dates back 30 years or more.

Who identifies the work units which can run in parallel? A compiler or the application programmer?

Who identifies the decomposition of the application data model into the work units and their state sharing and synchronization? A compiler or the application programmer?

Who identifies the strategy for gathering work unit results back into the sequentially consistent form required after they all complete? A compiler or the application programmer?

If the answer to all of these is the programmer, how does this really differ from the idiomatic POSIX threads application which uses user direction and/or trivial system probes to choose a thread count N appropriate to the system, then fires off N threads running the same worker function (block), then uses normal synchronization to wait for the threads to complete?

Re:Use Cilk (1)

AndrewNeo (979708) | more than 4 years ago | (#29389131)

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 (4, Informative)

samkass (174571) | more than 4 years ago | (#29389189)

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:GCD is task parallelism (0)

Anonymous Coward | more than 4 years ago | (#29388827)

Software is currently offered under Apache License, Version 2.0, once people contributed, Apple will change the license to APPLE PUBLIC SOURCE LICENSE as they did with mDNSResponder (bonjour). If they are truly interested to port to other platforms, they should have released under BSD license so that you do not have to worry about patent claims.

Re:GCD is task parallelism (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#29389293)

So in other words, they wrote a library to do:


        my $max = 16;
        my $num = 0;
        for my $f (glob "/something/*"){
                while($num >= $max){
                        $num-- if wait();
                }
                if(fork()){
                        $num++;
                }else{
                        dostuff($f);
                        exit;
                }
        }
        1 while(wait() > 0);

RTFA (5, Informative)

yabos (719499) | more than 4 years ago | (#29388393)

"We recognize that libdispatch is a new technology and you likely have many questions. Here are some documentation resources for getting started:

Introducing Blocks and Grand Central Dispatch
Concurrency Programming Guide
Grand Central Dispatch (GCD) Reference"

Re:RTFA (-1, Flamebait)

Rogerborg (306625) | more than 4 years ago | (#29389119)

RTFA

Read The Fucking Comment: that Fucking information is not "in the first few Fucking paragraphs" of the Fucking article, you Fucking zealot. If you're too Fucking dumb to recognise a Fucking question that's designed to Fucking help people get Fucking inducted into your Fucking cult then I'm guessing that you're too Fucking poor to afford in iFuck and must have Fucking robbed it from some latte-Fucking weedy looking Fuckwad.

Mad love, Fucknut!

Re:RTFA (1)

yabos (719499) | more than 4 years ago | (#29389207)

Maybe you should RTFC yourself. The links are right there on the page and unless you're a complete idiot you can clearly see it.

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 system can perform more efficiently on single-processor machines, large multiprocessor servers, and everything in between. Without a pervasive approach such as GCD, even the best-written application cannot deliver the best possible performance, because it doesnâ(TM)t have full insight into everything else happening in the system."

If you can't figure out what that means then GTFO this site.

Re:RTFA (2, Insightful)

MachineShedFred (621896) | more than 4 years ago | (#29389325)

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? (3, Informative)

dave-tx (684169) | more than 4 years ago | (#29388395)

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? (4, Informative)

Lord Grey (463613) | more than 4 years ago | (#29388397)

Introducing Blocks and Grand Central Dispatch [apple.com] is what you're looking for.

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? (3, Insightful)

je ne sais quoi (987177) | more than 4 years ago | (#29388411)

I want the 5 seconds back that I just spent reading your comment. It would have taken you less time to google it and read the first few sentences of wikipedia [wikipedia.org] than write that:

Grand Central Dispatch (GCD), named for Grand Central Terminal, is an Apple technology used to optimize application support for multicore processors.[1] It is an implementation of task parallelism based on the thread pool pattern. It was first released with Mac OS X 10.6.

Re:OK, I give up...what is it? (1, Insightful)

Anonymous Coward | more than 4 years ago | (#29388757)

But the parent is right about the fact that those two sentences should have been part of kdawson's post.

Not everybody knows everything about every subject, I find it confusing with most of the OSS projects, especially given the weird names they give their stuff.

Re:OK, I give up...what is it? (2, Informative)

Anonymous Coward | more than 4 years ago | (#29388413)

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? (1)

chetbox (1335617) | more than 4 years ago | (#29388427)

From Wikipedia [wikipedia.org]:

an Apple technology used to optimize application support for multicore processors

It essentially gives programmers a way to split their code into "blocks" which can be run on different processors. libdispatch then decides which processor to run each "block" on, so that the load is spread efficiently. It's similar in concept to threading except that events can trigger a new work-block to be created rather than a thread waiting for an event.

Re:OK, I give up...what is it? (1)

Jah-Wren Ryel (80510) | more than 4 years ago | (#29388505)

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? (5, Informative)

cowscows (103644) | more than 4 years ago | (#29388533)

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? (0)

Anonymous Coward | more than 4 years ago | (#29388623)

Everyone who reads slashdot isn't an OSX ween and has no idea what "Grand Central Dispatch" is.

i would have thought that everybody on google knows how to use google though :P

ars has a good discussion about it (and much more):
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12

Re:OK, I give up...what is it? (0)

Anonymous Coward | more than 4 years ago | (#29388707)

I'm pretty sure they are the operations department at Grand Central Station who are responsible for keeping the trains on time (scheduling threads) while preventing collisions (critical sections), traffic jams (deadlocks) and keeping customers happy (UI responsiveness). But then I could just be all wet.

Re:...what is it? Check the apple web site... (0)

klubar (591384) | more than 4 years ago | (#29388785)

You should just check the apple web site.

Yesterdays top news in /. was how wonderful and easy-to-use the Apple web site was. If you can't find the answer, including full documentation on the site, you don't need to worry your pretty little haad about it. We're Apple, marketing (and really clever naming) rules.

See below for marketing jargon speak:

Grand Central Dispatch (GCD) in Mac OS X Snow Leopard addresses this pressing need. It's a set of first-of-their-kind technologies that makes it much easier for developers to squeeze every last drop of power from multicore systems. With GCD, threads are handled by the operating system, not by individual applications. GCD-enabled programs can automatically distribute their work across all available cores, resulting in the best possible performance whether they're running on a dual-core Mac mini, an 8-core Mac Pro, or anything in between. Once developers start using GCD for their applications, you'll start noticing significant improvements in performance.

Re:...what is it? Check the apple web site... (0)

jedidiah (1196) | more than 4 years ago | (#29389101)

Thread scheduling is already handled by the operating system. This is OS 101 stuff from the 80s. What ELSE does GCD add?

My multi-threaded apps can already monopolize every CPU on my
box whether it is a 4 core desktop or a 64 core server. Been
that way for a LONG time.

Re:...what is it? Check the apple web site... (4, Interesting)

Penguin Follower (576525) | more than 4 years ago | (#29389171)

Once developers start using GCD for their applications, you'll start noticing significant improvements in performance.

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:OK, I give up...what is it? (0)

Anonymous Coward | more than 4 years ago | (#29388879)

read for comprehension.
the summary says it clearly "which is technology in Snow Leopard that makes it easier for developers to take advantage of multi-core parallelism."

Re:OK, I give up...what is it? (4, Insightful)

jo_ham (604554) | more than 4 years ago | (#29388921)

"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? (4, Insightful)

99BottlesOfBeerInMyF (813746) | more than 4 years ago | (#29388941)

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? (4, Funny)

Gilmoure (18428) | more than 4 years ago | (#29389005)

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:OK, I give up...what is it? (0)

Anonymous Coward | more than 4 years ago | (#29389089)

I saved those 5 seconds, actually! I didn't even RTFS :D

captcha: shortcut.

Google (1)

Gary W. Longsine (124661) | more than 4 years ago | (#29389163)

What you meant to say was, "Everyone who reads Slashdot isn't an internet weeny, and has no idea how to find out what a technology of which they haven't heard before might be, other than imploring (counterproductively with a snide remark) to be spoon fed by other participants in the discussion." The answer is the wonderful invention, Google [google.com]. You can type a word or phrase, like "Grand Central Dispatch", and Google will present you with links to document which discuss it. Oftentimes, one of those documents might appear at the web site of an online community encyclopedia, known as Wikipedia [wikipedia.org], which not only describes the thing in question, but also frequently provides convenient links to additional information.

Re:OK, I give up...what is it? (1)

travler (88311) | more than 4 years ago | (#29389413)

"...which is technology in Snow Leopard that makes it easier for developers to take advantage of multi-core parallelism..."

This seems pretty clear to me, not sure what more you want. Googling 'Grand Central Dispatch' comes up with lots of details.

Remember this is news for _nerds_. :)

What? (2, Interesting)

julesh (229690) | more than 4 years ago | (#29388375)

Can somebody explain what this "blocks" is? I mean, C being a block-structured language, I thought it already supported them...

Re:What? (5, Informative)

Daniel_Staal (609844) | more than 4 years ago | (#29388405)

Blocks are sections of program that can be passed around between functions as arguments. They basically allow 'functional' programming in C.

Re:What? (2, Informative)

644bd346996 (1012333) | more than 4 years ago | (#29388421)

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? (1)

ThePhilips (752041) | more than 4 years ago | (#29388627)

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.

Awesome! (5, Interesting)

gers0667 (459800) | more than 4 years ago | (#29388381)

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! (4, Insightful)

ThePhilips (752041) | more than 4 years ago | (#29388699)

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! (0)

Anonymous Coward | more than 4 years ago | (#29388831)

Having done some multiprogramming, I have to tell that it is really an end-user technology. Less a tool for developer.

Having also "done some multiprogramming" (I work in HPC), it's very much a tool for developers as well as the end-user.

In my case the end user and developer are the same person - me. I'm not alone in this situation.

Re:Awesome! (1)

ThePhilips (752041) | more than 4 years ago | (#29389071)

~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 also seeing the same with product sold by my employers: we have at least four applications with thread pools. Coming up for every deployment with the suitable configuration (which depends on business case of customer) is a time consuming process.

Re:Awesome! (0)

Anonymous Coward | more than 4 years ago | (#29389401)

~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 also seeing the same with product sold by my employers: we have at least four applications with thread pools. Coming up for every deployment with the suitable configuration (which depends on business case of customer) is a time consuming process.

Sounds like this stuff is very much a tool for the DEVELOPER then.

Anything that allows me to spend more time thinking about the overall problem, as a solid implementation for some of the nuts and bolts already exists, can only be good for me.

Re:Awesome! (5, Informative)

Dog-Cow (21281) | more than 4 years ago | (#29389097)

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:Awesome! (1)

jedidiah (1196) | more than 4 years ago | (#29389213)

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?

Apache and a threading framework (1, Redundant)

RiotingPacifist (1228016) | more than 4 years ago | (#29388383)

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
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 .NET Framework developed by Microsoft.
# Java Concurrency - comparable technology in Java (also known as JSR 166).

Re:Apache and a threading framework (1)

Enderandrew (866215) | more than 4 years ago | (#29388409)

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:Apache and a threading framework (1)

MrMr (219533) | more than 4 years ago | (#29388531)

Task parallellism libraries are essentially fancy wrappers around fork-and-exec. That is really old tech, and needs no rewrite.

Re:Apache and a threading framework (3, Informative)

samkass (174571) | more than 4 years ago | (#29388639)

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 (3, Insightful)

ThePhilips (752041) | more than 4 years ago | (#29388835)

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 (5, Informative)

Anonymous Coward | more than 4 years ago | (#29388455)

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:Blocks and GDC (0, Troll)

inKubus (199753) | more than 4 years ago | (#29389335)

So it's slow, but convenient, multi-threading. That's ok because the 16 core and 32 core chips will be here in 3 years.

If you want to do something fast you're not going to rely on a big, general OS library to queue up threads... Photoshop, for instance, will not be using this library. ;)

This does not help, Apple. (1, Interesting)

Anonymous Coward | more than 4 years ago | (#29388537)

Apple has a long tradition to make things its own way, not always in the cleanest way under the hood. This does not always help, and sometimes it just adds to the confusion. 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... Good support for OpenMP or any of the existing shared memory parallel programming libraries would have been much cleaner and portable.

Disclaimer: I use/program/work with an Intel Macbook Pro.

Re:This does not help, Apple. (2, Informative)

cbreak (1575875) | more than 4 years ago | (#29388635)

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:This does not help, Apple. (0)

Anonymous Coward | more than 4 years ago | (#29388743)

> GCD also does not need kernel changes as written in the sumary.

Without a kernel implementation, GCD is crippled.

Re:This does not help, Apple. (1)

lurch_mojoff (867210) | more than 4 years ago | (#29389091)

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:This does not help, Apple. (2, Insightful)

lisaparratt (752068) | more than 4 years ago | (#29388647)

My understanding of GCD is that it makes parallel programming and, importantly, interacting with the UI, pretty damned easy.

And despite that, if the only thing you can think of to do with Blocks is threading, then you seriously need to get back to learning your CompSci. Resource Allocation Is Invocation becomes a load more practical, and that alone would mark a major shift between C code that's mostly resource and error management overhead and code that actually does something.

Re:This does not help, Apple. (1)

lurch_mojoff (867210) | more than 4 years ago | (#29388857)

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.

Wait, WHAT?! (1, Informative)

Anonymous Coward | more than 4 years ago | (#29389169)

You and I must not be reading the same code.

libdispatch constantly references mach throughout, which is unique to OS X and would take ages to #ifdef out completely. It also makes use of features only available in GCC 4.2.x or later, which means that many older platforms are out in the cold. It also makes a ton of platform assumptions (though luckily many of these are #define'd, so they can be redefined for other platforms later, however there's plenty that isn't, and is coded specifically for Intel platform performance). Furthermore, it codes in some really weird Apple-specific things (like label names for the priority queue levels, #ifdef's for Cocoa support, other very strange code, not clean in anyone's definition).

With some significant work by an interested party, it could be made portable, but Apple didn't Open Source it with the idea that it'd immediately build on non-x86, Linux, or Windows (and in fact, it might be ages before it builds on the latter, using pthreads and functions like sysctlbyname(3) throughout). It could be portable... some day. But as it stands it's not. At all.

Re:This does not help, Apple. (1)

ThePhilips (752041) | more than 4 years ago | (#29388917)

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:This does not help, Apple. (1)

jedidiah (1196) | more than 4 years ago | (#29389329)

> 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.

"Better engineering" in Cupertino isn't all it's cracked up to be.

Re:This does not help, Apple. (2, Interesting)

Anonymous Coward | more than 4 years ago | (#29388923)

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:This does not help, Apple. (2, Informative)

am 2k (217885) | more than 4 years ago | (#29389063)

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).

GPL violation? (0, Insightful)

Anonymous Coward | more than 4 years ago | (#29388651)

Why would Apple suddenly open-source a major feature of their new OS? Did they get busted violating the GPL? It doesn't make sense that the most closed-source draconian control-freak vendor of all would suddenly open-source major parts of their OS without some legal Sword of Damocles hanging over their head. What aren't we being told here? Whose code did they get caught stealing?

Someone somewhere owes the community an explanation!

Re:GPL violation? (4, Informative)

Lemming Mark (849014) | more than 4 years ago | (#29388931)

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:GPL violation? (1)

dingen (958134) | more than 4 years ago | (#29388933)

Why is it so remarkable to you that Apple open sources one of their technologies? They already have several open sources projects which they use in their software, such as Darwin and Webkit. They also use lots of 3rd party open source technologies in their software. I don't think they're doing all of this because they're somehow violating licenses, but because they just think open source isn't so bad.

Re:GPL violation? (4, Insightful)

UnknowingFool (672806) | more than 4 years ago | (#29388945)

Apple has a long history of open source contributions since OS X. Apple has released parts of OS X as Darwin [wikipedia.org] under a BSD license since they first released OS X. OS X was developed from OPENSTEP which came from NextStep which itself was based on BSD. The kernel itself is derived from XNU which was based on the Mach kernel. All of these components are covered by BSD licenses. From what I understand since Apple uses a lot of open source Unix programs like CUPS, etc, they do contribute to fixes and patches on a regular basis.

Re:GPL violation? (3, Insightful)

Dog-Cow (21281) | more than 4 years ago | (#29389141)

Apple actually owns CUPS now. But, yes, they still make it available under an OSS license.

Re:GPL violation? (0)

Anonymous Coward | more than 4 years ago | (#29389083)

Someone somewhere owes the community an explanation!

Yes. That someone is you. That community is retards. You're making them look bad.

Re:GPL violation? (1)

cbreak (1575875) | more than 4 years ago | (#29389143)

Big parts of Mac OS X are open source, including the kernel, the compiler and some basic libraries. Now including LLVM, Clang and GCD.

Re:GPL violation? (2, Insightful)

AndrewNeo (979708) | more than 4 years ago | (#29389173)

If they were violating the GPL they probably wouldn't have released it under the Apache 2.0 license..

GCD -vs- OpenMP (3, Informative)

MobyDisk (75490) | more than 4 years ago | (#29388735)

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:GCD -vs- OpenMP (0)

Anonymous Coward | more than 4 years ago | (#29388793)

OpenMP is dirt simple to use. If you want 'elegance', implement is att as function calls instead of pragmas. But leave the programming language the f*ck alone!

Re:GCD -vs- OpenMP (1)

gnasher719 (869701) | more than 4 years ago | (#29388887)

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.

Not Invented at Apple (0, Troll)

Anonymous Coward | more than 4 years ago | (#29388937)

OpenMP was not invented by Apple, and cannot be used as a lever to undermine gcc.

Re:GCD -vs- OpenMP (1)

thefear (1011449) | more than 4 years ago | (#29388975)

Further, why did Apple invent a new syntax for 'Blocks' instead of using the one already proposed for C++0x. It will make things overly complex if someone wants to use GCD with the new C++ standard, or create portability issues...

IMO, developers are better off using OpenMP which doesn't require non-standard compiler extensions and is supported by more vendors.

Kamikaze development (-1, Flamebait)

gwappo (612511) | more than 4 years ago | (#29388905)

The problem with multi-threading isn't in laborious API's, it's also not in language support for nifty features. The problem with multi-threading is that some problems are damn hard to multi-thread, either due to algorithms, or more commonly due to the way the internal structures are linked together. This will only make overconfident developers shoot themselves in the foot more quickly (and provide some vendor lock-in for apple as things get increasingly less portable.)

Re:Kamikaze development (1, Insightful)

Anonymous Coward | more than 4 years ago | (#29388963)

no need for kernel support
open source implementation

yeah. sounds a helluvalot like vendor lock-in to me

Re:Kamikaze development (1)

TomorrowPlusX (571956) | more than 4 years ago | (#29389149)

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:Kamikaze development (1)

am 2k (217885) | more than 4 years ago | (#29389157)

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 (5, Insightful)

Dog-Cow (21281) | more than 4 years ago | (#29389175)

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?

Erlang Anyone? Anyone? (1)

mpapet (761907) | more than 4 years ago | (#29389345)

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.

Now, libxgrid... (1)

0100010001010011 (652467) | more than 4 years ago | (#29389353)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...