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

[Alexander Repenning]

In some cases you can apply the antiobjects idea to find a completely   
different solution that WILL work nicely with GPGPU frameworks. Say,  
if you do pathfinding then A* is usually the way to go. Because of the  
problems you mentioned A* will not work well with CPUs, i.e., A* is  
neither easily parallelizable  and nor incremental. Collaborative  
Diffusion solves the same problem in a completely different way that  
is parallelizable  and incremental. In essence you are running some  
kind of cellular automata computing diffusion equations. I think there  
would be many more applications like this.

Alex


On May 21, 2009, at 8:55 AM, Paul Krueger wrote:

> 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.
>
> 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

Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf


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