Apple's Grand Central Dispatch Ported To FreeBSD 205
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.
Re:Apple's Grand Central Dispatch Ported To FreeBS (Score:2, Insightful)
Netcraft confirms it: This joke is dying.
Re:Multicore Enhancements!! :) (Score:5, Insightful)
GCD is far more encompassing than just spawning threads. It's mainly a library for task-based parallelization (my wording, not theirs) and has some other goodies in it as well.
For starters, unless it's not apparent by now, just spawning a new thread to run every such job is too heavy. Scheduling a new GCD job (and all of them will get run on one of a bunch of thread pool threads) is on the range of tens of CPU instructions; on Mac OS X, where GCD originated, spawning a new thread steals away in the vicinity of one megabyte (I can't seem to find an exact number) just for various bookkeeping. That's a lot of setup; even if there's a lot of fat to cut there, the best solution is probably not to spawn a new thread every time.
The API is also very neatly designed. Tasks can be created and added to groups or queues and run synchronously or asynchronously. Semaphores, queues and event sources (which will trigger the addition of an event handler to a queue automatically) can all be paused and resumed to more easily control the flow. Neat, especially combined with the creation of queues that you set up to just funnel work onto another queue.
Add to that the existence of several global queues with varying priorities (corresponding to a set of worker threads at each priority) and the potential for smarts for a system that can see the entire picture with regards to load within the program and across the system. I don't know the extent to which such smarts exist already, but I think you'll agree that with more metadata available, such a scheduler would be better equipped than one fiddling with coarser-grained threads.
So yeah, this is nothing like "just" spawning threads. (I've never worked directly with pthread; it may very well reuse threads, but it didn't look like it from the man page you referred to.) None of it, as far as I can tell, is Apple inventing something new and breakthrough, but it's still a damn good API with a good consolidated set of computationally cheap features whose level of abstraction solves problems.
Re:No because they are different (Score:3, Insightful)
GCD is a mechanism to let one central authority dispatch threads across multiple cores, for all running applications (including the OS).
er... isn't that what modern preemptive multi-tasking OSes already do?
Sort of, but GCD is about what application developers can do. Using current development methods the average developer decides how many threads to spawn and the OS tries to give them all equal priority. Further if you break your app into too many threads performance drops because of management issues. If you break it into fewer threads than there are cores, cores sit idle.
GCD lets app developers break up their app into chunks that can be threads or can be the same thread and let the OS decide how far to break it up and what to send to what core and what to send to the GPU. It basically lets developers who use good practices fire and forget apps and not have to really worry about profiling and optimization for cores.
Re:Apple's Grand Central Dispatch Ported To FreeBS (Score:1, Insightful)
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.
Re:Multicore Enhancements!! :) (Score:5, Insightful)
Maybe someday we can actually have a modern desktop as responsive as BeOS was...
BeOS was indeed very responsive, but it was also notoriously difficult to program for. Apple seems to have done a great job at creating a powerful framework, while keeping it easy enough to be actually used by the developers.
Re:Multicore Enhancements!! :) (Score:5, Insightful)
Been there, done that on Solaris and Linux 10 years ago in plain old C. No magic required, just
and away you go.
Piece of cake! Of course, you have no idea how many other processes are tossing threads at their workload and so have no idea if this is a great time to spawn another 8 to really load out the CPU or whether you should just spawn 2 and let some other processes have their time. That's what GCD buys you.
Re:No because they are different (Score:3, Insightful)
It seems to solve the problem of what happens when you've got too much work for each processor is to make things more fine grained. Lots of tiny tasks spread around a few threads on just the right number of processors, rather than lots of threads. You've essentially just got a scheduling problem, you can have an academic career doing this stuff. Figuring out which sets of tasks have priority over others is not that much different than figuring out which applications threads have priority over other threads (ie, is the app with 6 threads more important than the one with 4 threads if you've only got 8 processors).
Splitting threads into smaller chunks, if you can rearrange your app structure is one approach to this. Your long running threads that talk to each other are now split into smaller units that talk to each other, only you've got more ways to arrange them. Essentially you're going from very coarse grained parallelism to a finer grained parallelism. which gives more flexibility. But people have been doing this stuff and dealing with its problems for decades. You run into the dusty deck problem again, only in a more modern context. Ie, you tell customers you can speed up their code on your parallel machine and compiler by a factor of X, only they have to rewrite things somewhat, and most customers find that too difficult or their algorithm isn't easily parallelized.
Re:GCD also replaces most synchronization / lockin (Score:3, Insightful)
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.
Re:No. Really? (Score:5, Insightful)
Re:Multicore Enhancements!! :) (Score:3, Insightful)
So does Linux need that, do they think about implementing something similar, porting it or what is happening?
Re:No. Really? (Score:4, Insightful)
When is the last time that Apple released an entirely new project? For example Sun released ZFS under the CDDL.
Why reinvent the wheel? They adopt it, improve it and release the improvements. At least they add. They deliver. When is the last time Stallman released an entirely new project? Or finished one? "Although nearly all components have been completed long ago and have been in production use for a decade or more, its official kernel, GNU Hurd, is incomplete and not all GNU components work with it." from the reliable-as-ever Wikipedia. Apple is not Stallman. They do not serve the same market. Apple is in hardware/software/platform, Stallman is in philosophy. Fair enough, einen Unterschied muß es geben.
Comment removed (Score:3, Insightful)
Re:No. Really? (Score:4, Insightful)
Well, we have the subject of this article, Grand Central Dispatch. We also have Darwin & XNU, their version of the Mach kernel. There is also Bonjour, their version of zeroconf, and their streaming server (Quicktime Streaming Server). They also purchased the source to gimp-print (now called Gutenprint) so they no longer have any obligation to keep it open source, but they do, and they keep releasing the source. How much more do you need?
Re:No. Really? (Score:3, Insightful)
In the mean time... When is the last time that Apple released an entirely new project?
You do realise this article is *about* apple releasing the source code to libdispatch?
Re:GCD is not multithreading, it's thread manageme (Score:3, Insightful)
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.