Proposal: GPU Execution of C# functions

[TehWardy]

Bear with me, I know there's a heavy expectation here ...

In todays world of computing its commonly accepted that the GPU is better suited to some tasks with a high level of threading or parallelism.

I have been building applications a lot lately that need to be executed as scheduled tasks because the cpu code would take several minutes to process what could be done on the gpu in little more than a couple of seconds. Such scenarios might include but are not limited to ...

• complex reporting scenarios in many business applications
• financial applications that use things like lap cubes and have large 3D sets of data
• 3D sets of data that need simple functions to compute each item in the set

In order to take advantage of the monster available in most computers that is the GPU I have to do a whole ton of tasks like ...

• pull in DX or OpenGL
• learn those API's
• learn HLSL
• learn how to compile HLSL code
• and so on ... ... the list of things to do is endless just to get even the most basic access to that computing power.

What i'm proposing here is not a full blown open source DX / rendering API implementation but simply the ability to execute some code on the GPU from within C#.

As An example: I would love to be able to do something like this in C# and have roslyn work out the details for me ...

// and here's what I would like to write in C# and have roslyn figure out for me
// threadRef would always be passed and would be a framework defined object
// myArgs would be an object of my definition that would be passed in to each thread
GPUTask<TResult> Compute<T, TResult>(ThreadRef threadRef, T myArgs)
{
    float result;
     ...
     return result;
}

The impact on my productivity would be insane here, it also means I can use all the of the resources available on my server not just that little CPU with its tiny number of cores. I can see scenarios in industries like finance, making really good use of this as its a neat way to compute large

To call it we could use something like a link extension perhaps ...

T list = GetList<T>();
var result = await list.GPUEach(Compute, i); //returns a Task<IEnumerable<T>>

