Comment by vergessenmir | Hacker News Reader

Comment by vergessenmir | Hacker News Reader

I've had to grab my throwaway a/c just because I've worked on this. I've used this framework in a commercial settings, in finance where it is gaining popularity. Have had to work through the bugs, been through several upgrade iterations.

When it works. It works. When it fails you're in for a world of pain. A lot is going on behind the scenes. The data structures, classes need special annotations to carefully translate the c# structures into something that cuda understands. You have to pay special attention to your object hierarchy, you have to be aware of all C# keywords that are supported and not supported. The fields in your class may be misaligned by a few bytes of the wrong annotation is used.

Don't get me started on cuda pointers - you're not shielded from this. My experience with this has put me off cuda frameworks in general.

You're better off learning cuda or hiring a cuda Dev than investing heavily in stacks like this.

My background is in HPC in finance.

Why would someone use C# in the first place? It seems to me that any advantage from the environment has gets lost by trying to make it work on a GPU.

I was going to say something similar to this. Usually such abstractions are leaky. I don't know the target market for this product. The one's who know CUDA will just use C++. The one's who know C++ won't use this. The one's who do not know CUDA will probably not use this because they will need to learn CUDA first anyway.

(Same story with those C# to Javascript compilers)

Well C# is a more familiar language for quants and quant devs than cuda.

Very few quants know CUDA. My brother happens to be one of them but he does most of his development now in python/pandas. He gets someone else to do the heavy lifting to target the HPC platform of choice.

Now the motivation behind the layer or framework is to provide greater productivity, remove the step of pairing quants with cuda Devs when productionsing the code.

These are all valid reasons to adopt such frameworks. But in practice the cost of upgrades, strange pointer bugs and delays to production releases don't make it worth it. Also you need the CUDA Dev for situations that the framework fails. If such a framework does become available that removes these pain points, I'd adopt it in a heartbeat

This may vary in other industries other than finance.

Are there structural problems with this approach or is it mainly because of immaturity? Usually version 3 of most software is mature enough to judge it by its merits.

Sounds like an IL analysis could point out all the problematic cases without all of the pain.

I'd take what you have described over Python and C++ easily.

I disagree, if people have given up trying to fly on the years of continous crashes, we would never haven gotten mainstream comercial flights.

Many times there is a need of ongoing investment, where things are failing pretty bad, until they actually take off.

Your example doesn’t account for substitutes, though. Before commercial flights, civilians couldn’t fly. Before Hybridizer, programmers could still use CUDA.

The point being that it takes time to get the right solution for a problem, and we shouldn't be stuck with C and C++ for GPGPU forever, just because no one has found out the ideal solution for multi-language GPGPU programming.

Just yesterday I saw a documentary about Gotthard Tunnel, also considered impossible to achieve, with high human costs and risk of insolvency until they finally managed it.

John Harrison took almost his entire life to create the first usefull marine chronometer, amid disbelief and issues to get proper funding.

Or if you want to bring it closer to home, very few people believed JavaScript would ever become fast or even leave the browser.

Sure, and on the road to flight many bad/impractical ideas were thrown out.

Reply on news.ycombinator.com