Support also doing processing on GPUs

This was discussed on pdl-devel back in Dec 2015 (see https://sourceforge.net/p/pdl/mailman/pdl-devel/?viewmonth=201512). There is also some discussion in Jun this year on PerlMonks (https://www.perlmonks.org/?node_id=11134476).

I recently revisited this; my thinking so far is that the best platform for mixed CPU/GPU processing seems to be OpenCL. However, OpenCL C doesn't support native-complex processing, but it would be possible to use OpenCL C++ with a class that overloads the arithmetic operators for source compatibility with existing Code; an easy first-cut alternative would be to only support GPU use on real types (which may also be further restricted to not supporting double for <OpenCL 2.0 environments - GPUs have long been aimed at speed rather than extreme precision, because of graphics' needs).

Defining some terms: "kernel" is a term in GPGPU-land for the code that actually runs in the GPU, typically being run once per "work item", which is basically identical to the "inner loop" inside a broadcastloop %{ /* blah */ %} (and/or loop). Current PDL operations have code generated by PP that doesn't distinguish between the "kernel" and the setup code (which runs on the "host"), since the output is just a bunch of C to put inside the function. When that distinction starts to matter, it will need some work.

Things that would need doing to allow this:

• split Code (etc) into kernel and setup code; another benefit of doing so would be to aid lazy-building ndarrays since PDL could be made to set up a set of very small ndarrays, call the kernel on that, then do something with the results, then throwing them away - an example might be to sumover a very long sequence using basically no memory
• figure a way to allow calling at least one other different broadcastloop initiator (as called in PP-generated C code); for back-compat with current CPU-only it's not desirable to make PDL have a hard requirement of OpenCL to operate at all
• implement dividing work into a task queue with 4x as many items as the number of processing-units as alluded to here (https://sourceforge.net/p/pdl/mailman/pdl-devel/?viewmonth=202109) (which will also help with parallelising non-deterministic tasks)
• either figuring how to identify code that calls into GPU-unavailable C functions (e.g. LAPACK) and having that not use GPU, or figure the best way to manage opt-in / opt-out of GPU use - an easy way might be to simply try OpenCL-compiling the generated code, which undoubtedly will fail if any unsuitable function calls (or headers) are found

Resources:

• https://github.com/CastXML/CastXMLSuperbuild which illustrates how to use CMake to build an external project (here, LLVM might be needed)
• http://portablecl.org/docs/html/install.html shows how to install Portable OpenCL (POCL)
• https://en.wikipedia.org/wiki/OpenCL#Example:_complex_number_arithmetic shows OpenCL C++ code to implement overloaded arithmetic operations for complex numbers
• https://github.com/KhronosGroup/libclcxx OpenCL C++ libraries
• https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html the actual spec for OpenCL 3.0 C

No specific file or test is named. Start by reading the PP-generated C path around broadcastloop and loop, then review the OpenCL resources linked in the issue. Done would require a defined approach for separating kernel and setup code, selecting GPU-capable operations, and preserving CPU-only operation.