On Thursday, 13 January 2022 at 21:13:11 UTC, jmh530 wrote:

For some data to be @safe-ly accessible across threads it must have no "unshared aliasing", meaning that shared(const(T)) and immutable(T) are ok, but simply T and const(T) are not.

The reason why the .parallel example above was not safe, is because the body of the foreach was passed as a delegate to the ParallelForeach.opApply and the problem is that delegates can access unshared mutable data through their closure. If the @safe-ty holes regarding delegates are closed, presumably we could add a ParallelForeach.opApply overload that took a @safe delegate and then the whole main function could be marked as @safe.

I think back when the module was under active development, the authors did carefully consider the @safe-ty aspects, as they have written code that conditionally enables some function overloads to be @trusted, depending on the parameters they receive. But in the end it was the best they could given the state of the language at the time. Most likely the situation has improved sufficiently that more the of the API could be made (at least conditionally) @safe.

You can check the various comments explaining the situation:

• https://github.com/dlang/phobos/blob/v2.098.1/std/parallelism.d#L32-L34
• https://github.com/dlang/phobos/blob/v2.098.1/std/parallelism.d#L3382-L3395
• https://github.com/dlang/phobos/blob/v2.098.1/std/parallelism.d#L254-L261

On Thursday, 13 January 2022 at 21:44:13 UTC, H. S. Teoh wrote:

There are two DIPs that aim to address the attribute propagation problem:

• Argument dependent attributes (ADAs) by @Geod24: https://github.com/Geod24/DIPs/blob/adas/DIPs/DIP4242.md

• Attributes for Higher-Order Functions by @Bolpat: https://github.com/Bolpat/DIPs/blob/AttributesHOF/DIPs/DIP-1NN4-QFS.md

On Thursday, 13 January 2022 at 21:39:07 UTC, Bruce Carneal wrote:

Yes, that is not a good situation…

The caveat is that if fewer people use dcompute, then fewer people will help out with it, then it will take more time to reach a state where it is "ready"…

Showing how/when dcompute improves performance on standard desktop computers might make more people interested in participating.

Are there some performance benchmarks on modest hardware? (e.g. a standard macbook, imac or mac mini) Benchmarks that compares dcompute to CPU with auto-vectorization (SIMD)?

On Thursday, 13 January 2022 at 20:38:19 UTC, Bruce Carneal wrote:

As a former GPGPU guy: can you explain in what ways dcompute improves life over using CUDA and OpenCL through DerelictCL/DerelictCUDA (I used to maintain them and I think nobody ever used them). Using the API directly seems to offer the most control to me, and no special compiler support.

On Thursday, 13 January 2022 at 21:51:10 UTC, Petar Kirov [ZombineDev] wrote:

Thanks for the detailed explanation.

On Thursday, 13 January 2022 at 21:06:45 UTC, Ola Fosheim Grøstad wrote:

I suppose that's my fault for not marketing more, the code generation is tested in LDC's CI pipelines so that is unlikely to break, and the library is built on slow moving APIs that are also unlikely to break. Just because it doesn't get a lot of commits doesn't mean its going to stop working.

As for specification, I think that would be a wasted effort and too constraining. On the compiler side, it is mostly using the existing LDC infrastructure with (more than) a few hacks to get everything to stick together, and it is heavily dependant on LDC and LLVM internals to be part of the D spec. On the runtime side of it, I fear specification would either be too constraining or end up out of sync with the implementation.

On Thursday, 13 January 2022 at 23:28:01 UTC, Guillaume Piolat wrote:

It is entirely possible to use dcompute as simply a wrapper over OpenCL/CUDA and benefit from the enhanced usability that it offers (e.g. querying OpenCL API objects for their properties is faaaar simpler and less error prone with dcompute) because it exposes the underlying API objects 1:1, and you can always get the raw pointer and do things manually if you need to. Also dcompute uses DerelictCL/DerelictCUDA underneath anyway (thanks for them!).

If you're thinking of "special compiler support" as what CUDA does with its <<<>>>, then no, dcompute does all of that, but not with special help from the compiler, only with what meta programming and reflection is available to any other D program.
It's D all the way down to the API calls. Obviously there is special compiler support to turn D code into compute kernels.

The main benefit of dcompute is turning kernel launches into type safe one-liners, as opposed to brittle, type unsafe, paragraphs of code.

On Thursday, 13 January 2022 at 23:28:01 UTC, Guillaume Piolat wrote:

For me there were several things, including:

1. the dcompute kernel invocation was simpler, made more sense, letting me easily create invocation abstractions to my liking (partially memoized futures in my case but easy enough to do other stuff)

2. the kernel meta programming was much friendlier generally, of course.

3. the D nested function capability, in conjunction with better meta programming, enabled great decomposition, intra kernel. You could get the compiler to keep everything within the maximum-dispatch register limit (64) with ease, with readable code.

4. using the above I found it easy to reduce/minimize memory traffic, an important consideration in that much of my current work is memory bound. Trivial example: use static foreach to logically unroll a window neighborhood algorithm eliminating both unnecessary loads and all extraneous reg-to-reg moves as you naturally mod around.

It's not that you that you can't do such things in CUDA/C++, eventually, sometimes, after quite a bit of discomfort, once you acquire your level-bazillion C++ meta programming merit badge, it's that it's all so much easier to do in dcompute. You get to save the heroics for something else.

I'm sure that new idioms/benefits will emerge with additional use (this was my first dcompute project) but, as you will have noticed :-), I'm already hooked.

WRT OpenCL I don't have much to say. From what I gather people consider OpenCL to be even less hospitable than CUDA, preferring OpenCL mostly (only?) for its non-proprietary status. I'd be interested to hear from OpenCL gurus on this topic.

Finally, if any of the above doesn't make sense, or you'd like to discuss it further, I suggest we meet up at beerconf. I'd also love to talk about data parallel latency sensitive coding strategies, about how we should deal with HW capability variation, about how we can introduce data parallelism to many more in the dlang community, ...