[Openmcl-devel] Speed, compilers and multi-core processors

Thu May 21 10:48:19 PDT 2009

Am 21.05.2009 um 16:55 schrieb Paul Krueger:

> You can't emphasize these points enough. GPGPU technology has its  
> place, but it's not perfect for everything. If you have an  
> application where data can be partitioned up neatly and distributed  
> to separate processing elements which tend to do the same limited  
> things over and over (FFT's are a good example), then GPGPU's may be  
> appropriate (as are FPGA's for similar reasons, although there are  
> certainly other factors there). If you have an application where  
> each processing thread may dynamically determine that it needs data  
> from an arbitrary location within a very large block of memory or  
> needs to do frequent updates within large data blocks in arbitrary  
> ways, then GPGPU's are not appropriate because the communication and  
> synchronization costs will typically kill you. That's especially  
> true on any larger distributed memory architecture, but even on  
> smaller systems you might overwhelm the memory subsystem.  Many of  
> the sorts of AI, graph, and intelligent applications that I am  
> personally more interested in fall into the second category, so  
> GPGPU's will likely not be of much help.

The appeal of the GPU is that it has lots of computing elements  
(originally designed for 3d rendering tasks). The trend is that these  
computing elements are getting more flexible and numeric computations  
are getting more accurate. Now we are at a point where the first  
programming languages appear that will allow writing portable  
algorithms that are able to run on the GPU: CUDA, OpenCL, ...

The typical applications the average user will see are about  
manipulating large amounts of multimedia data. Think using FinalCut  
Pro to render visual effects, to convert video formats etc. Think  
iPhoto/Aperture plugins that manipulate large 'raw' images (dust  
filters, sharpeners, ...). At the same time scientists working with  
such kind of data will find its uses, too.

If you look back at the SIMD Connection Machine it was thought that  
there are graph applications that are able to run in parallel on such  
a machine. The graph was mapped to compute elements which could  
communicate efficiently with nearby elements. A somewhat typical  
application domain was also querying data collections. Spread those  
data collections across a huge number of compute elements and run MAP/ 
REDUCE operations. An outcome was the WAIS protocol and a document  
query engine running on the connection machine ( http://en.wikipedia.org/wiki/Wide_area_information_server 
  )

For Lisp users it might be interesting to run numeric matrix  
operations in applications like Maxima on the GPU. Image understanding  
applications like Freedius ( http://www.ai.sri.com/project/FREEDIUS )  
could benefit from it. But there it would be probably written in the C/ 
OpenCL side and used from Lisp via FFI. CAD applications, too. I could  
even imagine that a large Triple Store ( http://en.wikipedia.org/wiki/Triple_Store 
  ) has algorithms in the query domain that could benefit from GPU /  
SIMD support. Also think about blackboards that have some dimensions  
as matrices mapped to the GPU (example of a blackboard system in Lisp: http://gbbopen.org/ 
  ).

As an example see this GBBOpen function:  map-instances-on-space- 
instances

   http://gbbopen.org/hyperdoc/ref-map-instances-on-space-instances.html

   ' Apply a function once to each unit instance on space instances,  
optionally selected by a retrieval pattern. '

Then see  FIND-INSTANCES:  http://gbbopen.org/hyperdoc/ref-find-instances.html

I could imagine that SOME uses of these function could be speed up a  
lot by running in parallel on a GPU with, say, 256 compute elements.

But that is just speculation on my side. It really depends if users  
really have such application problems and they can be mapped to GPUs.

Regards,

Rainer Joswig

>
> Paul
>
> On May 20, 2009, at 1:06 PM, Dan Weinreb wrote:
>
>> The instruction set is very restricted, and the communication
>> paths aren't there, as you suggested.  GPGPU is especially
>> good for highly compute-intensive operations over not
>> all that much data.  An FFT is an obvious example but
>> there are many, many good examples.  (Not that I'm an
>> expert, but I do know that much.)
>>
>> There are CUDA-compatible devices that don't even
>> have a video connection, i.e. for GPGPU only.
>> The NVidia Tesla, called a "computing processor"
>> (weird name).  240 cores per board, and you can
>> chain together four of them.
>>
>> (My officemates are getting this info and telling to
>> me faster than I can type it in.  Thanks, Andrew
>> and Scott.)
>>
>> -- Dan
>>
>> Jeremy Jones wrote:
>>>
>>> On Wed, May 20, 2009 at 9:13 AM, Raffael Cavallaro
>>> <raffaelcavallaro at mac.com> wrote:
>>>
>>>> tomshardware.com ran this a couple of days ago:
>>>>
>>>> <http://www.tomshardware.com/reviews/nvidia-cuda-gpgpu,2299.html>
>>>>
>>>> It's a summary of real-world results from apps using Nvidia's CUDA.
>>>> For certain things, like video encoding, they're seeing a 4x  
>>>> speedup
>>>> using the GPU over using the CPU. In addition, when they use the  
>>>> GPU,
>>>> it leaves the CPU free for other tasks.
>>>>
>>>
>>> Why don't we just throw out the main CPU and fill our computers with
>>> graphics cards?  (Once CCL is ported to GPUs of course)
>>>
>>> Seriously though, what does a CPU have that a GPU doesn't, besides a
>>> different instruction set?  More memory?  Better i/o?  Is the GPU
>>> instruction set too specialized?  I bet the answer is mainly  
>>> software,
>>> like OSes and device drivers.  I remember in the old days it was
>>> common to have a separate processor to handle i/o.  Maybe that's  
>>> what
>>> the main CPU should be relegated to.  OTOH, if the software is good
>>> enough, it should just be distributed to whatever computing  
>>> resources
>>> are appropriate and available.  Just thinking out loud.
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

Rainer Joswig, Hamburg, Germany
http://lispm.dyndns.org/
mailto:joswig at lisp.de

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20090521/9a929be2/attachment.htm>