GPGPUs

[Atash]

On Tuesday, 13 August 2013 at 16:27:46 UTC, Russel Winder wrote:
> The era of GPGPUs for Bitcoin mining are now over, they moved 
> to ASICs.
> The new market for GPGPUs is likely the banks, and other "Big 
> Data"
> folk. True many of the banks are already doing some GPGPU 
> usage, but it
> is not big as yet. But it is coming.
>
> Most of the banks are either reinforcing their JVM commitment, 
> via
> Scala, or are re-architecting to C++ and Python. True there is 
> some
> C#/F# but it is all for terminals not for strategic computing, 
> and it is
> diminishing (despite what you might hear from .NET oriented 
> training
> companies).
>
> Currently GPGPU tooling means C. OpenCL and CUDA (if you have 
> to) are C
> API for C coding. There are some C++ bindings. There are 
> interesting
> moves afoot with the JVM to enable access to GPGPU from Java, 
> Scala,
> Groovy, etc. but this is years away, which is a longer 
> timescale than
> the opportunity.
>
> Python's offerings, PyOpenCL and PyCUDA are basically ways of 
> managing C
> coded kernels which rather misses the point. I may get involved 
> in
> trying to write an expression language in Python to go with 
> PyOpenCL so
> that kernels can be written in Python – a more ambitious 
> version aimed
> at Groovy is also mooted.
>
> However, D has the opportunity of gaining a bridgehead if a 
> combination
> of D, PyD, QtD and C++ gets to be seen as a viable solid 
> platform for
> development.  The analogue here is the way Java is giving way 
> to Scala
> and Groovy, but in an evolutionary way as things all interwork. 
> The
> opportunity is for D to be seen as the analogue of Scala on the 
> JVM for
> the native code world: a language that interworks well with all 
> the
> other players on the platform but provides more.
>
> The entry point would be if D had a way of creating GPGPU 
> kernels that
> is better than the current C/C++ + tooling.
>
> This email is not a direct proposal to do work, just really an 
> enquiry
> to see if there is any interest in this area.

Clarifying question:

At what level is this interest pointed at? Is it at the level of 
assembly/IL and other scary stuff, or is it at creating bindings 
that are cleaner and providing more convenient tools?

'Cuz I'm seeing a lot of potential in D for a library-based 
solution, handling kernel code similar to how CUDA does (I think 
the word is 'conveniently'), 'cept with OpenCL or whatever 
lower-level-standard-that-exists-on-more-than-just-one-company's-hardware 
and abuse of the import() expression coupled with a heavy dose of 
metaprogramming magic.