Snow Leopard's Grand Central, Open CL boost app by 50% - Page 2

Originally Posted by cjones051073

Don't expect to see any improvement in handbrake due to these technologies.

Handbrake can already efficiently uses all cores on multicore machines since the x264 library it uses supports this. Has done for some time, long before Grand Central Dispatch came along. So nothing to gain there.

Moreover, the x264 devs have already looked into OpenCL/CUDA and (from memory) deduced there is not much they can gain from that. GPUs may well be fast but they have some serious limitations, and in the case of H264 encoding result in them not being ideal (note I said encoding, not decoding...)

Last and not least handbrake is multi-platform. They support linux and windows as well as OSX, so are unlikely to start a widespread rewrite for some new technology only available on one platform.

Chris

Originally Posted by cjones051073

Don't expect to see any improvement in handbrake due to these technologies.

Handbrake can already efficiently uses all cores on multicore machines since the x264 library it uses supports this. Has done for some time, long before Grand Central Dispatch came along. So nothing to gain there.

Moreover, the x264 devs have already looked into OpenCL/CUDA and (from memory) deduced there is not much they can gain from that. GPUs may well be fast but they have some serious limitations, and in the case of H264 encoding result in them not being ideal (note I said encoding, not decoding...)

Last and not least handbrake is multi-platform. They support linux and windows as well as OSX, so are unlikely to start a widespread rewrite for some new technology only available on one platform.

Chris

Originally Posted by solipsism

Yes, at least 7GB is real space that is freed up. Most of the additional is just a difference in reporting from binary to decimal depending on partition size, which is why you see reports of 20GB and more.

Originally Posted by brucep

6 GB IS SAVED except if you need to use rosatta the you save 3 g or less . The whole snowy purpose was to from the ground uo rebuild the new system
LEAN
MEAN
FAST

64BIT

lep is dead now
snowy is like OS9.2
The future needed a slim powerful snowy to move forward in our/apples brave new world ..

I may wrong here and there .

9

Originally Posted by backtomac

Nice post but are you sure HB wouldn't benefit from OCL and GCD?

Isn't video encoding a SIMD (same instruction multiple data) process? That's what OCL is supposed to shine at.

Wouldn't the fact that OCL and now GCD are open sourced encourage their adoption on the other platforms?

Originally Posted by backtomac

Nice post but are you sure HB wouldn't benefit from OCL and GCD?

Isn't video encoding a SIMD (same instruction multiple data) process? That's what OCL is supposed to shine at.

Wouldn't the fact that OCL and now GCD are open sourced encourage their adoption on the other platforms?

Originally Posted by addabox

True, but I'm curious about what GCD could do for Handbrake when Handbrake is competing for resources with other running processes.

My understanding is that one of the advantages of GCD is that it is system aware in a way that a given application cannot be, no matter how carefully coded for multicore optimization it may be, and allocates resources accordingly.

Originally Posted by cjones051073

From a post I read on the x264 list a while back were someone asked about CUDA. I forget the details but the general idea was they have taken a deep look into it and found it did not help in their particular case.

Originally Posted by backtomac

Wow, I'm surprised CUDA couldn't improve HB encoding. If that's true, then OCL which is very similar wouldn't help either.

I'm surprised.

Originally Posted by cjones051073

The main point of CGD is to help developers write multi-threaded applications. Writing good, robust multi-threaded applications is a serious undertaking and as such not one most devs would consider, unless (like x264) their code is a serious CPU user and as such big gains are possible by using all cores.

However, regardless of how a multi-threaded application is written, using GCD or not, at the end of the day the kernel just sees the threads. Its the kernels jobs to balance these threads between the cores, and I image it would do that just as well regardless of how the applications are written.

So, no, I doubt Handbrake/x264 would benefit in anyway from re-implementating its multi-threading to use CGD. At the end of the day, if you are utilising all your cores to 100%, then there is nothing left to gain ....

( Again, I am not a Handbrake or x264 dev, so the above is my personal opinion and in no way am I speaking for either Handbrake or x264. )

Let's say a program has a problem that can be split into eight separate, independent units of work. If this program then creates four threads on an eight-core machine, is this an example of creating too many or too few threads? Trick question! The answer is that it depends on what else is happening on the system.

If six of the eight cores are totally saturated doing some other work, then creating four threads will just require the OS to waste time rotating those four threads through the two available cores. But wait, what if the process that was saturating those six cores finishes? Now there are eight available cores but only four threads, leaving half the cores idle.

With the exception of programs that can reasonably expect to have the entire machine to themselves when they run, there's no way for a programmer to know ahead of time exactly how many threads he should create. Of the available cores on a particular machine, how many are in use? If more become available, how will my program know?

The bottom line is that the optimal number of threads to put in flight at any given time is best determined by a single, globally aware entity. In Snow Leopard, that entity is GCD. It will keep zero threads in its pool if there are no queues that have tasks to run. As tasks are dequeued, GCD will create and dole out threads in a way that optimizes the use of the available hardware. GCD knows how many cores the system has, and it knows how many threads are currently executing tasks. When a queue no longer needs a thread, it's returned to the pool where GCD can hand it out to another queue that has a task ready to be dequeued.

Originally Posted by Tauron

Windows 7 will now require 4 GB of RAM as a minimum and applications running on Windows 7 will use 30% more CPU cycles to keep it from crashing.

Originally Posted by applebook

I hope that you are joking because Windows 7 rarely uses over 1Gb on my 4Gb machine, and hardly more than 10% of each cores of my quad is under load even when watching 1080p.

Originally Posted by Cubert

Once again proving that Snow Leopard is more about positioning the Mac platform for the future than trying to drum up massive sales (which is happening anyway). And, I guess, it's also about "encouraging" people to upgrade their hardware, too.

Originally Posted by cjones051073

Don't expect to see any improvement in handbrake due to these technologies.

Handbrake can already efficiently uses all cores on multicore machines since the x264 library it uses supports this. Has done for some time, long before Grand Central Dispatch came along. So nothing to gain there.

Moreover, the x264 devs have already looked into OpenCL/CUDA and (from memory) deduced there is not much they can gain from that. GPUs may well be fast but they have some serious limitations, and in the case of H264 encoding result in them not being ideal (note I said encoding, not decoding...)

Chris

Originally Posted by manonthemove

Just so you guys know, a factor of 10-30 in performance is not uncommon for scientists who use CUDA. Given the similarities between OpenCL and CUDA, we should (hopefully) see a lot of improvement in the near future. Here is a link (http://sussi.megahost.dk/~frigaard/) to a standard piece of scientific code G2X (it does N-body calculations) modified to use CUDA by C. FRIGAARD (go to the bottom) which gets a factor of 30 for one subroutine and a factor of 10 overall.