=?windows-1252?Q?NVIDIA=92s_Tesla_T10P_Blurs_Some_Lines?=

What do you guys think about that?:
http://www.embeddedtechjournal.com/articles_2008/20080617_nvidia.htm

I heard about Cuda and GPU acceleration for HPC applications before
but this time I feel (like the author Kevin Morris) that this solution
is getting traction. I know some guys that three years ago tried to
use a Nvidia GPU to do FFTs and had to work at the OpenGL level. Not
very friendly. Now with Cuda getting more mature (and Telsa getting 64
bits floating point), it looks like it's becoming a nice alternative
to FPGAs.


Patrick

Patrick Dubois wrote:
> What do you guys think about that?:
> http://www.embeddedtechjournal.com/articles_2008/20080617_nvidia.htm
> 
> I heard about Cuda and GPU acceleration for HPC applications before
> but this time I feel (like the author Kevin Morris) that this solution
> is getting traction. I know some guys that three years ago tried to
> use a Nvidia GPU to do FFTs and had to work at the OpenGL level. Not
> very friendly. Now with Cuda getting more mature (and Telsa getting 64
> bits floating point), it looks like it's becoming a nice alternative
> to FPGAs.

and also this

http://www.embedded.com/products/softwaretools/208700454

["SAN JOSE, Calif. � Apple Inc. has submitted the Open Compute Language 
(OpenCL) to an ad hoc industry group that aims to define a programming 
environment for applications running across both x86 and graphics chips. 
The move is one of a growing number of efforts to extend the ubiquitous 
C language for increasing parallelism in multicore processors.]

Next, will we see boards with GPU and FPGA ?

-jg

Jim Granville wrote:
> Patrick Dubois wrote:
>> What do you guys think about that?:
>> http://www.embeddedtechjournal.com/articles_2008/20080617_nvidia.htm
>>
>> I heard about Cuda and GPU acceleration for HPC applications before
>> but this time I feel (like the author Kevin Morris) that this solution
>> is getting traction. I know some guys that three years ago tried to
>> use a Nvidia GPU to do FFTs and had to work at the OpenGL level. Not
>> very friendly. Now with Cuda getting more mature (and Telsa getting 64
>> bits floating point), it looks like it's becoming a nice alternative
>> to FPGAs.
> 
> and also this
> 
> http://www.embedded.com/products/softwaretools/208700454
> 
> ["SAN JOSE, Calif. � Apple Inc. has submitted the Open Compute Language 
> (OpenCL) to an ad hoc industry group that aims to define a programming 
> environment for applications running across both x86 and graphics chips. 
> The move is one of a growing number of efforts to extend the ubiquitous 
> C language for increasing parallelism in multicore processors.]
> 
> Next, will we see boards with GPU and FPGA ?
> 
> -jg
> 

Speaking of FPGA alternatives, this recently caught my eye. Don't know 
much about it, but it sure looks cool:

http://www.tilera.com/products/processors.php

-Jeff

Jeff Cunningham wrote:
>
> Speaking of FPGA alternatives, this recently caught my eye. Don't know
> much about it, but it sure looks cool:
>
> http://www.tilera.com/products/processors.php
>
> -Jeff

Jeff,
Where have I seen that before?
Ah yes, http://en.wikipedia.org/wiki/Transputer
Syms. 

On Thu, 19 Jun 2008 10:37:14 +0100, "Symon" wrote:

>Where have I seen that before?
>Ah yes, http://en.wikipedia.org/wiki/Transputer

And now, for bonus points, put an [X] against any
of the following reasons if you think it helps to 
explain why the Transputer was a market flop...

[ ] it was at least two decades ahead of its time
[ ] it was about one decade ahead of the technology
    needed to make it powerful enough to be competitive
[ ] it was based on robust, sound academic theory
[ ] it had a clean, effective, readable programming
    language that was not C
[ ] it was a British design
[ ] the software community was even more clueless about
    how to make use of multiple scalable compute resources
    in the late 1970s than it is today
[ ] when presented with a model that permits parallel
    processing to be spectacularly efficient, the
    software community retreats into its standard cosy
    set of assumptions that serial execution is sure
    to be faster and more efficient, and therefore
    Concurrent Is Bad, mainly because it isn't C

