在GPU上运行C＃代码

Question

I have no knowledge of GPU programming concepts and APIs. I have a few questions:

1. Is it possible to write a piece of managed C# code and compile/translate it to some kind of module, which can be executed on the GPU? Or am I doomed to have two implementations, one for managed on the CPU and one for the GPU (I understand that there will be restrictions on what can be executed on the GPU)?
2. Does there exist a decent and mature API to program independently against various GPU hardware vendors (ie a common API)?
3. Are there any best practices if one wants to develop applications that run on a CPU, written in managed language, and also provide speed optimizations if suitable GPU hardware is present?

I would also be glad for links to any kind of documentation with appropriate learning resources.

Best, Jozef

Answer 1

1) No - not for the general case of C# - obviously anything can be created for some subset of the language

2) Yes - HLSL using Direct X or Open GL

3) Not generally possible - CPU and GPU coding are fundamentally different

Basically you can't think of CPU and GPU coding as being comparable. A GPU is a highly specialised parallel processing tool - for lots of parallel simple calculations.

Trying to write a general progam in a GPU with lots of branches etc just won't be efficient - maybe not even possible.

Their memory access architectures are totally different.

You should write for the CPU but farm out appropriate parallel computations to the GPU.

Answer 2

1) No, not for the general case of C#, but a small subset, yes. Either through a runtime (check Tidepowerd GPU.NET) or via language support (LINQ or Code Quotations).

2) Yes, DirectCompute (DX11 Compute Shaders) and OpenCL are both vendor independent, mature APIs and you can find .NET binding for them.

3) No, as James said, they are different beast. GPU are high latency processors optimized for high throughput data parallel applications whereas CPU are low latency processors optimized for sequential general purpose applications.

The only research project I know that tries to address this issue is the SPAP language.

My advice, don't try to find the perfect universal API/runtime because there's none. Pick an existing technology (DirectCompute or OpenCL) and see how you can leverage it for your business.

Useful links for starting:

• Microsoft DirectCompute SDK (DirectCompute is part of the DirectX SDK)
• NVIDIA Compute SDK (ton of samples, CUDA, DirectCompute and OpenCL ones)
• AMD Stream SDK (mostly OpenCL samples)

Answer 3

1) Not that I know of, but there might be a library for C# that can help you.

2) OpenCL. It's GPU-independent and can even run on CPUs.

3) OpenCL will help you with that, you can compile for CPU too with OpenCL, though I'm not sure how great of code it makes for the CPU. I've really fallen in love with OpenCL lately, it works really really well.

Answer 4

There's also brahma . It supposedly captures expressions and compiles them for the GPU. I haven't tried myself.

And, Microsoft has a research prototype called accelerator , which is similar in goal but syntactically different.

Answer 5

Have you looked at Alea GPU ? There libraries, while not completely free, have a fair license. There is great documentation and an impressive looking tool-chain.

Answer 6

For Java, see the Aparapi project ( https://github.com/aparapi/aparapi ). This allows a subset of Java to be run on any GPU which supports OpenCL. The bytecode of Kernel classes is cross-compiled at runtime to OpenCL code. There are severe restrictions on the java code which can be cross-compiled - basically no Objects can be used as fields, locals or method args.

However a hefty advantage is that the kernels can be executed in either Java or OpenCL (with automatic fallback to Java ThreadPool execution in the event of unavailability of an appropriate GPU/APU device). This sounds like the closest thing to what you are seeking in part 3 of your question (though of course the managed language is not C#).

I'm not aware of anything similar in C#.