TEteleforce·Mar 24, 2024Submission
DCompute: Native execution of D on GPUs and other Accelerators
2 points · Open discussionlibmir
dcompute
D2017–2024
libmir / dcompute
dcompute
DCompute: Native execution of D on GPUs and other Accelerators
5Distinct people
13Mentions
0Explicit recommenders
144GitHub stars
What to know before exploring
What it is
DCompute: Native execution of D on GPUs and other Accelerators
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year13 dated mentions
Observed mentions: 2017-02-28 07:30:34 UTC to 2024-03-24 15:19:14 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 1 | 1 |
What Hacker News says
13 sourcesI almost spew my coffee when reading your grand parent comments.
One of the first teams that ported LAPACK to CUDA or CULA are apparently being paid handsomely by Nividia [1],[2].
Interestingly, DCompute is a little known effort to support compute on CUDA and OpenCL in D language, and it was done by a part-time undergrad student [3].
I strongly believe we need a very capable language to make advancement much easier in HPC/AI/etc, and D language fit the bill very much and then some. Heck it even beat other BLAS libraries that other so called data languages namely Matlab and Julia still heavily depended on for their performances to this very day. It does it in style back in 2016 more than seven years ago [4]. The DCompute implementation by the part-timer in 2017 actually depended on this native D implementation of these linear algebra rout
Read the rest
ines in Mir [5].
[1] CULA: hybrid GPU accelerated linear algebra routines:
https://www.spiedigitallibrary.org/conference-proceedings-of...
[2] CUDA Spotlight: John Humphrey:
https://www.nvidia.com/content/cuda/spotlights/john-humphrey...
[3] DCompute: GPGPU with Native D for OpenCL and CUDA:
https://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-native...
[4] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen:
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
[5] DCompute: Native execution of D on GPUs and other Accelerators:
https://github.com/libmir/dcompute
Shameless plug: LDC (the LLVM based D compiler) can already target CUDA (and OpenCL) and wraps its API and all of the nasty details involved in replicating <<<>>> kernel launches with https://github.com/libmir/dcompute/ with a sane syntax that's type safe. LLVM handles the codegen, and all of the "magic" is done in the library.
In Let's learn D game programming development (2021) [video]As noted elsewhere it seems your experience is somewhat outdated: the releases of the LLVM D Compiler (one of the two compilers worth using for production builds, the other being GDC) are buffered to the bugs introduced in DMD (which is more stable than it used to be although there are still regressions), and there is a fork based GC available for linux, but as the GC will only ever trigger on allocation, don't use it and it won't collect.
> While C++ is not by any means a great meta-language, it's improved considerably since that time.
C++ has also painted itself into a corner multiple times too, which despite being technically an improvement over the status quo are lacking severely in their utility. C++ screwed up "constexpr if" big time by always introducing a scope (which costs you a pair of {}'s in the rare occasion you need one) whi
Read the rest
ch means you can't conditionally insert declarations (i.e. variables, structs/classes, functions).
> but beyond the novelty you'd hardly find a mature or reliable codebase written by a team of professionals using hacks like [string manipulation and mixins].
They are a wonderful hack when you need them and nothing else will do what you want. This is not unlike resorting to macros in C++, except that its hygienic, unlike macros.
I'm not claiming the project is mature and I'm only one person, but reliable definitely out there. The most heinous set of string mixins i've ever written[1] has definitely got to be the code for generating wrappers to call the OpenCL object property querying functions (clGetDeviceInfo & friends). You need to pass a size and a void pointer to the address of the return object that you have to call once, twice or more (depending on the type of the queried property) to figure out how much memory you need to allocate to call it again.
The important thing is that the interface[2] you use to drive this code generation is very clean and return on investment for getting the generic case correct is large.
[1]: https://github.com/libmir/dcompute/blob/master/source/dcompu...
[2]: https://github.com/libmir/dcompute/blob/master/source/dcompu...
there is DCompute for writing D programs on the GPU: https://github.com/libmir/dcompute
it's pretty awesome
In Why I Like Dlinks for the curious: https://github.com/libmir/dcompute/
In Unified Shader Programming in C++It a mix of SPIR/PTX backends for LLVM and proprietary toolchains.
Java,
https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/...
http://www.jcuda.de/
https://clojurecuda.uncomplicate.org/
Haskell
Accelerate, http://www.acceleratehs.org/
Obsidian, https://github.com/svenssonjoel/Obsidian
.NET
Hybridizer , http://www.altimesh.com/hybridizer-essentials/,
Alea GPU, http://www.quantalea.com/
NMmath, https://www.centerspace.net/nmath-premium/
D,
DCompute, https://github.com/libmir/dcompute
Julia,
JuliaGPU, https://github.com/JuliaGPU
In Futhark 0.9.1 released – now with CUDA backendThere is DCompute[1] which is able to generate SPIR-V and PTX simultaneously from the same D source. See my comment to the parent.
http://github.com/libmir/dcompute
In Intel to Develop Discrete GPUs, Hires AMD's Raja Koduri as Chief ArchitectThere is no reason that you can't create both OpenCL (i.e. SPIR-V) and PTX from the same source. Thats what I do for [DCompute](https://github.com/libmir/dcompute). Agnosticism at the library level/CPU side is next on my list.
In Intel to Develop Discrete GPUs, Hires AMD's Raja Koduri as Chief ArchitectIDK about Cython, but I remember a blog post using Python's AST reflection to jit to LLVM ->NVPTX -> PTX. It's relatively simple to do, I've done it for LDC/D/DCompute[1,2,3]. It's a little tricker if you want to be able to express shared memory surfaces & textures, but it should still be doable.
[1] https://github.com/ldc-developers/ldc
[2] dlang.org
[3] http://github.com/libmir/dcompute
In High-Performance GPU Computing in the Julia Programming LanguageI am working on [dcompute](https://github.com/libmir/dcompute) which I hope will bring an equivalent experience when running on OpenCL and CUDA, and being written in D will provide all the advantages it does to writing kernels as it does with writing host code (with of course the ability to share compile time information across host and device). I believe that this levelling of the playing field will let the best hardware win.
If you have any question, please ask!
In Which GPU(s) to Get for Deep LearningI am the author of DCompute, a compiler/library/runtime framework for abstracting OpenCL/CUDA for D. You can write kernels already, although the API automation is still a work in progress.
I'm hoping that this should level the field a bit, because let's face it, people use CUDA for two reasons: the OpenCL driver API sucks; and the utility libraries (cuDNN et al) for CUDA. Possibly driver quality as well.
By having an API thats not horrible to use, that advantage is gone. The utility libraries will be more of a challenge to undermine, but since it targets CUDA natively there is no disadvantage to users of nvidia's hardware, but there is no advantage to others, yet (see GLAS[1] for what is possible with relative ease). Using D as the kernel language will also bring significant advantages over C/C++, static reflection, sane templates and co
Read the rest
mpile time code generation to name a few.
You can find it at https://github.com/libmir/dcompute.
If you have any question, please ask!
[1] https://github.com/libmir/mir-glas
DCompute – Native heterogeneous computing for D – is here
2 points · Open discussion