Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

BornAgainMac

macrumors 604
Original poster
Feb 4, 2004
7,418
5,511
Florida Resident
Now that Snow Leopard has been out for some time will Grand Central Dispatch ever be used by apps such as Final Cut or Handbrake type apps? Seems like it is a feature that sounded good on paper but developers never really jumped on it.

Was this feature ever used?
 
Maybe the next version of Final Cut will have better multicore support, at least it's needed. I think HandBrake supports multiple cores pretty well already
 
Handbrake gets a full 200% out of my C2D processor already. I’m not sure if it uses Grand Central or not, but regardless, it has great multicore support.
 
I agree that Handbrake doesn't need it and they have a Windows version so it makes sense to do their own thing. I am just surprised for new startup applications are written to take advantage of this feature. It would seem it will remain for custom scientific apps using Xcode than for any mainstream apps.
 
I am a very beginner Objective-C programmer (or programmer in general), so just ignore this if it is idiotic.

How hard is it to build in multicore capability yourself vs building an app that lets the OS handle it with Grand Central?
 
Now that Snow Leopard has been out for some time will Grand Central Dispatch ever be used by apps such as Final Cut or Handbrake type apps? Seems like it is a feature that sounded good on paper but developers never really jumped on it.

Was this feature ever used?

splitting your code into blocks that can be executed asynchronously is complicated. the more the bigger the project is. some apps get GCD for free though if they used NSOperation to do multitasking before.


I agree that Handbrake doesn't need it and they have a Windows version so it makes sense to do their own thing. I am just surprised for new startup applications are written to take advantage of this feature. It would seem it will remain for custom scientific apps using Xcode than for any mainstream apps.

For newer apps that I develop I use GCD. But touching older already multithreaded code that works is not a priority for me as it was a lot of work to get the code working in the first place :p

Also old school multithreading is not equal to gcd ... you can't just convert old threads to gcd blocks and expect them to work out of the shelf. The transition to gcd will come but it will last a little while till every app uses it. I believe GCD is one of the few ways to write code for multicore machines without getting totally insane :)
 
How hard is it to build in multicore capability yourself vs building an app that lets the OS handle it with Grand Central?

Uh, it's a pain. You have to know how many cores there are in the system and scale appropriately. You must handle thread queueing yourself - knowing always how much work each cores is doing and will be doing in the next few moments and dispatch new threads to the appropriate core. (You can even be fancy and move threads from one core to another if the another one is less busy - that's what GCD does too.)

And still you wouldn't get anywhere near GCD's performance and elegance as GCD is a part of the OS and has access to the kernel space to pull all needed information.

Just use GCD - you still have to worry about the problems of multi threaded programming like data access synchronization and such nice things that can drive you totally insane.

For the beginning look at NSOperation. It's a nice encapsulation of a thread - you just have to subclass NSOperation and implement -()main: where you do all the fancy work.

And it has a huge advantage: On OS X <= 10.5 it will use "old" pthreads and on 10.6+ it will use GCD so it is backwards compatible if your app needs to run on older OS X.
 
if handbrake does such a nice job of ‘manually’ implementing multicore/thread capability, I wonder why the windows version is so terrible.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.