Re: GPUs and CUDA

[Shark8 <onewingedshark@gmail.com>]

On Jul 12, 12:59 am, Anatoly Chernyshev <achernys...@gmail.com> wrote:
> On Jul 11, 10:38 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> wrote:
>
> > Wouldn't a multicore PC with additional Graphics processors be
> > a candidate for an Ada 2012 Ravenscar multicore runtime?
>
> I'm not sure about that, taking into account that Ada's original
> purpose is embedded systems, which are often missing GPUs whatsoever.
> Yet, I believe, GPU's cores are not quite the same as CPU's, even in
> terms of synchronization and communication.
>
> >Err... I think "binding" is perhaps a horrid idea. (Raise your hand if
> >you just want a light wrapper around C-headers.)
> >The way to go, IMO, is to allow a specialized pragma to indicate to
> >the compiler that such and such subprogram is intended for
> >distribution to the GPUs for parallel work.
> >This would allow something like
> > Pragma CUDA( Ralph );
>
> I guess, in this particular case, the binding or port is better. The
> suggested pragma makes the language (or at least compiler) hardware-
> dependend, which I, personally, would hate to see.

Yet that is exactly what implementation-defined pragmas are supposed
to allow.
And it needn't force the program to be implementation-dependent;
consider:

Task Type Some_Task [...];

Procedure X is
  Tasks : Array (1..20) of Some_Task;
  Pragma Multiprocessor(Construct => Tasks, Processors => 4, Cores =>
4);
begin
Null; -- We're finished with the procedure when all tasks are
finished.
end X;

A compiler which is written for a single-processor computer is free to
ignore the pragma Multiprocessor...
and yet this will still work. (Though maybe not as-typed, I didn't try
to compiler it, it might need a level of indirection.)

In the particular case of CUDA I've always thought it would have been
better for them to specialize an Ada compiler rather than a C compiler
simply because the TASK construct is very well-suited to such
parallelisms; they could have had some error/complexity-checking which
would cause the compiler to error-out should the TASKs tagged with the
CUDA held things which would be impossible or onerous to implement.

> Yet, the IT's
> hardware sector is much more agile than Ada's standards, so that today
> we have CUDA, and tomorrow it will be replaced by who-knows-what...

True.