Technology Brief for Apple's Grand Central Multicore Paradigm [pdf]

#1

Post by nickb » Mon, Jun 08, 2009, 8:18 PM UTC

Technology Brief for Apple's Grand Central Multicore Paradigm [pdf]
images.apple.com

Re: Technology Brief for Apple's Grand Central Multicore Paradigm [pdf]

#2

Post by swannodette » Mon, Jun 08, 2009, 10:02 PM UTC

While all the Apple hardware announcements look great, I think this is possibly an even more significant announcement. C/Objective-C/C++ gets lambdas and closures! It looks like Apple has a very interesting single machine concurrency story here.

Right now I'm really enjoying Clojure- it's lockless approach to single machine concurrency is plenty, plenty fun. Unfortunately the downside of learning Clojure is that many other popular languages look downright archaic to me in this regard now. Now reading over this document, whodathunk, concurrency programming might be as fun in C as it is in Clojure!

Re: Technology Brief for Apple's Grand Central Multicore Paradigm [pdf]

#3

Post by jmtulloss » Mon, Jun 08, 2009, 10:09 PM UTC

First of all, this is awesome.

I am missing some details though. Are these true closures? What are the scoping rules? Can you read data declared outside of your block? Can you alter it? Is the only way to keep alterations safe to use a private queue? I guess time (or a closer reading) will tell.

Re: Technology Brief for Apple's Grand Central Multicore Paradigm [pdf]

#4

Post by gchpaco » Mon, Jun 08, 2009, 10:26 PM UTC

This encourages a very different style of multicore programming than is common on desktops today, closer to that of grid systems. Very interesting to see how this develops.

Re: Technology Brief for Apple's Grand Central Multicore Paradigm [pdf]

#5

Post by agocke » Mon, Jun 08, 2009, 10:49 PM UTC

I wonder how this will affect the legacy methods of concurrency in OS X -- specifically POSIX threads. I know I wrote a number of C apps using POSIX threads that worked well in OS X and in Linux. While this is nice and interesting for Mac only programs, I hope that I don't have to rewrite my cross platform apps to take advantage of the API.

Re: Technology Brief for Apple's Grand Central Multicore Paradigm [pdf]

#6

Post by wmf » Mon, Jun 08, 2009, 10:53 PM UTC

agocke wrote: post #5

I wonder how this will affect the legacy methods of concurrency in OS X -- specifically POSIX threads. I know I wrote a number of C apps using POSIX threads that worked well in OS X and in Linux. While this is nice and interesting for Mac only programs, I hope that I don't have to rewrite my cross platform apps to take advantage of the API.

Obviously pthread support won't be removed; pthread programs just won't play as nice with each other as Grand Central programs.

Re: Technology Brief for Apple's Grand Central Multicore Paradigm [pdf]

#7

Post by swannodette » Mon, Jun 08, 2009, 10:56 PM UTC

jmtulloss wrote: post #3

First of all, this is awesome. I am missing some details though. Are these true closures? What are the scoping rules? Can you read data declared outside of your block? Can you alter it? Is the only way to keep alterations safe to use a private queue? I guess time (or a closer reading) will tell.

More information about the implementation of blocks here: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/00267...

Re: Technology Brief for Apple's Grand Central Multicore Paradigm [pdf]

#8

Post by miratom » Tue, Jun 09, 2009, 12:54 AM UTC

A Job Queue is a great thing to have, especially when it provided for you, but it's hardly "revolutionary."

Re: Technology Brief for Apple's Grand Central Multicore Paradigm [pdf]

#9

Post by perneto » Tue, Jun 09, 2009, 1:29 AM UTC

This sounds inspired by SEDA (Staged Event-Driven Architecture). http://www.eecs.harvard.edu/~mdw/proj/seda/ It was about time someone made good use of it, too!

Is there more info available? The white paper is nice, but not too packed with detail.

Re: Technology Brief for Apple's Grand Central Multicore Paradigm [pdf]

#10

Post by agocke » Tue, Jun 09, 2009, 1:38 AM UTC

wmf wrote: post #6

agocke wrote: post #5

I wonder how this will affect the legacy methods of concurrency in OS X -- specifically POSIX threads. I know I wrote a number of C apps using POSIX threads that worked well in OS X and in Linux. While this is nice and interesting for Mac only programs, I hope that I don't have to rewrite my cross platform apps to take advantage of the API.

Obviously pthread support won't be removed; pthread programs just won't play as nice with each other as Grand Central programs.

Well I didn't really mean to suggest that it would be removed, mainly about what kind of performance hit I would take by using pthreads instead of Grand Central. In addition, how well will pthread programs and GC programs work together. Normally, the threading is handled by the scheduler in a straightforward model, but if the GC model modifies the scheduler model, I'm not really sure what the results will be.