Text 11271, 61 rader
Skriven 2006-05-31 18:14:24 av /m (1:379/45)
Ärende: Deconstructing databases with Jim Gray
==============================================
From: /m <mike@barkto.com>

http://www.regdeveloper.co.uk/2006/05/30/jim_gray/

===
...Graphical Processor Units or GPUs

What are your views on using Graphical Processor Units (GPUs) for data
processing?

Unbeknownst to most of us, the graphics community has been building vector
co-processors and putting them into every laptop, every desktop. At present,
the typical vector co-processor has about 40 times the CPU power - instruction
per second power - of the CPU. It also has about ten times the memory
bandwidth.

Intel and AMD talk about multi-core; well, a typical GPU has a hundred cores, a
hundred pipelines and is doing all this texture mapping in parallel. So if you
could figure out how to program the GPU you could go a lot faster, and the coda
to this is that the GPU continues to double at a much faster rate of speed than
CPUs. So it is incumbent upon us software guys to use the instructions where we
find them, and we are beginning to find lots and lots of instructions in the
GPU.

There is a Microsoft research project, which has published a technical report,
I think two months ago, about Accelerator [Microsoft Tech Report 2005-184 -
Ed], a general purpose programming language that extends C# and allows you to
program array-oriented operations in video and ATI chips. The language is
generic; you can program not knowing which GPU you've got.

This project was working with some people at the University of North Carolina
and they are graphics guys who know how to program GPUs and they came up with a
novel algorithm for sorting. So the general thing we are doing is going
methodically through the problems and seeing if we can map those problems to
GPUs. I'm currently looking at processing satellite imagery and much of the
satellite image processing fits GPUs beautifully because it is fundamentally
pixel programming. My main role in working on that paper was that, in doing
something like sorting, you have to balance I/O and CPU and memory utilisation.
So it's a system-wide design and I helped the people at North Carolina with
making sure that the I/O could deliver data quickly enough so that we weren't
disk-bound. We had to use several disks in order to keep the system busy
because a disk only gives you data at about 50MB per second and the GPU can
sort at about 500MB per second.

What kind of applications would the GPU processing would suit?

Crypto would be a good application. In addition, many of the large data
applications; like mapping applications or sensor applications. Of course, the
most natural thing is any kind of the processing of cameras so if you can get
Photoshop recast using the GPU instead of the CPU it would run a lot faster.
Fundamentally highly parallel "do this to all the pixels" applications are
good....
===

Geo., didn't you at on epoint mention that the powerful GPUs would be used for
encryption/decryption of high-def video signals?

 /m

--- BBBS/NT v4.01 Flag-5
 * Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)