GPGPU support

[Rick C. Hodgin]

> Hi,
> I'm not really sure which kind of computations gmp uses, but in my
> experience matrix-computations and ffts can be done really well on
> gpus. This is why cuda is used in most projects. It provides cuBLAS
> and cuFFT, so that you don't have to care about the low-level cuda
> implementation and can just use the cuda-kernels in your normal
> c++-code.
> For example it is relatively straight forward to change the
> lapack-code to run on a nvidia-gpu.
> Yours sincerely
> Robert Schade

Robert, thanks for that info.  I'm thinking there has to be a way to
approach the vector-like abilities of any GPU engine through a generic
modification to the compiler back-end.  The logic rules are there for a
single operation, and if we can create a model which uses those rules in
a vector instead of a single computing stream, then every application
out there that makes use of computational logic could be immediately
migrated to the GPU using this approach.

gvcc is my proposed naming convention.  It uses the GNU C front-end, and
the vector component mimics using GPU primitives the same capabilities
as the CPU would, but always with vector lanes in mind, keeping each one
where it needs to be throughout the entire function.

I think this would be possible.  Difficult, but possible, and it would
solve virtually every issue I've seen to date about serial algorithms
being unable to reap any benefits from the GPU.  From a programmer's
point of view, it would be something like having the compiler create
multiple threads for you, but instead of running on CPUs governed by the
kernel, they're running on the GPU governed by the specifics of the
back-end engine used at the time of compile.

I have a whole slew of steps in mind on how we can get from "does not
exist today" to "it appears to be working on these logic ops" to "it
appears to be working on these processing ops" to full-blown
applications.

gvcc -- un-serializing the un-serializable. :-)

- Rick