To me ComputeSharp looks a lot more accessible. I could understand how to use it instantly from the readme file. While I've gone over the documentation for ilgpu now and it mostly raises more questions.

Looks like ComputeSharp is at a higher level of abstraction, or closer to what I expect with my background.

Anyway its definitely a valuable project and I'd love to give it a run.

Ouch... that's very sad to hear :( ILGPU was developed with Cuda/OpenCL/C++ AMP (designed for GPGPU computing) in mind. Do you have any suggestions for us to improve the documentation?

You have a very short-sighted view of .Net development. I’d take whatever .Net tech over anything Java. With Mono, .Net, .Net Core, and Unity’s IL2CPP .Net and C# start to appeal to a broad audience.

I think you have very short-sighted view of Java. Java has GraalVM. There's simply nothing even close in .NET world. And this is just about the core of the runtime.

Java is catching up quickly. I say that as a .NET-focused dev, who touches Java once a year.

I primarily develop Unity Applications and there is IL2CPP that compiles and runs IL code as C++. Also, I’ve developed in Java regularly over the years and it’s never a pleasure. C# is a better language. Java 8 introduced Stream API and it sucks. I hate how blotted every new Java Library is in size and API smell. Everything in Java land is over-engineered and Tomcat can die in a fire.

I work with both regularly since 2002, alongside occasional C++ development, and Microsoft UI division really needs to clarity what they want.

The GUI roadmap is becoming a joke, now they are pushing for Blazor on Web Widgets as Electron alternative alongside MAUI, with a "pick whatever you like best".

This doesn't work like that when selling long term solutions to customers, specially when we still have UWP scars to take care of.

It feels that after WinRT failure to take over the world, they are unsure where to go next, and throwing into all directions to see what sticks.

Keep in mind that you're on Hacker News: the majority of the commenters will not be referring to desktop software but rather web, which is where all the focus and the drive behind all .NET Core feature development has been coming from.

I think it's fair to say that the .NET team absolutely has a vision and has made significant progress towards achieving it so far as web (frontend/backend) development is concerned, despite how ridiculously lacking the desktop UI story is/has been. (In fact, it's even worse than that since 10 years ago, .NET was the only ecosystem that had an excellent and comprehensive story for UI development that was supported from start to finish.)

Check the deep chain of comments discussing the postponing of AOT and Java interoperability for cloud deployments on .NET 6 to .NET 7, as resources were focused on making MAUI work on macOS.

Where was this?

You kind of proved my point.

Ever been to a JS shop? At least when someone hacks C# together, the math works, libraries don't dissapear from under you, and every build message does not contain "such and such developer is looking for a good job"

> "They restarted IIS instances and Windows servers regularly. Now they restart their Docker container instances."

Sound like an improvement to me :)

And okay suppose we accept they are clueless, whats with accusations of arrogance?

This is me, except I haven't looked at Docker yet. I'm just using straight self-hosted kestrel instead of IIS now.

I think the fact that it runs on dx12 is very cool, because it could potentially allow me to run gpgpu stuff on a laptop with only integrated graphics. Does anyone have any sense of whether or not that would be worthwhile? Is the parallel efficiency of an integrated gpu worthwhile to develop for?

If your algorithm is well parallelized, sure! Even a mobile GPU would likely be much faster in things such as image processing or other general purpose shaders than trying to run those on the CPU (which especially on mobile is likely not to be very performant).

If you wanted to try, you can clone the repository (make sure to be in the dev branch!) and then run the Benchmark project, which will show you some baseline difference in speed between the CPU and the GPU for some example algorithms. Let me know how it goes!

Thanks for the reply! I will check this out. My potential use case is actually audio processing, I’ll let you know how it goes!

Awesome! If you find any particular problems feel free to open an issue on the repo (or ping me in the C# Discord server). Do make sure to grab one of the latest ComputeSharp 2.0 packages from the CI though and not the ones on NuGet, those are still with the old 1.x version, I plan to update them in the coming weeks! Also remember to have a look at the various samples in the repo if you want some general reference as to what kind of operations can be done with the library. Cheers!

I thought most audio DSP/VSTs don't use GPGPU because of the latency. It is rare CUDA or similar is required, if ever.

Intel and AMD integrated graphic support OpenCL, meaning ILGPU will work on your laptop.

CUDA is NVidia vendor lock-in. While not a bad things intrinsically, it does limit possibilities for a general purpose. With this one, you can just plug whatever GPU that supports DX12 into your hardware and start creating "incoming blockchain miners written in C# in ..3..2..1"

But why is ILGPU a problem then? ILGPU is CUDA + OpenCL. OpenCL should be fine, right?

And DX12 is Microsoft vendor lock-in. To make a portable GPGPU app I'll have to use ILGPU. The only platform DX12 covers, that ILGPU does not is XBox.

ILGPU provides both Linux and MacOS.

ComputeSharp can run code on the CPU as well, through the DX12 WARP device (https://docs.microsoft.com/windows/win32/direct3darticles/di...). It's obviously not super performant compared to properly optimized code for the GPU, but it offers an easy to use fallback solution for devices that don't have a compatible GPU at least. ComputeSharp will just automatically pick that device if it can't find a suitable GPU to use, and it's also possible to just explicitly use that one instead if eg. you wanted to run some tests or something else.

The CPU part I mentioned is mostly a side thought. Risking being incorrect here, but I thought with ILGPU using CPU device means you can use .NET debugger to debug your code, which is a huge advantage.

ILGPU's main brilliancy though is support for most interesting platforms: Windows, Linux, MacOS, and maybe even Android (via opencl). Also, hopefully, Nvidia-based IoT boards (via CUDA and OCL).

DX12 coverage is way less, and only really brings XBox to the table.

I am not saying your project is bad. It is also brilliant! I would love to work on it too, if days had just over 32-36 hours instead of 24 :-) But as a consumer of .NET open source package ecosystem, it would be MUCH better not to write GPGPU code twice using one library first for Mac, Linux and Android, and then again using another library for XBox (either works on Windows).

So I am asking you to be open minded here and seriously consider joining ILGPU project.

P.S. personally, I found ILGPU a few months ago, and I am in no way part of the project (yet).