Slashdot Mirror


Ask Slashdot: What Is the Most Painless Intro To GPU Programming?

dryriver writes "I am an intermediate-level programmer who works mostly in C# NET. I have a couple of image/video processing algorithms that are highly parallelizable — running them on a GPU instead of a CPU should result in a considerable speedup (anywhere from 10x times to perhaps 30x or 40x times speedup, depending on the quality of the implementation). Now here is my question: What, currently, is the most painless way to start playing with GPU programming? Do I have to learn CUDA/OpenCL — which seems a daunting task to me — or is there a simpler way? Perhaps a Visual Programming Language or 'VPL' that lets you connect boxes/nodes and access the GPU very simply? I should mention that I am on Windows, and that the GPU computing prototypes I want to build should be able to run on Windows. Surely there must a be a 'relatively painless' way out there, with which one can begin to learn how to harness the GPU?"

19 of 198 comments (clear)

  1. GPU programming is pain by Anonymous Coward · · Score: 5, Funny

    GPU programming is painful. A painless introduction doesn't capture the flavor of it.

    1. Re:GPU programming is pain by PolygamousRanchKid+ · · Score: 5, Funny

      Yeah, it would be like S&M without the pain . . . cute, but something essential is missing from the experience.

      Heidi Klum has a TV show call "Germany's Next Top Model". She basically gets all "Ilsa, She-Wolf of the SS" on a bunch of neurotic, anorexic, pubescent girls, teaching them how a top model needs to suffer.

      Heidi Klum would make a good GPU programming instructor.

      . . . and even non-geeks would watch the show. A win-win for everyone.

      --
      Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
    2. Re:GPU programming is pain by Anonymous Coward · · Score: 4, Funny

      Yeah, that's what we need! More neurotic, anorexic, pubescent girls who know how to do GPU programming!

    3. Re:GPU programming is pain by Darinbob · · Score: 4, Funny

      I thought we needed more "Ilsa, She-Wolf" programming instructors.

  2. Learn OpenCL by Tough+Love · · Score: 5, Insightful

    Since the whole point of GPU programming is efficiency, don't even think about VBing it. Or Pythoning it. Or whatever layer of a shiny crap might seem superficially appealing to you.

    Learn OpenCL and do the job properly.

    --
    When all you have is a hammer, every problem starts to look like a thumb.
    1. Re:Learn OpenCL by Tr3vin · · Score: 4, Interesting

      Learn OpenCL and do the job properly.

      This. OpenCL is C based so it shouldn't be that hard to pick up. The efficient algorithms will be basically the same no matter what language or bindings you use.

    2. Re:Learn OpenCL by CadentOrange · · Score: 4, Informative

      What's wrong with a higher level language that interfaces with OpenCL? You're still writing OpenCL, you're just using Python for loading/storing datasets and initialisation. If you're starting out, something like PyOpenCL might be better as it'll allow you to focus on writing stuff in OpenCL.

    3. Re:Learn OpenCL by HaZardman27 · · Score: 4, Insightful

      That's because the closest analogy to a software engineer using a more abstracted language in the hardware world is the packaging of common circuitry. Or when hardware engineers design chips, do they actually model out the components of every single transistor?

      --
      Apparently wizard is not a legitimate career path, so I chose programmer instead.
    4. Re:Learn OpenCL by AdamHaun · · Score: 4, Informative

      Or when hardware engineers design chips, do they actually model out the components of every single transistor?

      Chip design is absurdly complicated (even on the digital side), and involves several layers of abstraction. In roughly increasing level of detail:

      * Spec level: high-level behavioral description of the functionality of a digital system, something like "8-bit 115.2kbps UART" or "2MHz PWM with 0-100% duty cycle in 0.1% increments".
      * HDL/RTL level: software-like description of the complete system design. Can range from higher-level (describing behavior) to lower-level (describing specific logic). When people talk about buying, selling, or creating "IP" in the chip design world, they're usually talking about RTL for a single functional unit.
      * Gate level: Logic gates and flip-flops and their connections.
      * Transistor level: The transistors that make up the gates, and their connections.
      * Device level: The behavior of an individual transistor.
      * Physical layout: Just what it sounds like; the actual arrangements of metal and silicon.

      There are some more in between, but that should give you an idea. HDLs are not necessarily low-level. For large designs (like modern SoCs), it takes some *very* expensive and complex software to go deeper into the list, and the process is not entirely automated. So I wouldn't say hardware design can't be high-level. The difference is that in hardware, you always have to care about the lowest level when you're doing your high-level design, while in software you can take more things for granted. So even though a board-level design might just be a bunch of off-the-shelf chips hooked together, it still takes a lot of work to make sure everything comes out right.

      --
      Visit the
    5. Re:Learn OpenCL by Chaos+Incarnate · · Score: 3, Funny

      Just because we C# programmers can't do memory management worth a damn doesn't mean we're no better than VB programmers. We at least know what case sensitivity means. ;)

      --
      Benford's Corollary to Clarke's Law: "Any technology distinguishable from magic is insufficiently advanced."
  3. Re:XNA or Unity by stewsters · · Score: 4, Informative

    I don't think he is looking at making a game, I think he is looking for some cheap parallel processing. I have done some cuda, it was a pain to set up a few years back. There probably are better tutorials now.

  4. Obsidian by jbolden · · Score: 4, Informative

    I get the impression that CUDA/OpenCL is still the best option. This thesis on Obsidian presents, a Haskell set of binding which might be easier and also covers the basics quite well. Haskell lends itself really well because the language inherently is designed for parallelism because of purity and out of order computation. That being said, I think Obsidian is a bit rough around the edges but if you are looking for a real alternative, this is one.

    1. Re:Obsidian by jbolden · · Score: 4, Informative

      The big issue is that Haskell is lazy. Which means in particular the programmer by default doesn't determine order of execution. This makes Haskell a better counter example since order of execution is so key to so many languages.

      Erlang's type system is rather typical dynamic while Haskell has a Hindley–Milner type system which again shows off the plusses of functional better.

      Haskell has more of the most sophisticated ideas in computer science than any other language. It has become the standard for computer science in particular language and compiler research. So when an idea is "news" there is very likely an implementation of Haskell of that idea. Erlang's community is more practical and less cutting edge.

      Haskell is easier to program in.

  5. GPU programming *is* pain, princess. by Chris+Mattern · · Score: 4, Informative

    Anyone who tells you differently is selling you something.

  6. OpenACC by SoftwareArtist · · Score: 4, Interesting

    OpenACC is what you're looking for. It uses a directive based programming model similar to OpenMP, so you write ordinary looking code, then annotate it in ways that tell the compiler how to transform it into GPU code.

    You won't get as good performance as well written CUDA or OpenCL code, but it's much easier to learn. And once you get comfortable with it, you may find it easier to make the step from there into lower level programming.

    --
    "I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
  7. Nothing easy but Udacity can help by Jthon · · Score: 5, Informative

    So there's nothing really easy about GPU programming. You can look at C++ AMP from Microsoft, OpenMP or one of the other abstractions but you really need to understand how these massively parallel machines work. It's possible to write some perfectly valid code in any of these environments which will run SLOWER than on the CPU because you didn't understand fundamentally how GPUs excel at processing.

    Udacity currently has a fairly decent intro course on GPU programming at: https://www.udacity.com/course/cs344

    It's based around NVIDIA and CUDA but most of the concepts in the course can be applied to OpenCL or another GPU programming API with a little syntax translation. Also you can do everything for the course in your web-browser and you don't need an NVIDIA GPU to finish the course exercises.

    I'd suggest running through that and then deciding on what API you want to end up using.

  8. Understand The Hardware by Anonymous Coward · · Score: 3, Informative

    If you are going to program a GPU, and you are looking for performance gains, you MUST understand the hardware. In particular, you must understand the complicated memory architecture, you must understand the mechanisms for moving data from one memory system to another, and you must understand how your application and algorithm can be transformed into that model.

    There is no shortcut. There is no magic. There is only hardware.

    If you do not believe me, you can hunt up the various Nvidia papers walking you through (in painful detail-- link below) the process of writing a simple matrix transpose operation for CUDA. The difference between a naive and a good implementation, as shown in that paper, is huge.

    That said, once you understand the principles, CUDA is relatively easy to learn as an extension of C, and the Nvidia profiler, NVVP, is good at identifying some of the pitfalls for you so that you can fix them.

    http://www.cs.colostate.edu/~cs675/MatrixTranspose.pdf

  9. Re:CUDA by UnknownSoldier · · Score: 4, Informative

    Agreed 100% about CUDA and OpenMP! Already invented a new multi-core string searching algorithm and having a load of fun playing around with my GTX Titan combing CUDA + OpenMP. You can even do printf() from the GPU. :-)

    The most _painless_ way to learn CUDA is to install CUDA on a Linux (Ubuntu) box or Windows box.
    https://developer.nvidia.com/cuda-downloads

    On Linux, at the command line fire up 'nsight' open the CUDA SDK samples and start exploring! And by exploring I mean single-stepping through the code. The NSight IDE is pretty darn good considering it is free.

    Another really good doc is the CUDA C Programming Guide.
    http://docs.nvidia.com/cuda/cuda-c-programming-guide/

    Oh and don't pay attention to the Intel Propaganda - there are numerous inaccuracies:
    Debunking the 100X GPU vs CPU Myth: An Evaluation of Throughput Computing on CPU and GPU
    http://pcl.intel-research.net/publications/isca319-lee.pdf

  10. OpenACC or OpemMP 4.0 are exactly what you want by John_The_Geek · · Score: 5, Informative

    I teach this stuff daily, and the huge advance over the past year has been the availability of OpenACC, and now OpenMP 4, compilers that allow you to use directives and offload much of the CUDA pain to the compiler.

    There is now a substantial base of successful codes that demonstrate that this really works efficiently (both development time and FLOPS). S3D runs at 15 PFLOPS on Titan using this and may well win the Gordon Bell prize this year. Less than 1% of lines of code modified there. NVIDIA has a whole web site devoted to use cases.

    I recommend you spend a day to learn it. There are regular online courses offered, and there is a morning session on it this Monday at XSEDE 13 if you are one of those HPC guys. A decent amount is available online as well.

    BTW, with AMD moving to Fusion, the last real supporter of OpenCL is gone. NVIDIA prefers OpenACC or CUDA and Intel prefers OpenMP 4 for MIC/Phi. So everyone officially supports it, but no one really puts any resources into it and you need that with how fast this hardware evolves.