Slashdot Mirror
Apple's Grand Central Dispatch Ported To FreeBSD
bonch writes "Apple's Grand Central Dispatch, which was recently open sourced, has been ported to FreeBSD and is planned to be included by default in FreeBSD 8.1. Also known as libdispatch, the API allows the use of function-based callbacks but will also support blocks if built using FreeBSD's clang compiler package. There's already discussion of modifying BSD's system tools to use the new technology." The port was originally unveiled last month at the 2009 Developer Summit in Cambridge. Slides from that presentation are available via the Dev Summit wiki.
Always taking from the open source community, and never giving back!
#DeleteChrome
Oh yes. Fanbois are already out?! They do it once, and Lo and Behold!!! THEY ALWAYS DO IT!!!
I noticed in their last slide they asked how to put closures into GCC. Why bother? Just use the Apple LLVM clang front end where it is already implemented and ditch GCC altogether.
My first question was "So...what does this do?" Apparently it is a more efficient way of scheduling threads on multi-core systems http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090903.pdf apple's site says this: "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. " So this seems good then.
So, basically this is a tool to streamline concurrent code on multi core machines? Did BSD not have something like this already?
now it can die in parallel, optimized for the number of cores and other system activity.
Do you even lift?
These aren't the 'roids you're looking for.
Netcraft confirms it: This joke is dying.
Package XYZ ported from Ubuntu to Debian!
Has anyone written a comparison of GCD, Intel Thread Building Blocks, and VC++ 2010's own task-based concurrency library?
GCD is a mechanism to let one central authority dispatch threads across multiple cores, for all running applications (including the OS).
The other two things you mentioned are ways for programs to more easily use multiple threads, but they are still threads under the main process and not centrally managed - so you have to decide blind how much of the system you can take for your threading needs.
You can compare the Blocks syntax to ways those two systems specify work units to be done in parallel, but that is just a part of the story.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
It's unclear that this buys you much over OpenMP 3.0. GCD gives you a little bit more flexibility, but that's not needed in many applications, and GCD is quite inconvenient without closures.
Grand Central is not introducing multithreading - it's introducing comprehensive thread management. So, how many threads are you going to spin for that task? Too many, and you waste a lot of time on thread management and preemption. Too few, and you have processors sitting idle. Now how will you handle this with multiple CPU's? Multiple cores? Hyperthreading? Different cache amounts and layout? OpenCL and GPU processing? Do you know what the rest of the operating system is doing to plan appropriately?
In short, your program can at best make a stab at these issues, and possibly even do a reasonable job if you put a lot of time, effort, and profiling into it. Or you could just use GCD, and let the framework handle it all for you, regardless of whether you're on a Core Solo Mac Mini or a Mac Pro with mutliple OpenCL graphics cards.
It's good stuff. And Apple gave it to the community (much like WebKit enhancements, launchd, etc).
I don't know what kind of crack I was on, but I suspect it was decaf.
Or you could just use GCD, and let the framework handle it all for you, regardless of whether you're on a Core Solo Mac Mini or a Mac Pro with mutliple OpenCL graphics cards.
I also think it's a great idea because it's a library. Meaning that if it is updated for speed, stability, etc. it can be incorporated automatically on the next compile. It probably won't benefit single cores at all, but when we start using octal cores this kind of software will be needed, and embraced.
Can someone explain how this is different from a normal OS with kernel level threads and not userland threads? What can this do that e.g. Windows threading, native posix threading (NPTL) in Linux, etc... Is this just apple "inventing" kernel level threads or is it something new?
er... isn't that what modern preemptive multi-tasking OSes already do?
Modern OS's move applications or (even threads) across different cores. But applications can have many threads, and the threads until now have been mostly managed by the applications themselves. The choice to spin off 10 or 100 threads? Up to the application. And that choice was made without the application being able to understand what choices other applications had made... the OS was left to manage as best it could with a large pile of threads, or sometimes apps with no threads that could just run on one core.
With GCD, instead you simply create as many threads as you like, and the central manager decides how many can be run across all the cores. The other part (Blocks) simply makes is easier to define the parts that can run off in separate threads, as noted that is more comparable to the other libraries because you want to encourage every app to have some parallel components. But the other approaches run back into the same problem that once you have defined the parts that can be run in parallel - how many threads should you spawn?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Frankly I think its a good thing. The BSD code tree is so old parts of it were rotting from the core. This may inject a vigorous new root into the tree. A sort of BSD for the 21st century perhaps.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
...It probably won't benefit single cores at all...
Actually, it should reduce management overhead for applications on a machine using a single core.
Meh..BSD isnt dead, pot smoking is good, and Linux is just for broke rejects who are mad cause they cant afford MS. Its hardly superior to anything, and the only reason it continues to thrive is because the developers make it easy for tards who need a GUI.
Do I understand it correctly if I oversimplify it as "centralized thread pool"?
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
The other often-overlooked advantage of GCD is that submitting work to a queue is thread-safe, queues themselves are lightweight, and queues can be made internally-serial but parallel to all other queues. Apple's documentation has a lot of good examples of how to use this structure to eliminate almost all locking code (which is usually pretty heavyweight). If you need to serialize access to a resource, just create a serial queue and any other queue can send tasks to it without worrying about any synchronization.
As someone who's struggled with performance from trying to determine how fine-grained to make locks, this seems like an awesome approach.
It has one, but it's not "just" one. For one thing, it's got an event model for creating and coalescing jobs to automatically schedule on a queue, for watching signals and I/O activity. There's more than that, too, like being able to create new queues, target them onto other queues and pause a queue for further execution.
Awesome! They have almost reinvented lexical closures, etc. In another ten years this will be as awesome as using continuations for UI navigation in a web framework, which was done yesterday.
Thanks goodness for the GPL, or we might never have convinced Apple to release its code so that FreeBSD could use it!
Wait... what is that? Oh, nevermind then...
Linux users tend to know how to pirate, so the cost argument doesn't really work. In fact, most people who have linux installed it over (or at least beside) an existing MS system.
it seems like the ability to share work across machines, not just cores, would be a critical difference.
Neither GCD nor OpenMP allow you to "share work across machines".
On their stolen computer next to all the other things they stole from school. They even steal the flies from outside who swarm around their unwashed bodies. linux is the devolvement of humanity - a linux user is like an anti-human - taking the opposite form of what a real human should be. They do not know how to reproduce, they cannot interact with others and they long ago forgot the concept of personal hygiene. They believe communism is something we should strive for and believe klingon is a real language. yes... we know of your type.
does he get derivative works?
i could not have said it better myself. well done brother.
I also think it's a great idea because it's a library. Meaning that if it is updated for speed, stability, etc. it can be incorporated automatically on the next compile.
Or, if you're dynamically linked with the library containing it, incorporated automatically when the library is replaced, with no recompilation needed.
(Yes, I know, automatically picking up improvements and automatically picking up shiny new bugs are both enabled by dynamic linking.)
If you're creating a serial queue anyway, you no longer have parallelism. If you have multiple serial queues, you may as well have had multiple threads with no interlocking between them. This is just yet another API to do what competent parallel system programmers have been doing since the first thread.
Sam ty sig.
Similar to how iphone was the first real phone, this is the first real threading supergoo invented evaar!! Wasn't the name of Apple a dead giveaway already??
Don't you dare compare me to the parent.. he is certainly no commie...
Tobias Ussing http://www.nearby.dk
It doesn't even support the full C++ specification. Why are people moving to clang?
The "central management of OS threads" is marketing speak for a N-M scheduler with an OS wide limit on the number of heavyweight threads
True enough, but it is the part that differentiates GCD from the other frameworks and thus deserved the most explanation.
This is only useful because OS X has horrendous per-thread overhead.
Actually it's useful because threads on all platforms have overhead, which is why the reuse of them by GCD to run these lightweight blocks matters. It's why it's being integrated into BSD.
The interesting part of GCD is blocks and tasks, and it is useful to the extent which it makes expressing parallelism more convenient to the programmer.
That is true and what makes it likely we'll see many apps actually take advantage of this where we haven't seen that many apps even bother to thread much before. Frankly even though it will not help with performance (because there is no GCD) I'm excited to have blocks (closures) on the iPhone.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
It's a win/win, but the mini-Stallmans will never see it that way.
To the contrary: I am a huge fan of Stallman's philosophy and see Apple's work as win/win.
The people that are complaining are the looney Apple Haters, who try and find any point possible by which to attack Apple - never realizing until it is to late the latest position they are attacking from makes no sense.
Please do not taint all those of us who respect the GPL with the same brush the Haters paint themselves in corners with.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
This is just yet another API to do what competent parallel system programmers have been doing since the first thread.
RTFM, and learn what you're missing.
The point of GCD is that taking advantage of multiple cores becomes much less work. When I say "much less", thinks minutes versus days. Besides the ease of use, the underlying implementation also deals with scaling the queues across the number of available cores on the fly, and makes the management of serial dependencies trivial.
Another benefit of GCD over managing the threads yourself is performance. Apple changed the implementation of Objective-C's garbage collector from running on a dedicated thread to running in GCD, and picked up a double-digit improvement in the speed of memory recovery.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Apparently it is a more efficient way of scheduling threads on multi-core systems ...
...So this seems good then.
duh!
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*
Oh REAAAAALLLY?
If you mod me down, I shall become more powerful than you could possibly imagine.
Apple isn't "sticking with GPLv2" so much as "actively working to replace every last scrap of GPLvn code with BSD/MIT/Apache code." They appear to be under the impression that GPL is unfriendly to business, which impression is defensible. They are investing many programmer years in Clang/LLVM, and soon enough will be liberated from the tyranny of gcc.
If you mod me down, I shall become more powerful than you could possibly imagine.
Queues and threads aren't the same thing. The framework manages the size of the thread pool based on the current system state, and queues are assigned to threads automatically. Not only do you avoid expensive thread creation, but you also get an optimal number of threads for the system you're running on.
You obviously don't know what GCD is or why it was created and didn't bother doing any reading on it before posting.
Well a GCD queue also has overhead, right? The OP is correct - on systems that get threading right (ie not OS X) if you have 200 tasks that can run in parallel, the easiest way forward is to create 200 threads.
When might you not want to do this? One is if each task has a large associated memory overhead so you don't want the data for every task to be in memory at once. In that case maybe you want fewer threads, and a controller thread that loads data and keeps the thread pool queue long enough that it never stalls but short enough that you use minimal memory.
Another situation is when a thread is very expensive. This is not true on Linux (at least if you're careful with stack size) and used to be true on Windows but I believe has been improved over time.
Another situation is where the tasks aren't available all at once. This is just a variant of the first scenario.
The final one is when a task blocks, eg, reading from disk. In that case you might want a very large number of threads in order to keep the CPUs busy and not waiting around on disk.
This is exactly what many SIMULA-systems did under the hood. Except SIMULA hid the dirty details better and the language worked on systems that didn't support a "Grand Central Dispatch" (there is even an really inefficient and awfull SIMULA to C compiler).
I've never programmed in PLANC (the system programming language used by Norsk Data and, as far as I know, the first hardware independent system programming language), but, as I recall, it had similar, if not identical, language constructs as those devised by apple.
Me think US corporations should start looking at the world around them and stop reinventing things already invented. They would save a lot of money and effort.
This is between one and two orders of magnitude more expensive than adding a block to a work queue with GCD.
Switching between the threads is also relatively expensive. At the very least, you need to save all of the registers and update the stack pointer (probably in response to a timer interrupt, so also factor in the cost of a transition from kernel space to users pace). With GCD, the kernel will give you one thread per CPU for each priority level (or fewer if there are already lots of CPU-bound threads), so you minimise number of context switches.
This is effectively what an N:M scheduler does, but is slightly better. With an N:M scheduler, you are switching between some threads in userspace, which saves some overhead, but the threads still have largely-disjoint working sets and so you end up with more cache churn (performance killer on modern CPUs). With GCD, you will only be switching between work queues in a given thread between blocks, so there is no cache churn (the old block's cache lines are no longer needed, so you'll kick them out but not then bring them back in immediately). The other nice side effect of this is that, because GCD knows which work queues are assigned to which threads, it can remove locks used for passing messages between work queues if both queues are in the same threads.
In short, it's an N:M threading model with preemptive kernel threads and cooperative userspace threads. If you read an OS textbook, you'll see that this is, at least in theory, about the most efficient scheduling model possible.
I am TheRaven on Soylent News
Welcome TO Our Website: Http://www.tntshoes.com
we are a prefession online store, you can see more photos and price in our website which is show in the photos
please email me by: www.shopperstrade@hotmail.com
lv Handbags , dior, D&G channell coach etc $23-32 free shipping.the name of our website is in the photos blow is our website, hellow we are a online fasion shopping mall"
OUR WEBSITE:
YAHOO:shoppertrade@yahoo.com.cn
MSN:shoppertrade@hotmail.com
Http://www.tntshoes.com
On one hand, FreeBSD is leading the way in adopting cool technology - ZFS, DTrace, PF, and now GDC.
But, they still do not have a UVC driver, and the 70's installer technology still craps out on some platforms.
So, on the server, it rules, but on the desktop/laptop, well, it kinda blows.
Ars Technica has a great explanation on Grand Central Dispatch (GCD), and how LLVM and OpenCL fits into the grand scheme of things:
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars
Note: all links from same article, which is 23 proper pages long (not 5 line jobs).
Jumpstart the tartan drive.
See this page on Ars Technica for an explanation: http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12
Jumpstart the tartan drive.
Not quite true. Each serial queue runs in parallel with respect to *other* serial queues. GCD also reserves for itself the right to schedule items from different serial queues on multiple threads or the same thread, should the work be done quickly and a thread become free again. That can be a fairly significant optimization, since you don't need to trap into the kernel (e.g. sleep waiting for more work) if all you're doing is chaining between multiple items of non-blocking work in userland and can detect when there's more work queued up and ready to run. Trapping into the kernel is expensive, and GCD goes to a lot of trouble (both with work scheduling and GCD objects like semaphores) to avoid it, if such is an available optimization (and there are cases where it is, and is not, so it's nice to have something else worrying about those details for you).
when we start using octal cores
High end workstations are already shipping with dual quad (8 cores total) and will probablly be shipping with dual hex (12 cores total) in the not too distant future. Quad core is fairly common in the midrange and is even available on some fairly low end machines (e.g. the dell vostro 420). Laptops and low end desktops are generally shipping with dual cores.
With the exception of nettops and netbooks single cores are pretty much history.
The bottom line is that cores aren't getting that much faster so most of our gains in computing power are likely to come from more cores and software that needs to get the most out of CPUs is going to need to embrace that and soon.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Welcome to our website: Http://www.tntshoes.com
We can supply women shoes, brand shoe, safety shoe, clothes, sports products, craftwork and electronic products.
(1) Material:100% authentic leather
(2) High quality sports shoes with reasonable prices
(3) Small trial orders accepted
(4) With original box,
(5) Size: US 8-13, Euro 41-47
(6) Inner packing:1cardoard box
We have various styles sport shoes on the company website. If you ask for details,
please visit our website or contact us directly
OUR WEBSITE:
YAHOO:shoppertrade@yahoo.com.cn
MSN:shoppertrade@hotmail.com