Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Anyone not switching to CUDA ?

Reply
Thread Tools

Re: Anyone not switching to CUDA ?

 
 
fft1976
Guest
Posts: n/a
 
      07-22-2009
On Jul 22, 1:39*pm, Nicolas Bonneel
<(E-Mail Removed)> wrote:
> fft1976 a écrit :
>
> > I'm curious: is anyone not switching all their new projects to CUDA
> > and why? It seems to me that CPUs are quickly becoming irrelevant in
> > scientific computing.

>
> multi-core programming is not really recent. Also, coding on GPU already
> has several years, and CUDA is not the only way to code on GPU.
> Finally, Larrabee is being release soon, and I would see no reason to
> change all your code in a heavy way to make it run on GPU while Larrabee
> might require much fewer changes.



Frankly, I doubt Larrabee will be anywhere near 1.7 TFLOPS for $500
that we can have with CUDA _today_ (for a certain fairly wide class of
scientific problems)
 
Reply With Quote
 
 
 
 
BGB / cr88192
Guest
Posts: n/a
 
      07-23-2009

"fft1976" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Jul 22, 1:39 pm, Nicolas Bonneel
<(E-Mail Removed)> wrote:
> fft1976 a écrit :
>
> > I'm curious: is anyone not switching all their new projects to CUDA
> > and why? It seems to me that CPUs are quickly becoming irrelevant in
> > scientific computing.

>
> multi-core programming is not really recent. Also, coding on GPU already
> has several years, and CUDA is not the only way to code on GPU.
> Finally, Larrabee is being release soon, and I would see no reason to
> change all your code in a heavy way to make it run on GPU while Larrabee
> might require much fewer changes.


<--
Frankly, I doubt Larrabee will be anywhere near 1.7 TFLOPS for $500
that we can have with CUDA _today_ (for a certain fairly wide class of
scientific problems)
-->

I don't use CUDA, but I also don't do scientific computing...

I do some limited GPU based processing, but mostly this is through the use
of OpenGL and the use of fragment shaders.


I might be willing to code for the GPU if it were provided in a means
similar to GLSL, for example, as a kind of OpenGL add-on or companion
library, however, to make my code dependent on an IMO questionable
preprocessor and compiler toolset, probably not, even for the performance
benefit...

now, it probably seems like it would be less convinient to compile with a
library-based interface, but in my experience it is actually far more
convinient, even for things like ASM (which are traditionally statically
assembled and linked against an app).

though maybe counter-intuitive, the inconvinience cost of using a library
interface to compile and link the code, and accessing dynamically-compiled
code through function-pointers, turns out to be IME more convinient than
that of having to deal with an external compiler/assembler and getting it
linked in this way...

of course, maybe my sense of "convinience" is skewed, who knows...




 
Reply With Quote
 
 
 
 
Nicolas Bonneel
Guest
Posts: n/a
 
      07-23-2009
fft1976 a écrit :
> On Jul 22, 1:39 pm, Nicolas Bonneel
> <(E-Mail Removed)> wrote:
>> fft1976 a écrit :
>>
>>> I'm curious: is anyone not switching all their new projects to CUDA
>>> and why? It seems to me that CPUs are quickly becoming irrelevant in
>>> scientific computing.

>> multi-core programming is not really recent. Also, coding on GPU already
>> has several years, and CUDA is not the only way to code on GPU.
>> Finally, Larrabee is being release soon, and I would see no reason to
>> change all your code in a heavy way to make it run on GPU while Larrabee
>> might require much fewer changes.

>
>
> Frankly, I doubt Larrabee will be anywhere near 1.7 TFLOPS for $500
> that we can have with CUDA _today_ (for a certain fairly wide class of
> scientific problems)


This is not really the point. You cannot change your whole projects with
heavy modifications on the basis of a technology which is currently
beeing seriously endangered. I guess Larrabee will also provide much
better, and possibly larger cache.
GPU also suffer from rounding of denormalized numbers to zero (which is
fine for graphics, but maybe not for scientific computing).
Think that to get good performance with GPUs, you really have to
re-think your whole project (even if it was already parallelized on CPU)
just because of the GPU cache.

With 32cores featuring vector instructions of 16 single precision
numbers at the same time, I guess you can indeed get performances
similar to current GPUs. But with much less involved re-coding.

If you target broad diffusion of your application, you're stuck anyway
with graphic cards which do not support CUDA (while they still support
shaders).
So, except if by "project" you mean a 6 month research project, I don't
find any argument to port tens/hundreds of thousands lines of code to CUDA.

--
Nicolas Bonneel
http://www-sop.inria.fr/reves/Nicolas.Bonneel/
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      07-23-2009
Nicolas Bonneel <(E-Mail Removed)> writes:
> GPU also suffer from rounding of denormalized numbers to zero (which
> is fine for graphics, but maybe not for scientific computing).


They also use floats rather than doubles, which are useless for
scientific computing. I notice that the ones that do support
doubles do so at a tenth of the performance of floats, which is
roughly the hit you'd get if you wrote your own multi-precision
floats.

Then again, I tend to be a bit of Kahan-ite when it comes
to FPUs.
Phil
--
If GML was an infant, SGML is the bright youngster far exceeds
expectations and made its parents too proud, but XML is the
drug-addicted gang member who had committed his first murder
before he had sex, which was rape. -- Erik Naggum (1965-2009)
 
Reply With Quote
 
