Why 'Gaming' Chips Are Moving Into the Server Room

Esther Schindler writes "After several years of trying, graphics processing units (GPUs) are beginning to win over the major server vendors. Dell and IBM are the first tier-one server vendors to adopt GPUs as server processors for high-performance computing (HPC). Here's a high level view of the hardware change and what it might mean to your data center. (Hint: faster servers.) The article also addresses what it takes to write software for GPUs: 'Adopting GPU computing is not a drop-in task. You can't just add a few boards and let the processors do the rest, as when you add more CPUs. Some programming work has to be done, and it's not something that can be accomplished with a few libraries and lines of code.'"

Comments

A whole new level of parallelism

[TwiztidK]

I've heard that many programmers have issues coding for 2 and 4 core processors. I'd like to see how they'll addapt to running "run hundreds of threads" in parallel.

Re:A whole new level of parallelism

[morcego]

This is just like programing for a computer cluster ... after a fashion.

Anyone used to do both should have no problem with this.

I'm anything but a high end programmer (I mostly only code for myself), and I have written plenty of code that runs with 7-10 threads. Believe me, when you change the way you think about how an algorithm works, it doesn't matter if you are using 3 or 10000 processors.

Re:A whole new level of parallelism

[Sax Maniac]

This isn't hundreds of threads that can run arbitrary code paths like a CPU, you have to totally redesign your code, or already have implemented parallel code so that you already run a number of threads that all do the same thing at the same time, just on different data.

The threads all run in lockstep, as in, all the threads better be at the same PC at the same time. If you run into a branch in the code, then you lose your parallelism, as the divergent threads are frozen until they come back together.

I'm not a big thread programmer, but I do work on threading tools. Most of the problems with threads seems to come with threads doing totally different code paths, and the unpredictable scheduling interactions that arise between them. GPU coding a lot more tightly controlled.

Re:A whole new level of parallelism

[Nadaka]

No it isn't. That you think so just shows how much you still have left to learn.

I am not a high end programmer either. But I have two degrees on the subject and have been working professionally in the field for years, including optimization and parallelization.

Many algorithms just won't have much improvement with multi-threading.

Many will even perform more poorly due to data contention and the overhead of context switches and creating threads.

Many algorithms just can not be converted to a format that will work within the restrictions of GPGPU computing at all.

The stream architecture of modern GPU's work radically differently than a conventional CPU.

It is not as simple as scaling conventional multi-threading up to thousands of threads.

Certain things that you are used to doing on a normal processor have an insane cost in GPU hardware.

For instance, the if statement. Until recently OpenCL and CUDA didn't allow branching. Now they do, but they incur such a huge penalty in cycles that it just isn't worth it.

Re:A whole new level of parallelism

[Dynetrekk]

Believe me, when you change the way you think about how an algorithm works, it doesn't matter if you are using 3 or 10000 processors.

Have you ever read up on Amdahl's law?

Good luck with that

[tedgyz]

This is a long-standing issue. If your programs don't just "magically" run faster, then count out 90% or more of the programs that will benefit from this.