Each item in the list would then be given to a thread on the gpu to execute. I suspect there would need to be some rules around the type of code that could be executed (e.g no daft things like EF calls or cmplex types where you call methods on them in the compute function but the roslyn compiler is really smart and i'm sure with some really simple rules we could throw a compile time exception to say "this function is runnable on the gpu" or similar.

[svick]

Have you tried any of the existing approaches that allow you to program GPUs from C#? (Some that I found after a quick search: CUDAfy.NET, GpuLinq, Alea GPU.) Were those insufficient for your needs?

[TehWardy]

Neat, didn't know others had already done this type of thing. I was actually thinking it might be cool just to have it as a core feature that C# was a language that could be executed on both platforms, more so since more platforms is the current aim generally speaking anyway for C# and Roslyn.

[gafter]

I'm not sure what this has to do with Roslyn. Are you asking for language support?

[TehWardy]

@gafter: I don't really know where things need to happen but my guess is that there would need to be support in the compiler to take a chunk of one of the other Roslyn supported languages and compile it to HLSL / OpenCL and wrap it in some mechanism that allows it to be called in the normal way I call c# methods.

What i guess this means to roslyn is that (with some rules / constraints) C# methods could be compiled in to HLSL or OpenCL functions that can be executed on the gpu (probably needing a new library that takes advantage of this new functionality in the compiler).

The net result: I write C#, the compiler worries about getting it to run on my GPU, and my code makes the most of all of my system resources not just that CPU.

[dsaf]

Even the SIMD support is still not ready :( http://blogs.msdn.com/b/dotnet/archive/2014/05/13/update-to-simd-support.aspx

[dsaf]

@TehWardy re-post here:

https://github.com/dotnet/coreclr https://github.com/dotnet/corefx https://github.com/dotnet/corefxlab

[benaadams]

Even the SIMD support is still not ready :(

@dsaf Not sure what you mean? Its been mainstream ever since RyuJIT x64 and 4.6 went RTM in July

[sharwell]

I'd love to expand https://github.com/tunnelvisionlabs/NOpenCL to include this type of functionality.

I've considered two primary approaches:

1. Create a Roslyn-based compile-time translator that reads C# methods (e.g. static methods which have a particular attribute applied to them) and converts it to OpenCL code which might look like this. The converted code could then get embedded as a resource, and a C# wrapper could be compiled that callers can use instead of the original method to automatically run the GPU code on supported systems or the C# implementation on others.
2. Create a runtime disassembler for CIL that performs operation similar to the previous approach, but does so at runtime.

[dsaf]

@benaadams sorry, you are right! http://www.nuget.org/packages/System.Numerics.Vectors

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[TehWardy]

@sharwell NOpenCL looks cool :) and if it's possible to be done entirely transparently to the caller other than a simple attribute on a method that's an even better bonus.

[aL3891]

I also think this would be really cool but not really a language feature in it self, however it does kind of tie in to roslyn since this would be a really cool application of the proposed code generation from nugets as well as the replace/original keywords that are proposed (#5561 and dotnet/roslyn#5292.)

Using those features, a library could look for an attribute and then generate the code to actually run the method on the gpu.

[JeWaVe]

[disclaimer : I work for altimesh] Just for you to know there are proprietary compilers doing that for you.

You can have a look at our community product (free) Hybridizer for example, and our SDK on github.

In addition, our full product can target simd hardware from the same code.

For the sake of completeness, our main competitors are cudafy (not updated for a long time), and aleaGPU.

[kaby76]

I have been writing a free and open source compiler for CIL/C# to NVIDIA GPUs for the last two years, called Campy. It is under development and still has a way to go. (I can only do so much, but I'm an unemployed compiler developer.) It currently supports value/ref types, virtual functions, new, strings, arrays, collections, generics, Net Framework/Core/Standard, Windows/Ubuntu, minimal support for debugging in VS. It's based off of LLVM 7.0 (for debugging support), CUDA 9. The runtime is based off of DotNetAnywhere and highly modified with CUDA. I didn't use Corefx/Coreclr because a lot of native code would have to be modified, and it's such a moving target. If you do add support for targeting a GPU, there are a lot of issues, e.g., identifying what to compile to GPU, data structure copy issues, memory management of reference types for a SIMT model, exceptions (CUDA does not support C++ exception handling), files (there are no files on a GPU, and no way to call the CPU from GPU), etc.

[ghost]

Tagging subscribers to this area: @dotnet/area-meta See info in area-owners.md if you want to be subscribed.

Issue Details

---

Bear with me, I know there's a heavy expectation here ... In todays world of computing its commonly accepted that the GPU is better suited to some tasks with a high level of threading or parallelism. I have been building applications a lot lately that need to be executed as scheduled tasks because the cpu code would take several minutes to process what could be done on the gpu in little more than a couple of seconds. Such scenarios might include but are not limited to ... - complex reporting scenarios in many business applications - financial applications that use things like lap cubes and have large 3D sets of data - 3D sets of data that need simple functions to compute each item in the set In order to take advantage of the monster available in most computers that is the GPU I have to do a whole ton of tasks like ... - pull in DX or OpenGL - learn those API's - learn HLSL - learn how to compile HLSL code - and so on ... ... the list of things to do is endless just to get even the most basic access to that computing power. What i'm proposing here is not a full blown open source DX / rendering API implementation but simply the ability to execute some code on the GPU from within C#. As An example: I would love to be able to do something like this in C# and have roslyn work out the details for me ... ``` // and here's what I would like to write in C# and have roslyn figure out for me // threadRef would always be passed and would be a framework defined object // myArgs would be an object of my definition that would be passed in to each thread GPUTask Compute(ThreadRef threadRef, T myArgs) { float result; ... return result; } ``` The impact on my productivity would be insane here, it also means I can use all the of the resources available on my server not just that little CPU with its tiny number of cores. I can see scenarios in industries like finance, making really good use of this as its a neat way to compute large To call it we could use something like a link extension perhaps ... ``` T list = GetList(); var result = await list.GPUEach(Compute, i); //returns a Task> ``` Each item in the list would then be given to a thread on the gpu to execute. I suspect there would need to be some rules around the type of code that could be executed (e.g no daft things like EF calls or cmplex types where you call methods on them in the compute function but the roslyn compiler is really smart and i'm sure with some really simple rules we could throw a compile time exception to say "this function is runnable on the gpu" or similar.

Author:	TehWardy
Assignees:	-
Labels:	`area-Meta`, `discussion`, `untriaged`
Milestone:	-