On Thursday, 13 January 2022 at 16:31:11 UTC, Tejas wrote:
On Thursday, 13 January 2022 at 14:24:59 UTC, Bruce Carneal wrote:
Yes. The language independent work in LLVM in the accelerator area is hugely important for dcompute, essential.
Sorry if this sounds ignorant, but does SPIR-V count for nothing?
SPIR-V is very useful. It is the catalyst and focal point of some of the most important ongoing LLVM accelerator work. Nicholas and I both believe that that work could provide a much more robust intermediate target for dcompute once it hits release status.
Gotta surf that wave as we don't have the manpower to go independent. I dont think anybody has that amount of manpower, hence the collaboration/consolidation around LLVM as a back-end for accelerators.
There was a time to try overthrow C++, that was 10 years ago, LLVM was hardly relevant and GPGPU computing still wasn't mainstream.
Yes. The "overthrow" of C++ should be a non-goal, IMO, starting yesterday.
Overthrowing may be hopeless, but I feel we should at least be a really competitive with them.
Sure. We need to offer something that is actually better, we just don't need to be perceived as better by everyone in all scenarios. An example: if management is deathly afraid of anything but microscopic incremental development or, more charitably, management weighs the risks of new development very very heavily, then D is unlikely to be given a chance.
Because it doesn't matter whether we're competing with C++ or not, people will compare us with it since that's the other choice when people will want to write extremely performant GPU code(if they care about ease of setup and productivity and not performance-at-any-cost, Julia and Python have beat us to it :-(
Yes. We should evaluate our efforts by comparing (competing) with alternatives where available. D/dcompute is already, for my GPU work at least, much better than CUDA/C++. Concretely: I can achieve equivalent or higher performance more quickly with more readable code than I could formerly with CUDA/C++. There are some things that are trivial in D kernels (like live-in-register/mem-bandwidth-minimized stencil processing) that would require "heroic" effort in CUDA/C++.
That said, there are definitely things that we could improve in the dcompute/accelerator area, particularly wrt the on-ramp for those new to accelerator programming. But, as you note, D is unlikely to be adopted by the "performance is good enough with existing solutions" crowd in any case. That's fine.