nmm1@cam.ac.uk
Guest
Posts: n/a
 
      07-23-2009
In article <h48b4n$q1o$(E-Mail Removed)>,
BGB / cr88192 <(E-Mail Removed)> wrote:
>
>
>I might be willing to code for the GPU if it were provided in a means
>similar to GLSL, for example, as a kind of OpenGL add-on or companion
>library, however, to make my code dependent on an IMO questionable
>preprocessor and compiler toolset, probably not, even for the performance
>benefit...


That was one of my two points. They are working on it. Watch this
space.


Regards,
Nick Maclaren.
 
Reply With Quote
 
BGB / cr88192
Guest
Posts: n/a
 
      07-23-2009

"Phil Carmody" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Nicolas Bonneel <(E-Mail Removed)> writes:
>> GPU also suffer from rounding of denormalized numbers to zero (which
>> is fine for graphics, but maybe not for scientific computing).

>
> They also use floats rather than doubles, which are useless for
> scientific computing. I notice that the ones that do support
> doubles do so at a tenth of the performance of floats, which is
> roughly the hit you'd get if you wrote your own multi-precision
> floats.
>
> Then again, I tend to be a bit of Kahan-ite when it comes
> to FPUs.


probably this would depend a lot on the type of "scientific computing", as
there are likely some types of tasks where speed matters a whole lot more
than accuracy...





 
Reply With Quote
 
Paul Hsieh
Guest
Posts: n/a
 
      07-23-2009
On Jul 22, 11:54*pm, Phil Carmody <(E-Mail Removed)>
wrote:
> Nicolas Bonneel <(E-Mail Removed)> writes:
> > GPU also suffer from rounding of denormalized numbers to zero (which
> > is fine for graphics, but maybe not for scientific computing).

>
> They also use floats rather than doubles, which are useless for
> scientific computing. I notice that the ones that do support
> doubles do so at a tenth of the performance of floats, which is
> roughly the hit you'd get if you wrote your own multi-precision
> floats.
>
> Then again, I tend to be a bit of Kahan-ite when it comes
> to FPUs.


Sure, sure ... but don't mistake the forest from the trees. If nVidia
is really serious about CUDA they will be forced to make real IEEE-754
doubles just like Intel or anyone else. I am sure that this is already
in their pipeline of features slated for a future product.

nVidia *wants* this to be used for super computing applications and
the TOP500 list guy refuses to accept any results from something that
isn't 64 bit. The economical motivations should be sufficient to
guarantee that they support it in the future. And if they don't write
a benchmark for it showing that its slower than advertised, publicize
your benchmark widely and watch nVidia respond.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
 
Reply With Quote
 
nmm1@cam.ac.uk
Guest
Posts: n/a
 
      07-23-2009
In article <(E-Mail Removed)>,
Paul Hsieh <(E-Mail Removed)> wrote:
>
>Sure, sure ... but don't mistake the forest from the trees. If nVidia
>is really serious about CUDA they will be forced to make real IEEE-754
>doubles just like Intel or anyone else. I am sure that this is already
>in their pipeline of features slated for a future product.


I asked them that question, and their non-answer made it pretty clear
that it is.


Regards,
Nick Maclaren.
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      07-23-2009
http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
> In article <(E-Mail Removed)>,
> Paul Hsieh <(E-Mail Removed)> wrote:
>>
>>Sure, sure ... but don't mistake the forest from the trees. If nVidia
>>is really serious about CUDA they will be forced to make real IEEE-754
>>doubles just like Intel or anyone else. I am sure that this is already
>>in their pipeline of features slated for a future product.

>
> I asked them that question, and their non-answer made it pretty clear
> that it is.


They already have doubles in their Tesla line. Their spokespeople have
also already admitted that they'll make professional (i.e. Tesla)
customers pay for the advanced silicon until there's demand from the
commodity market, and that's the direction they're expecting, and
planning, to move in.

Phil
--
If GML was an infant, SGML is the bright youngster far exceeds
expectations and made its parents too proud, but XML is the
drug-addicted gang member who had committed his first murder
before he had sex, which was rape. -- Erik Naggum (1965-2009)
 
Reply With Quote
 
nmm1@cam.ac.uk
Guest
Posts: n/a
 
      07-23-2009
In article <(E-Mail Removed)>,
Phil Carmody <(E-Mail Removed)> wrote:
>
>They already have doubles in their Tesla line. Their spokespeople have
>also already admitted that they'll make professional (i.e. Tesla)
>customers pay for the advanced silicon until there's demand from the
>commodity market, and that's the direction they're expecting, and
>planning, to move in.


Er, have you any idea how slow they are? Real programmers seem to
agree that a Tesla is 3-4 times faster than a quad-core Intel CPU
in double precision, which doesn't really repay the huge investment
in rewriting in CUDA.

I believe that a future version of the Tesla will improve the speed
of double precision considerably.


Regards,
Nick Maclaren.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
CUDA standard with Windows ? Skybuck Flying Windows 64bit 5 07-01-2011 01:56 AM
CUDA bindings? jzakiya Ruby 6 06-28-2010 07:00 PM
CUDA dg.google.groups@thesamovar.net Python 0 01-29-2009 05:34 PM
Process Switching vs. Fast/CEF Switching? asdf Cisco 7 05-29-2007 05:26 PM
anyone who help me about routing and switching. PS2 gamer Cisco 1 06-01-2004 05:40 AM



Advertisments