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.
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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.

I'm interested. There may be a significant need for gpu work for my PhD, seeing as the amount of data needing to be crunched is a bit daunting (dozens of sensors with MHz sampling, with very intensive image analysis / computer vision work).
I could farm the whole thing out to cpu nodes, but using the gpu nodes would be more fun.


However, I'm insanely busy atm and have next to no experience with gpu programming, so I'm probably not gonna be that useful for a while!

On Tuesday, 13 August 2013 at 16:27:46 UTC, Russel Winder wrote:
> The entry point would be if D had a way of creating GPGPU kernels that
> is better than the current C/C++ + tooling.

You mean an alternative to OpenCL language?

Because, I imagine, a library (libopencl) would be easy enough to write/bind.

Who'll gonna standardize this language?

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.

I suggest looking into HSA.

http://developer.amd.com/wordpress/media/2012/10/hsa10.pdf

This will be available on AMD APUs in December, and will trickle out to arm and other platforms over time.

On Tuesday, 13 August 2013 at 18:35:28 UTC, luminousone wrote:
> 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.

>
> http://developer.amd.com/wordpress/media/2012/10/hsa10.pdf
>
> This will be available on AMD APUs in December, and will trickle out to arm and other platforms over time.

What a very interesting concept redesigned from the ground up.

How about this for the future:

D2 > LLVM Compiler  > HSAIC Finaliser > Architected Queueing Language


Here is a another usefull link:

http://developer.amd.com/resources/heterogeneous-computing/what-is-heterogeneous-system-architecture-hsa/

Nick

On Tuesday, 13 August 2013 at 22:24:18 UTC, Nick B wrote:
> On Tuesday, 13 August 2013 at 18:35:28 UTC, luminousone wrote:
>> 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.
>
>>
>> http://developer.amd.com/wordpress/media/2012/10/hsa10.pdf
>>
>> This will be available on AMD APUs in December, and will trickle out to arm and other platforms over time.
>
> What a very interesting concept redesigned from the ground up.
>
> How about this for the future:
>
> D2 > LLVM Compiler  > HSAIC Finaliser > Architected Queueing Language
>
>
> Here is a another usefull link:
>
> http://developer.amd.com/resources/heterogeneous-computing/what-is-heterogeneous-system-architecture-hsa/
>
> Nick

And its not just AMD, HSA is supported by the HSA Foundation, with wide industry support.

http://hsafoundation.com/

It is platform independent, at least in so far as it doesn't need x86 to operate, within a few years most ARM devices will support HSA.

And HSAIL bytecode sits inside the ELF executable file next to the platform's bytecode, so compiling it in does not break any platform that does not support HSA.

Memory isn't simply a shared architecture, its fully cache coherent, allows the GPU to use the same virtual address space as the CPU, On an APU platform you never need to copy data to and from GPU memory, simply pass a pointer and your done.

HSAIL bytecode also is expressive enough for c++(including virtual functions) to compile directly to it, so no reason D can't.

Some additions to D to handle micro threading, wouldn't go amiss however.

The HSA finalizer AMD will be provided is supposed to use LLVM(at least that is my understanding).

So changes required to support HSA would likely be minimal, most of these changes would be friendly to building in support for openCL or the like as well for none supported platforms.

Russel Winder:

> This email is not a direct proposal to do work, just really an enquiry to see if there is any interest in this area.

Probably I can't help you, but I think today some of the old purposes of a system language, that is to write code for heavy computations, are now done on GPUs (or even ASICs as you say). So using only the CPU from D is not enough. So what you are discussing here is important.

Bye,
bearophile

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.

On Fri, 2013-08-16 at 04:21 +0200, Atash wrote:
[…]
> 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?

Assembly language and other intermediate languages is far from scary but not really what is proposed, which was intended to be "standards compliant", with the current standard being OpenCL. There is a place for assembly language level working but there are others who do that to realize the standards giving us a C linkage API.

> '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.

CUDA has a huge tool chain designed as much to ensure lock in to C, C++ and NVIDIA as to make computations easier for end users.

OpenCL is (was?) Apple's vision for API access to the mixed CPU and GPGPU hardware it envisaged, and which is now rapidly being delivered. Intel chips from now on will always have one or more GPGPU on the CPU chips. They label this the "many core" approach.

The core (!) point here is that processor chips are rapidly becoming a collection of heterogeneous cores. Any programming language that assumes a single CPU or a collection of homogeneous CPUs has built-in obsolescence.

So the question I am interested in is whether D is the language that can allow me to express in a single codebase a program in which parts will be executed on one or more GPGPUs and parts on multiple CPUs. D has support for the latter, std.parallelism and std.concurrency.

I guess my question is whether people are interested in std.gpgpu (or
some more sane name).

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Friday, 16 August 2013 at 10:04:22 UTC, Russel Winder wrote:
> [...]
> The core (!) point here is that processor chips are rapidly becoming a
> collection of heterogeneous cores. Any programming language that assumes
> a single CPU or a collection of homogeneous CPUs has built-in
> obsolescence.
>
> So the question I am interested in is whether D is the language that can
> allow me to express in a single codebase a program in which parts will
> be executed on one or more GPGPUs and parts on multiple CPUs. D has
> support for the latter, std.parallelism and std.concurrency.
>
> I guess my question is whether people are interested in std.gpgpu (or
> some more sane name).

It seems to me that you are describing something similar to C++
AMP, which is a high level, language specific solution to GPGPU
problem.