For maximum credit, write a 10,000 word dissertation
explaining why the social dynamics of the software community
will ensure the early death of anything that looks like
a general-purpose, tightly-coupled network of compute nodes.

Not that I'm bitter, or anything like that :-)
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

On Thu, 19 Jun 2008 12:04:16 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

>On Thu, 19 Jun 2008 10:37:14 +0100, "Symon" wrote:
>
>>Where have I seen that before?
>>Ah yes, http://en.wikipedia.org/wiki/Transputer
>
>And now, for bonus points, put an [X] against any
>of the following reasons if you think it helps to 
>explain why the Transputer was a market flop...
>
>[ ] it was at least two decades ahead of its time
>[ ] it was about one decade ahead of the technology
>    needed to make it powerful enough to be competitive
>[X] it was based on robust, sound academic theory
>[X] it had a clean, effective, readable programming
>    language that was not C
>[X] it was a British design
worse than that: it was a Government funded design under a government
that didn't fund technology...
>[ ] the software community was even more clueless about
>    how to make use of multiple scalable compute resources
>    in the late 1970s than it is today

Definitely not this one.

as well as O***m, they came up with Ada, where you can: 
	create a task type;
	create an array of tasks of that type;
	loop over the array starting the tasks;
	loop over the array collecting the results;
in pretty much no more code than the above.

Nowadays, C++ has given the SW community ONE positive thing:
the old argument that Ada is too large and complex to be usable no
longer holds water...

But count the hand-wringing woe-is-me stories about the difficulty of
parallelism and the massive new collaborations to solve the problem on
one hand, and the mentions of Ada (or O***m) on the other...

>[X] when presented with a model that permits parallel
>    processing to be spectacularly efficient, the
>    software community retreats into its standard cosy
>    set of assumptions that serial execution is sure
>    to be faster and more efficient, and therefore
>    Concurrent Is Bad, mainly because it isn't C
>
>For maximum credit, write a 10,000 word dissertation
>explaining why the social dynamics of the software community
>will ensure the early death of anything that looks like
>a general-purpose, tightly-coupled network of compute nodes.
>
>Not that I'm bitter, or anything like that :-)

The funny thing about the transputer (from the VERY little I did on it
at the time; paper only since I couldn't afford one as a hobbyist) is
that there was a time window when it appeared to be the fastest single
processor available, (ignoring 3-chip solutions) even without its hooks
for parallelism... but that got overshadowed by the parallelism.

If it had had an MMU, it could have made a nice Unix workstation 
(or single-chip Lilith, or...)

- Brian

On Jun 18, 5:39 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Next, will we see boards with GPU and FPGA ?
>
> -jg

What is missing is an embedded solution. To my knowledge, there is no
compact embedded system using the latest Nvidia GPUs. We can't fit a
PC (even a smallish one) inside our instrument. Even if we could, heat
dissipation would be a problem. So I guess that FPGAs will still reign
for a while in high performance embedded applications.

Patrick

Jeff Cunningham wrote:
> 
> Speaking of FPGA alternatives, this recently caught my eye. Don't know 
> much about it, but it sure looks cool:
> 
> http://www.tilera.com/products/processors.php

Availability?  Price?


       Dave

"Dave" <dave@comteck.com> wrote in message 
news:f008$485ae84d$40b83d5e$25934@COMTECK.COM...
> Jeff Cunningham wrote:
>>
>> Speaking of FPGA alternatives, this recently caught my eye. Don't know 
>> much about it, but it sure looks cool:
>>
>> http://www.tilera.com/products/processors.php
>
> Availability?  Price?

Nvidia. Google.

Yes. Cheap.

MikeWhy wrote:
> "Dave" <dave@comteck.com> wrote in message
> news:f008$485ae84d$40b83d5e$25934@COMTECK.COM...
>> Jeff Cunningham wrote:
>>>
>>> Speaking of FPGA alternatives, this recently caught my eye. Don't
>>> know much about it, but it sure looks cool:
>>>
>>> http://www.tilera.com/products/processors.php
>>
>> Availability?  Price?
>
> Nvidia. Google.
>
> Yes. Cheap.

MikeWhat?