Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Grand Central Dispatch and Open CL Bring Significant Performance Improvements for Optimized Applications
- Thread starter MacRumors
- Start date
- Sort by reaction score
Yes Handbrake is just a graphical shell for ffmpeg. All it does is collect some data from a few dialog boxes and radio buttons then pass off all the real work to ffmpeg.
You will have to wait until Grand central and Open CL are adopted by Linux and then the developers will modify ffmpeg. Likely it will take a couple years at least.
But this is all open source so you all can help if you want. What a Grand Central baded ffmeg? Anyone can build one if they like. No need to wait for others to do the work for you. If yuo lackthe skils then maybe you can pay someone to do the work or buy a Mac and give it to a developer
Let's be clear here, Grand Central Dispatch does not bring any performance improvements. It is just a library to simplify threading for some who might not otherwise do multi-threaded programming. It's the multi-threading that brings the performance improvements.
Similarly, OpenCL doesn't bring performance improvements, it's just a language that simplifies being able to run code on a GPU, which is probably difficult to do in a cross GPU way otherwise. But it's running code on the GPU that brings the performance improvement.
Also, since the article compares Leopard to Snow Leopard, it's difficult to tell if all the performance improvements are due to multi-threading and pushing code off onto the GPU. Why didn't they just run the non-GCD, non-OpenCL code on Snow Leopard rather than Leopard to compare? The article also makes some strange statement about decoding being more GPU intensive than encoding??? My understanding was that MPEG encoding is almost always more processor intensive. For that matter, how do you get a 165% CPU load???
Similarly, OpenCL doesn't bring performance improvements, it's just a language that simplifies being able to run code on a GPU, which is probably difficult to do in a cross GPU way otherwise. But it's running code on the GPU that brings the performance improvement.
Also, since the article compares Leopard to Snow Leopard, it's difficult to tell if all the performance improvements are due to multi-threading and pushing code off onto the GPU. Why didn't they just run the non-GCD, non-OpenCL code on Snow Leopard rather than Leopard to compare? The article also makes some strange statement about decoding being more GPU intensive than encoding??? My understanding was that MPEG encoding is almost always more processor intensive. For that matter, how do you get a 165% CPU load???
Given that ffmpeg is LGPL code and apparently that's what the folks cited in this article were modifying, they will probably need to make the code available. So, a version of the work is already done.
100% = 1 core, so in this case with the quad core MP you could have up to 400% CPU usage. The GCD optimized version was using 30% more CPU (two cores instead of one) which is why the encoding was faster.
And the decoding isn't move intensive *overall* than the encoding, it's that the GPU was able to take more of the processing load for decoding (the GPU would be surely better at decoding than encoding).
Open GL/Grand Central optimization is fine, however such improvement are probably an advantage of, what, 20% of the users?
I've been holding on SL upgrade, so far. I've been actually reading of more complains than positive comments.
I'd much prefer to see improved overall conditions, increased battery life for laptops, etc.
I've been holding on SL upgrade, so far. I've been actually reading of more complains than positive comments.
I'd much prefer to see improved overall conditions, increased battery life for laptops, etc.
Wrong. All applications written for SL will take advantage of GCD when the 3rd party dev steps up and implements it. To see OpenOffice and MS Office re-written to leverage GCD and benefit drastically from blocks by leveraging unused CPU cores would bring random comments of ``everything is so fast and snaps when I make a change to my document, my 10,000 x 100 spreadsheet, to my ability to connect to database sources and scale up, etc.''
iLife will take full advantage of both.
OpenCL is being taken advantage of at the low-level presently.
Any application [including all of iWorks] can leverage OpenCL for it's offloading of number crunching, aiding Quartz in various aspects to streamlining processes for WebKit and thus give everyone an improved experience. Built-in SVG, WebGL for Opera, Firefox, Safari, Chrome, etc., will benefit on OS X.
The impact for an application like Keynote will be more visible the more Keynote expands into OpenGL presentations that include interactive fly-throughs and much more.
Any application that takes external data sources and requires numerical analysis of numbers, pattern matching, etc., will take advantage of it.
It's all dependent upon the developers time, vision and goals of their applications.
All games take advantage of it because of the instant dependency of the environment to sap the life out of a CPU(s).
Any Graphics Editor, Flash editor, SVG editor, multimedia suite, Audio/Video application can immediately leverage both but will require re-architecting portions of the code to make it happen.
It's not unreasonable to expect 6-9 months before major vendors bring out new versions leveraging both with considerable peformance improvements while reducing overhead to reach those aims.
Even a 2 Core system isn't being leveraged efficiently until the advent of SL to the market for Macs.
So far with no apps using 10.6 & many times my current apps seem to run slower on my 1st gen 3 GHz Intel Mac Pro with dual ATI 3870 video cards, there is little incentive to change our OS. Maybe there will be by time we are up to 10.6.6 or so. By then the new bugs caused by going to 10.6 from 10.5.8 will be worked out.
So far I usually run 10.6.1 for an hour or 2 each day. I don't do any mission critical work as of yet. Like many I do not trust updates. Also why suffer the risk if things are not doing anything new or faster.
OS 10.6 Snow Leopard has to be a very small money deal for Apple. Before they got $129 per updated Mac with all PPC & Intel Macs available. Now they get $29 per updated Intel only Macs. This is a much smaller amount & a much smaller market. Was 10.6 written because Apple is now copying Microsoft. Remember when Apple went to OS X MS just came out with a new version of MS Office, Office X for Mac, which was just a change from System 9 to OS X code. OS 10.6 cut out all of the PPC Users & changed some of the OS to 64 bit. Now with the few new items no one got on the band wagon early with Apps for the new or updated features in OS 10.6.
Or is this slowness to change because Apple developers can see that most of Apple's work is on the iPhone so they are being very slow to work on programs for a system that the system maker is being laxs at having emphasis on this system.
When we we see these features used? That is probably why Apple took PPC support out. This is as by time these features are used most PPC Macs & 1st & 2nd gen Intel Macs are too old to move those recycled electrons around in a useful pattern.
I have OS 10.6 but I really don't use it. How many other OS 10.6 purchasers are like this?
So far I usually run 10.6.1 for an hour or 2 each day. I don't do any mission critical work as of yet. Like many I do not trust updates. Also why suffer the risk if things are not doing anything new or faster.
OS 10.6 Snow Leopard has to be a very small money deal for Apple. Before they got $129 per updated Mac with all PPC & Intel Macs available. Now they get $29 per updated Intel only Macs. This is a much smaller amount & a much smaller market. Was 10.6 written because Apple is now copying Microsoft. Remember when Apple went to OS X MS just came out with a new version of MS Office, Office X for Mac, which was just a change from System 9 to OS X code. OS 10.6 cut out all of the PPC Users & changed some of the OS to 64 bit. Now with the few new items no one got on the band wagon early with Apps for the new or updated features in OS 10.6.
Or is this slowness to change because Apple developers can see that most of Apple's work is on the iPhone so they are being very slow to work on programs for a system that the system maker is being laxs at having emphasis on this system.
When we we see these features used? That is probably why Apple took PPC support out. This is as by time these features are used most PPC Macs & 1st & 2nd gen Intel Macs are too old to move those recycled electrons around in a useful pattern.
I have OS 10.6 but I really don't use it. How many other OS 10.6 purchasers are like this?
My MacPro is one of those that can not boot to the 64 bit Kernal... but still runs 64 bit apps.. like LightRoom. Does this mean it can not take advantage of these advancements?
Not OpenCL as in my MacPro's case, the ATI X1900 XT isn't supported.
You need to have a specific card for OpenCL to be used
Please do tell.
I got nearly double performance from Handbrake clock for clock moving from a 2.4 GHz Core 2 Duo to Quad. Here's the shocker under Windows XP.
I don't see how you can tell me that Core 2 wasn't being leveraged until Snow Leopard. I'm not coughing up for a Mac Pro but I know that Core 2 is at its limits for what I do.
Here's another shocker for you. The Nehalem platform takes single vs. dual vs. quad into account with Turbo Boost.
Heh! The guy has (almost) the same rig is me (see my sig) but I have 2x his cores
I like handbrake but I'm not married to it. If there was another application out there (even paid, but reasonably priced) which could nab me 50-100%% gains I'd be all over it.
It would be nice but adding cores doesn't necessarily translate to a linear gain.
Mail.app was the poster child on WWDC for use of GCD and that's pretty much a run-of-the-mill app if you ask me. Many applications can be made to use better threading, certainly all apps that are communicating with other services, such as networking.
There is so much wrong with this post that I don't know where to start. Do you honestly think applications like Office do not already use threads where they are useful? Why in the world would I do OpenCL for 3D when I have OpenGL???
There's quite a bit of overhead running a 32-bit plug-in in 64-bit Safari.
Apple or Adobe are going to need to provide a new plug-in or run Safari in 32-bit mode for now.
Thanks, but my point was that the article was poorly written, and provides inadequate info with an inadequate analysis.100% = 1 core, so in this case with the quad core MP you could have up to 400% CPU usage. The GCD optimized version was using 30% more CPU (two cores instead of one) which is why the encoding was faster.
And the decoding isn't move intensive *overall* than the encoding, it's that the GPU was able to take more of the processing load for decoding (the GPU would be surely better at decoding than encoding).
I really really want an optimized HandBrake. Flash too. There's no good reason that my roommate's POS Dell should handle flash better than my MBP.
Not surprised! HB is a bit of special case, in that it can actually make use of your computer. Many of the libraries it uses, such as x264, are already coded rather well for multicore machines. It is not a typical application, in that respect, and I don't think I'm wrong to say that GCD is relatively irrelevant to it under normal circumstances. OpenCL would probably be a huge boon, but implementing it is entirely non-trivial and would have to happen in the libraries, not HB itself.
GCD/OpenCL are not magic bullets for performance. OpenCL is only useful in specific cases, and requires substantial changes to code. GCD makes writing apps which make use of multiple cores, like Handbrake, much easier, but it won't suddenly make all your existing apps fly.
GCD is like a quick-reference guide to help you easily get full marks on your Performance homework, and OpenCL is a special extra-credit assignment that's not for everyone. They're not going to hack into the school database and retroactively change all your grades.
Um...
I agree. People are acting like developers have never thought about threads before. GCD makes creating and managing threads easier (also keeps a program from stepping all over the toes of another program when it comes to threads), but it will not suddenly make non-threadable programs threadable or make developers good and programming with threads and shared resources. To start, there has to be work that can run in parallel in the program. The standard GUI program of click, wait for response, click again doesn't have very much that can be useful for threads.
The big win comes in tasks like encoding/decoding. In those cases developers have already been using threads for a very long time, but they have probably been conservative on the number of threads created (too few and you don't use the procs, too many and context switching kills you). Now they can request all they want and let GCD manage how many threads to create dynamically based on the system the code is executing on.
Thing is, GCD can actually have an impact even if the most trivial seeming app is converted to use it. The more apps you're running that use GCD rather than their own thread-management, the snappier your system ought to be overall, as GCD will be keeping the number of threads at as optimal a level as possible, rather than machines losing time to threads that barely do anything.
Which is pretty much the expectations that I have for GCD. I'm just wondering how much of an impact it will have on Apple's dual core or break the bank environment.
Quad cores or even 4 cores, 8 threads aren't that hard to get unless you're buying a Mac. I brought this up before but how much more points can we squeeze out of a dual core today? Snow Leopard would be better off outside of Apple's homogenous nearly pure dual core environment.