os that rather uses the gpu?

Robert Myers rbmyersusa at gmail.com
Sat Jul 17 03:04:40 UTC 2010

On Fri, Jul 16, 2010 at 10:35 PM, JD <jd1008 at gmail.com> wrote:

> So, what would you say is/are the class/classes of problems that would
> benefit greatly from a high flops gpu, but without the sort of bus
> bandwidth you would like to see?

Almost any problem that is embarrassingly parallel or nearly so is
potentially a candidate for low-bandwidth computing.  Ray tracing is the
primo example.  Almost any linear problem is potentially embarrassingly
parallel, and, if you don't want to go through the work of exposing the
embarrassingly parallel nature of the problem, there are the tricks that
make the linpack benchmark so popular for selling "supercomputers" that have
absurdly small bisection bandwidths.

My question, though, is, if that's the kind of problem you have, why not do
it on a distributed platform and teach students how to use distributed
resources?  If you're Pixar, I understand why you'd want a well-organized
farm of GPU's, but if you just want to replicate what LLNL (Lawrence
Livermore) was doing, say, ten years ago, are you doing your students any
favor by giving them a GPGPU instead of the challenge of doing real
distributed computing?  Conceivably, watts per flop (power consumption)
makes GPGPU's the hands down winner over distributed computing for problems
that are embarrassingly parallel or nearly so.  Inevitably, though, people
will want clusters of GPUGPU's, so you'll wind up doing distributed
computing, anyway.

If you rewrite your applications for the one-off architectures typical of
GPU's, so that you have to do it all over again when the next generation
comes out, have you really done yourself any favors?

I don't claim that there are simple or obvious answers, but it's just too
easy for people to be blown away by huge flops numbers.  What I'm afraid of
has already started to happen as far as I'm concerned, which is that all
problems will be jammed into the low-bandwidth mold, whether it's
appropriate or not.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/users/attachments/20100716/c41c7b9d/attachment.html 

More information about the users mailing list