ILGPU: Write GPU programs with C# and F#
github.com
github.com
It quickly seems that the low level C/Cpp is becoming obsolete, and it's hard to squeeze performance unless you're doing something truly green field / new. Otherwise someone has already optimized the hell out of it.
So what's the use case for porting GPU to higher level languages like C#? What would you use this for?
Because all code is in the single repository in the post and is fairly easy to read, you can skim through it to draw your own conclusions if this interests you.
Also, very easy to start using: just `dotnet add package ILGPU` on most configurations (as ADHD puts higher mental strain on activities involving complex configuration, I try to keep to the tools that have minimal ceremony)
C# (and F# by extension) generally allow to write system-ish code, with references to locals and same C primitives, which means that you're likely not sacrificing in performance in this particular scenario by having the language be higher-level. After all, you're using ILGPU's APIs first and foremost.
As to why use it at all - you are likely to move faster with it than C++, especially if it's not your full-time job, with all the escape hatches to extract 99.9% efficiency still on the table (that is, if performance of the kernel emitted by ILGPU has issues in the first place - see below for alternative, cheap FFI and easy C/C++ integration are still there as well).
It also lets you do things like PTX assembly: https://github.com/m4rs-mt/ILGPU/blob/master/Samples/InlineP...
I hear and see both of these sentiments frequently from the internet crowd (on-lookers). It's both wrong and humorously arrogant. I'll repeat what I said to someone on reddit yesterday: there are thousands (maybe 10s?) scattered around the FAANGs, NVIDIA, AMD, Intel, accelerator startups, boutiques, etc. whose day to day is both C/C++ and squeezing perf out of kernels and getting many points (sometimes 10s) improvement. Certainly the wins aren't daily but I'm saying they do steadily find room for improvement. How is that possible? I'll give you a hint: platforms, demands, hardware, use-cases all change essentially on a quarterly basis.
So before you proclaim victory on behalf of whatever high-level framework, ask yourself if you're really familiar with the production and business environment for this kind of code.
I'm always really shocked on hn when people getting called out for arrogance respond with accusations (of vitriol). What day job do you have where you can make proclamations like "It quickly seems that the low level C/Cpp is becoming obsolete" while simultaneously admitting being an amateur and not get checked. Must be very different from my day job where being precise and accurate and conservative is paramount. Moreover what kind of habit of thought are you in that being called out for that is read as vitriol?
When people post like this it's hard to tell if they are trying to have a conversation in good faith, or they are seeking pleasure in the form of belittling someone.
it was as condescending as the original comment was arrogant. what exactly is the confusion here? if you want to a community where people are allowed to make bold claims without doing sufficient research (hn) then you should also allow for those people to treated as such.
That’s as much a matter of personal identity as a ‘habit of thought’, friend. Otherwise, we could we comment on the basis of _your_ perspective as some mutable affectation, no?
You see, we are shadows of ourselves. An inquisitive play, or let’s say a “judgment” about Cuda economics: aspirational, errant? Then, the linguistic phalanx: honed no doubt by long running needs to be heard and seen and listened to.
My day job is optimization for logistics and multi-agent systems on edge deployments. We vary between heterogenous compute environment on-platform and occasional connections to cloud-like servers, but only occasionally. The system has a lot to do and we're pushing what it can do for itself.
I like these problems and am always trying to find new ways to solve them. That's really it, I'm wondering if it's best to focus on learning to work the hardware as is, or learning to twist existing libraries into new problems.
For example if you look at this: https://weightythoughts.com/p/cuda-is-still-a-giant-moat-for...
It actually denigrates anyone who would consider starting at low level CUDA kernels. I liked your message though, you had a great point: what do I imagine all those CUDA programmers do if not write CUDA?
2. I don’t think you have an appreciation for the sheer amount of software—including lots of very critical software—implemented in C and C++ that are being improved upon daily.
A buddy of mine works on critical low-level software (including C) in the energy sector. Millions of lines of code. The effects, positive or negative, of any single code change can impact tens of thousands of Americans (likely even more). His job is to maintain and continuously optimize this software. Given your comment, I think you’d be surprised to learn that he never runs out of work.
https://old.reddit.com/r/rust/comments/18209in/gpu_programmi...
Currently SIMD support for a fast CPU accelerator is the main focus for the next big accelerator type.
I did look once at back-end implementations and contributing either Metal back-end or adapting Vulkan back-end to run on top of MoltenVK seemed much more realistic.
With that said, OpenCL already works as is so you are not completely unsupported.
OTOH the field is almost bare on the Apple side, in spite of there being over a billion devices out there with relatively low hardware fragmentation and almost uniform ISA throughout the entire product lineup. Hence the suggestion.
You can just give it a try and see if you like it or not.
In general, I think you are right and Python has completely won for high-level libraries while C++ has completely won for implementation, and threshold for making people move is way too high: difficult to match 5-10x improvement over Python in experience, and C++ crowd would never even look at C#, let alone think it has something to offer them, because the mythology says that the only true way is C/C++ for this kind of code and C# is just weird Java (especially now with ggml being on the radar of many).
(fun thought experiment: imagine average reaction to a statement "you can write high level code that compiles to Metal Performance Shaders or targets Apple AMX but it's C#", not dissimilar to a reaction when people hear that C# is the prime choice for portable SIMD code)