Applications using Grand Central Dispatch and OpenCL

Discussion in 'Mac Programming' started by micm, Jul 16, 2010.

  1. micm macrumors newbie

    Jun 30, 2010
    [I'm turning this thread here from Mac Applications, as it seems more appropriate.]

    Hello folks,

    When Snow Leopard came out last year, Apple made marketing out of the fact of having no new features. Arstechnica wrote a splendid review praising the potential of the two new core technologies it brought, and the perspective performance improvements coming from them.

    The "radically new development paradigm" was promising for a slower deployment, but I though it would have been compensated by the advantages in speed and code maintainability.

    So I've been periodically sampling the Internet for news on either technology. I expected lists of applications employing them, or some visibility on existing apps directories (like "GCD" or "OCL" tags). In lack of these I then resorted to expecting some random block posts from developers, but even of this I find very little.

    The most material you find from Robert Watson, concerning applications at the FreeBSD project!

    So what happened to these technologies under the Mac? Did they pass ignored by Mac Developers? If so, why? If not, why do they not reflect publicly the same excitement that the competent Ars masters showed?

  2. Cromulent macrumors 603


    Oct 2, 2006
    The Land of Hope and Glory
    OpenCL is a pretty specialised technology. You can't just speed anything up with it. You need to have an algorithm that can be easily parallelised. Plus it only really works well for single precision floating point calculations. Video codecs would be the first thing I would expect to see make use of it, but as most codec software is cross platform (libx264 for example) they might be waiting for better support on Linux and Windows before making the leap.

    Basically, just because the technology is available does not mean that every program is instantly going to start making use of it. OpenCL is probably not suitable for most programs.

    As for GCD I imagine that new development will start making a shift towards it although frankly it is just a higher level abstraction for something which software has been doing for years so as a user you are unlikely to see much of an improvement unless it helps developers write code with fewer bugs (a probable outcome).
  3. misee macrumors member

    Jul 4, 2010
    If you use technologies as GCD and OpenCL, your program will only run on Mac OS X 10.6 and above. So it is also a decision of whether you want to target older systems or not. Also, apps usually won't advertise that they are using GCD or OpenCL, since the average user won't know what these technologies are.
    But don't worry, I think most developers saw the changes and will also start using them where it makes sense. But rewriting existing applications to use new technologies isn't always as easy as one might imagine. Plus, you can always introduce new bugs, and debugging multithreaded applications isn't one of my favorite activities.
  4. pilotError macrumors 68020


    Apr 12, 2006
    Long Island
    Using Pthreads, the code is more portable to other platforms. If you know what your doing GCD And OpenCL don't gain you anything.

    The only advantage is getting to use the GPU without resorting to CUDA.

    Do any of the Mac GPU's support the OpenCL yet? I haven't heard much about it at all.
  5. wrldwzrd89 macrumors G5


    Jun 6, 2003
    Solon, OH
    Yes, the nVidia 9400M and stronger GPUs definitely have the muscle to put OpenCL to use. Alas, my iMac has an ATI Radeon 2600 PRO, which is just below the cutoff. Oh well.
  6. misee macrumors member

    Jul 4, 2010
    Isn't CUDA only for NVIDIA GPUs, while OpenCL can be used for all CPUs/GPUs that are supported? I don't know much about CUDA, OpenCL & co., so I might be mistaken...
    As far as I know, all newer GPUs should be able to use OpenCL. This is a list of supported GPUs from september 2009, I didn't find anything newer:
    • NVIDIA Geforce 8600M GT
    • GeForce 8800 GT
    • GeForce 8800 GTS
    • Geforce 9400M
    • GeForce 9600M GT
    • GeForce GT 120
    • GeForce GT 130
    • ATI Radeon 4850
    • Radeon 4870
  7. Catfish_Man macrumors 68030


    Sep 13, 2001
    Portland, OR
    Any app using Core Image uses OpenCL under the hood. Any app using NSOperationQueue (or a number of other APIs, actually), uses GCD under the hood.
  8. gnasher729 macrumors P6


    Nov 25, 2005
    This is for questions about how to write Mac applications. So if you can't get GCD to work properly, ask. But frankly, your question requires a major discourse into the way that commercial software development works, and I am not willing to do that here.

    Executive summary: Introducing major paradigm shifts like OpenCL and GCD will affect major applications several years after the introduction. User's will benefit when they have completely forgotten about it.
  9. mfram macrumors 65816

    Jan 23, 2010
    San Diego, CA USA
    I wrote a Mandelbrot generation app for the Mac because I wanted to try the OpenCL and GCD functionality in Snow Leopard. Also, I wanted the experience writing my first Mac app. :) Mandelbrot sets can be computed in parallel very easily using the classic algorithm so it lends itself to try these "new" technologies.

    Of the two, I found GCD more useful in a new app. It isn't really revolutionary. Apple just took a standard threading paradigm and filled in a lot of the mundane work for the programmer. Makes is much easier to use little execution blocks because they've done all the queuing and dispatch work for you. For new apps, it saves the programmer time. For existing apps which have already implementing their threading model, it doesn't make sense to use GCD because that work has already been done. Maybe if they extended it more for remote (distributed) execution, then it might make sense to re-implement an app using it.

    OpenCL is in a very rough state right now. Not a lot of quality documentation. And where it is documented there's a whole bunch of "this isn't implemented yet" notes in it. I had to do a lot of trial and error to get the OpenCL to work in my app. Several times when I made mistakes in the code it caused my entire graphics card to lock up requiring me to uncleanly power off the laptop to get it to come back again. Once I got my app working in OpenCL, it wasn't significantly faster than the main CPU on my algorithm. There really isn't any good reason to use it in my app. Yeah, it can do a lot of work in parallel, but it takes a lot to set up that parallel execution, cutting away the speed gains. I'm sure there are probably better ways to do what I wanted in OpenCL, but I couldn't get any huge performance increases from it in my app.

    From an end-user perspective none of this matters. The OpenCL and GCD "features" don't really do anything for end users. Only programmers looking for a performance and/or time-to-market efficiency increase on their apps.
  10. grero macrumors newbie

    May 10, 2011
    Hi all,
    My first post on the forum. I just wanted to add my two cents to the discussion. I've also been trying out both GCD and OpenCL and I found GCD to be the most useful of the two. As far as I understand, GCD is quite similar to OpenMP both in function and amount of coding needed to get it working, so the incentive to use GCD over OpenMP is perhaps not that great.
    One benefit I see to learning OpenCL is when it is used in conjunction with OpenGL. Since OpenCL allows you to perform computations on the GPU, there is no need to copy data back and forth between GPU and CPU, which could potentially speed up things like data visualization. I agree that documentation on how to do this could be better. There is some sample code provided with xcode, though, which I found to be quite useful.
  11. larkost macrumors 6502a

    Oct 13, 2007
    The thing you are missing here is that in order for pthreads code to work as well as GCD code, the programmer has to have anticipated the properties of the computer it is running on. Not only how many cores, but how many are available at that particular moment to do work (i.e.: are not working on something else). Since the GCD system is worked into the OS, it can vary the workload across cores when they are available, and scale back on the threads when they are not. This is surprisingly useful when you are trying to work multithreading into applications like (which uses GCD) that do not completely take over a computer (i.e.: have to play nice with other apps).

    With pthreads you would be hard-pressed to be able to do anything like that. Plus you would have to do all the tedium of thread-safe dispatch queues yourself.

Share This Page