Slashdot Mirror


NVIDIA Shaking Up the Parallel Programming World

An anonymous reader writes "NVIDIA's CUDA system, originally developed for their graphics cores, is finding migratory uses into other massively parallel computing applications. As a result, it might not be a CPU designer that ultimately winds up solving the massively parallel programming challenges, but rather a video card vendor. From the article: 'The concept of writing individual programs which run on multiple cores is called multi-threading. That basically means that more than one part of the program is running at the same time, but on different cores. While this might seem like a trivial thing, there are all kinds of issues which arise. Suppose you are writing a gaming engine and there must be coordination between the location of the characters in the 3D world, coupled to their movements, coupled to the audio. All of that has to be synchronized. What if the developer gives the character movement tasks its own thread, but it can only be rendered at 400 fps. And the developer gives the 3D world drawer its own thread, but it can only be rendered at 60 fps. There's a lot of waiting by the audio and character threads until everything catches up. That's called synchronization.'"

8 of 154 comments (clear)

  1. Re:Where's the story? by mrbluze · · Score: 3, Insightful

    No offence, but I'm perplexed as to how this rubbish made it past the firehose.

    --
    Do it yourself, because no one else will do it yourself. [beta blockade 10-17 Feb]
  2. Oversimplifying is bad by BattleCat · · Score: 1, Insightful

    Topic is rather interesting, especially for game developers, among whom I sometimes lurk , but what's the point of simplifying descriptions and problems up to the point of being meaningless and useless ?

    1. Re:Oversimplifying is bad by mrbluze · · Score: 2, Insightful

      but what's the point of simplifying descriptions and problems up to the point of being meaningless and useless ? This isn't information, it's advertising. The target audience is teenagers with wealthy parents who will buy the NVIDIA cards for them.
      --
      Do it yourself, because no one else will do it yourself. [beta blockade 10-17 Feb]
  3. New programming tools needed by maillemaker · · Score: 3, Insightful

    When I came up through my CS degree, object-oriented programming was new. Programming was largely a series of sequentially ordered instructions. I haven't programmed in many years now, but if I wanted to write a parallel program I would not have a clue.

    But why should I?

    What is needed are new, high-level programming languages that figure out how to take a set of instructions and best interface with the available processing hardware on their own. This is where the computer smarts need to be focused today, IMO.

    All computer programming languages, and even just plain applications, are abstractions from the computer hardware. What is needed are more robust abstractions to make programming for multiple processors (or cores) easier and more intuitive.

    --
    A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
    1. Re:New programming tools needed by Anonymous Coward · · Score: 1, Insightful

      Erlang?

    2. Re:New programming tools needed by philipgar · · Score: 2, Insightful

      While you make some good points in your comment, there are parts that are off. First, UNIX pipes are not an effective way to parallelize an application. UNIX pipes provide a method that tends to be inefficient, and will involve much "needless" copying of data (from your application to the pipe, the OS will then read in the data and write it to the other process which will then likely read the data into its address space). Additionally, UNIX pipes work well for steady state, but tend to have problems with starting up and stopping. This is true of many pipeline systems. They also lack the ability to easily communicate "side channel" information. There are other streaming programming languages that are being tried that will hopefully fix some of these problems, for instance, see the StreamIT project at MIT.

      Additionally your examples given in your post about UNIX pipes neglect to mention the fact that a pipeline is only as fast as it's slowest component. The idea of breaking tar -czf into tar cf|gzip and fully utilizing 2 CPUs is laughable. tar (without compression) is an extremely simple program that doesn't require much CPU time to run, while gzip will likely run for a while on the data. You'll likely get the situation where gzip is running 100% of the time (assuming your I/O is fast enough), and tar is running 5-10% of the time. This is quite far from the 200% number quoted.

      Pipelining is a fairly easy technique to exploit parallelism for some applications, but to really utilize many processors, SPMD (single program multiple data) techniques are necessary, as you hinted at with the worker threads (one way to achieve this). A well parallelized program should take advantage of both types of parallelism to maximize performance.

      Phil

  4. CUDA = NVIDIA desperate to compete with Intel? by Cordath · · Score: 4, Insightful

    CUDA is an interesting way to utilize NVIDIA's graphics hardware for tasks it wasn't really designed for, but it's not a solution to parallel computing in and of itself. (more on that momentarily) A few people have gotten their nice high end Quadros to do some pretty cool stuff, but to date it's been limited primarily to relatively minor academic purposes. I don't see CUDA becoming big in gaming circles anytime soon. Let's face it, most gamers buy *one* reasonably good video card and leave it at that. Your video card has better things to do than handle audio or physics when your multi-core CPU is probably being criminally underutilized. Nvidia, of course, wants people to buy wimpy CPU's and then load up on massive SLI rigs and then do all their multi-purpose computation in CUDA. Not gonna happen.

    First of all, there are very few general purpose applications that special purpose NVIDIA hardware running CUDA can do significantly better than a real general purpose CPU, and Intel intends to cut even that small gap down within a few product cycles. Second, nobody wants to tie themselves to CUDA when it's built entirely for proprietary hardware. Third, CUDA still has a *lot* of limitations. It's not as easy to develop a physics engine for a GPU using CUDA as it is for a general purpose CPU.

    Now, I haven't used CUDA lately, so I could be way off base here. However, multi-threading isn't the real challenge to efficient use of resources in a parallel computing environment. It's designing your algorithms to be able to run in parallel in the first place. Most multi-threaded software out there still has threads that have to run on a single CPU, and the entire package bottlenecks on the single CPU running that thread even if other threads are free to run on other processors. This sort of bottleneck can only be avoided at the algorithm level. This isn't something CUDA is going to fix.

    Now, I can certainly see why NVIDIA is playing up CUDA for all they're worth. Video game graphics rendering could be on the cusp of a technological singularity. Namely, ray tracing. Ray tracing is becoming feasible to do in real time. It's a stretch at present, but time will change that. Ray tracing is a significant step forward in terms of visual quality, but it also makes coding a lot of other things relatively easy. Valve's recent "Portal" required some rather convoluted hacks to render the portals with acceptable performance, but in a ray tracing engine those same portals only take a couple lines of code to implement and have no impact on performance. Another advantage of ray tracing is that it's dead simple to parallelize. While current approaches to video game graphics are going to get more and more difficult to work with as parallel processing rises, ray tracing will remain simple.

    The real question is whether NVIDIA is poised to do ray-tracing better than Intel in the next few product cycles. Intel is hip to all of the above, and they can smell blood in the water. If they can beef up the floating point performance of their processors then dedicated graphics cards may soon become completely unnecessary. NVIDIA is under the axe and they know it, which might explain all the recent anti-Intel smack-talk. Still, it remains to be seen who can actually walk the walk.

  5. Re:Is this why there's no OpenGL 3.0? by johannesg · · Score: 2, Insightful

    NVidia has every reason to want OpenGL to succeed - if it doesn't, Microsoft will rule supreme over the API to NVidia's hardware, and that isn't a healthy situation to be in. As it is, OpenGL gives them some freedom to do their own thing.

    However, having mentioned Microsoft... If *someone* does want OpenGL to succeed it is them... If and when OpenGL 3.0 ever appears, I bet there will be some talk of some "unknown party" threatening patent litigation...

    Destroying OpenGL is of paramount important to Microsoft, since it will grant them total dominance over 3D graphics. Apple, Linux, Sony (PS3), and other vendors that rely on OpenGL will completely lose their ability to compete.