March 11, 2022 Re: The problem that took him 5 years to fix in C++, I solved in a minute with D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to H. S. Teoh | On Thursday, 10 March 2022 at 20:25:12 UTC, H. S. Teoh wrote: >
| |||
March 10, 2022 Re: The problem that took him 5 years to fix in C++, I solved in a minute with D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to zjh | On Fri, Mar 11, 2022 at 01:35:46AM +0000, zjh via Digitalmars-d wrote: [...] > `D` has no `C++`'s collapse expression. > And It is orthogonal to the '[]' index. Why not add it in d? > `...` Folding expression, is very powerful. > With its help, they can complete powerful metaprogramming like d. I'm not the one you have to convince; talk to Walter or submit a DIP. :-) T -- Food and laptops don't mix. | |||
March 11, 2022 Re: The problem that took him 5 years to fix in C++, I solved in a minute with D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Paulo Pinto | On Thursday, 10 March 2022 at 15:49:36 UTC, Paulo Pinto wrote:
> C# metaprogramming is called T4 templates, Roslyn plug-ins, compiler attributes, reflection and code generators.
>
> Are they clunkier than D?
>
> Surely, however C# comes with Unity (what happened to Remedy?), Orleans, CUDA (including GPGPU debugging), IoT (Meadows), Cloud SDKs for GCP/AWS/Azure, Blazor, Uno, MAUI,....
>
> D, well it has MIR and vibe.d, that is about it.
I feel compelled to mention dcompute here as a competitor for CUDA. It is a substitute for the kernel language and the runtime is just as easy to use. It can run on CUDA ( as a backend) so all the same tools will work including debugging (modulo probably demangling support).
| |||
March 11, 2022 Re: The problem that took him 5 years to fix in C++, I solved in a minute with D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Paul Backus | On 10.03.22 12:52, Paul Backus wrote:
>
> Reminds me of this CppCon talk by Andrei Alexandrescu that was posted in the community Discord recently:
>
> https://youtu.be/va9I2qivBOA
Nice talk, but the explanation why there is a quadratic number of template instantiations for `destroyLog` seems to be wrong.
`destroyLog` itself is actually only instantiated a linear number of times. In particular, it is not true that it is instantiated with every combination of `lo` and `hi` where `0≤lo<hi≤n`. Most of them are never reached.
E.g., n=8, recursion tree of (lo,hi)-arguments:
```
(0,8)
/ \
(0,4) (4,8)
/ \ / \
(0,2) (2,4) (4,6) (6,8)
/ \ / \ / \ / \
(0,1) (1,2) (2,3) (3,4) (4,5) (5,6) (6,7) (7,8)
```
Of course, the number of instantiated templates is indeed quadratic because each static index operation instantiates a linear number of templates and there are n index operations.
There is also something weird going on with the computation of the middle point:
```c++
constexpr size_t m = lo + (hi + low)/2;
```
This should be
```c++
constexpr unsigned m = lo + (hi - lo)/2;
```
(Or just (lo + hi)/2, I highly doubt this is ever going to wrap around :o). )
The following glorious hack avoids the linear indexing by consuming each element in the type sequence exactly once, when it is needed. The template parameter Ts is a type_sequence and the automatically deducted function return type is Ts[hi - lo .. $].
This only causes a linear number of template instantiations.
```c++
template<unsigned lo,unsigned hi,typename Ts>
auto destroyLog(unsigned i,void *p){
static_assert(lo < hi);
assert(lo <= i && i < hi);
if constexpr (lo + 1 != hi) {
constexpr unsigned m = lo + (hi - lo)/2;
using Rs = decltype(destroyLog<lo, m, Ts>(i, p));
if (i < m){
destroyLog<lo, m, Ts>(i, p);
return decltype(destroyLog<m, hi, Rs>(i, p))();
} else {
return destroyLog<m, hi, Rs>(i, p);
}
} else{
using T = typename head<Ts>::type;
static_cast<T*>(p)->~T();
return typename tail<Ts>::type();
}
}
```
| |||
March 11, 2022 Re: The problem that took him 5 years to fix in C++, I solved in a minute with D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Nicholas Wilson | On Friday, 11 March 2022 at 04:03:50 UTC, Nicholas Wilson wrote: > On Thursday, 10 March 2022 at 15:49:36 UTC, Paulo Pinto wrote: >> C# metaprogramming is called T4 templates, Roslyn plug-ins, compiler attributes, reflection and code generators. >> >> Are they clunkier than D? >> >> Surely, however C# comes with Unity (what happened to Remedy?), Orleans, CUDA (including GPGPU debugging), IoT (Meadows), Cloud SDKs for GCP/AWS/Azure, Blazor, Uno, MAUI,.... >> >> D, well it has MIR and vibe.d, that is about it. > > I feel compelled to mention dcompute here as a competitor for CUDA. It is a substitute for the kernel language and the runtime is just as easy to use. It can run on CUDA ( as a backend) so all the same tools will work including debugging (modulo probably demangling support). What is dcompute answer to Hybridizer alongsiside Visual Studio and Nsights? https://developer.nvidia.com/blog/hybridizer-csharp/ https://developer.nvidia.com/nsight-visual-studio-edition | |||
March 11, 2022 Re: The problem that took him 5 years to fix in C++, I solved in a minute with D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Ali Çehreli | On Thursday, 10 March 2022 at 18:47:51 UTC, Ali Çehreli wrote: >To respond to another point in this thread, I am not embarrassed to admit that I am emotional. I actually like to be emotional. Thank you very much! :) Well, I've never been emotional in these forums, except when some people recently objected to a no-war icon. I showed the icon to my daughter and told her that "when it matters technologists seize to be narrow-minded and see the bigger picture", then the disappointment in the D community's the-lets-not-take-a-stance-on-even-the-most-obvious-attitude surfaced and I had to apologise to her and let her know that the narrowmindedness of technologists actually is deep, they are usually not very good at seeing the bigger picture. The only interesting thing about this thread in relation to C++ and constexpr is this: they have a process. When they add a new feature they introduce it in a minimal state, then wait for users to gain experience with it and extend bit by bit in subsequent versions. This is true for constexpr, coroutines and many other features. This brings some advantages:
This is all in line with good language evolution policies. D has string mixins and they require compile time string concatenation, without string mixins the demand for dynamic compile time string concatenation is not very high in the context of system level programming. So it made sense to first support a fixed container like array (high demand because of LUT building), wait with the addition of basic_string/vector to C++20, then we'll have to see if there are further improvements in C++23/26. I personally only need constexpr array in C++, and more frequently end up with my own string representations anyway (typical of lower level programming). If you plan on using C++ for higher level programming than dsp/engines you'll be disappointed, but that disappointment goes much deeper than any individual feature. C++ cannot become a glorified scripting language, nor should it try to be. It should focus on the strong points it has, and so should D. But D needs to learn something about process from C++. Take a step away from the the-lets-not-take-a-stance-on-even-the-most-obvious-attitude, get some clear focus and make priorities. You actually have to choose between:
D's current approach is "experimental language evolution based on creativity without breaking changes" and that is not a sustainable model in the long term. | |||
March 11, 2022 Re: The problem that took him 5 years to fix in C++, I solved in a minute with D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Paulo Pinto | On Friday, 11 March 2022 at 06:41:37 UTC, Paulo Pinto wrote: >On Friday, 11 March 2022 at 04:03:50 UTC, Nicholas Wilson wrote: >On Thursday, 10 March 2022 at 15:49:36 UTC, Paulo Pinto wrote: >C# metaprogramming is called T4 templates, Roslyn plug-ins, compiler attributes, reflection and code generators. Are they clunkier than D? Surely, however C# comes with Unity (what happened to Remedy?), Orleans, CUDA (including GPGPU debugging), IoT (Meadows), Cloud SDKs for GCP/AWS/Azure, Blazor, Uno, MAUI,.... D, well it has MIR and vibe.d, that is about it. I feel compelled to mention dcompute here as a competitor for CUDA. It is a substitute for the kernel language and the runtime is just as easy to use. It can run on CUDA ( as a backend) so all the same tools will work including debugging (modulo probably demangling support). What is dcompute answer to Hybridizer alongsiside Visual Studio and Nsights? I enjoyed the pretty graphs and summaries produced by Nsight back in my CUDA days but I was then, and still am, more interested in the leverage provided by language directly. That said, we can add tooling, and we should. For all I know hooking dcompute code into Nsight, for example, may be as easy as running under a C++ main and linking with nvcc. I plan to pitch in on dcompute myself after the current project and enabling Nsight seems like a good place to start (maybe someone has already done it, I've not looked for it...) dcompute can be improved but in my experience it is, already, head and shoulders above C++ when it comes to producing readable, performant, kernels quickly. OTOH, if you're a total tool fanboy you're probably better off with something else, at least for now. I've not tried Csharp on GPUs, hybridizer or otherwise. Was the GPU meta programming capability there not too "clunky"? How did your performance compare to well crafted C++/CUDA implementations? | |||
March 11, 2022 Re: The problem that took him 5 years to fix in C++, I solved in a minute with D | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | On Friday, 11 March 2022 at 06:41:37 UTC, Paulo Pinto wrote:
> What is dcompute answer to Hybridizer alongsiside Visual Studio and Nsights?
>
> https://developer.nvidia.com/blog/hybridizer-csharp/
>
> https://developer.nvidia.com/nsight-visual-studio-edition
Hybridizer, seems to be the MSIL equivalent of dcompute.
As for VS, there is VisualD, and failing that you can get a lot of milage from pretending to be C++ and using the regular debugging tools for CUDA when you use the CUDA backend of dcompute.
I've not used NSight, but I don't see why it couldn't be used with VisualD.
| |||
March 14, 2022 Re: The problem that took him 5 years to fix in C++, I solved in a minute with D | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Bruce Carneal | On Friday, 11 March 2022 at 09:37:41 UTC, Bruce Carneal wrote: >On Friday, 11 March 2022 at 06:41:37 UTC, Paulo Pinto wrote: >On Friday, 11 March 2022 at 04:03:50 UTC, Nicholas Wilson wrote: >On Thursday, 10 March 2022 at 15:49:36 UTC, Paulo Pinto wrote: >C# metaprogramming is called T4 templates, Roslyn plug-ins, compiler attributes, reflection and code generators. Are they clunkier than D? Surely, however C# comes with Unity (what happened to Remedy?), Orleans, CUDA (including GPGPU debugging), IoT (Meadows), Cloud SDKs for GCP/AWS/Azure, Blazor, Uno, MAUI,.... D, well it has MIR and vibe.d, that is about it. I feel compelled to mention dcompute here as a competitor for CUDA. It is a substitute for the kernel language and the runtime is just as easy to use. It can run on CUDA ( as a backend) so all the same tools will work including debugging (modulo probably demangling support). What is dcompute answer to Hybridizer alongsiside Visual Studio and Nsights? I enjoyed the pretty graphs and summaries produced by Nsight back in my CUDA days but I was then, and still am, more interested in the leverage provided by language directly. That said, we can add tooling, and we should. For all I know hooking dcompute code into Nsight, for example, may be as easy as running under a C++ main and linking with nvcc. I plan to pitch in on dcompute myself after the current project and enabling Nsight seems like a good place to start (maybe someone has already done it, I've not looked for it...) dcompute can be improved but in my experience it is, already, head and shoulders above C++ when it comes to producing readable, performant, kernels quickly. OTOH, if you're a total tool fanboy you're probably better off with something else, at least for now. I've not tried Csharp on GPUs, hybridizer or otherwise. Was the GPU meta programming capability there not too "clunky"? How did your performance compare to well crafted C++/CUDA implementations? I guess it is good enough to keep their business going, http://www.altimesh.com/ | |||
March 14, 2022 Re: The problem that took him 5 years to fix in C++, I solved in a minute with D | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | On Monday, 14 March 2022 at 00:42:34 UTC, Paulo Pinto wrote: >On Friday, 11 March 2022 at 09:37:41 UTC, Bruce Carneal wrote: >On Friday, 11 March 2022 at 06:41:37 UTC, Paulo Pinto wrote: I guess it is good enough to keep their business going, http://www.altimesh.com/ Indeed. Business success with a language pretty much closes out the "is the language good enough" argument (for successful dlang companies as well of course). Still, I thought we were addressing comparative benefit rather than "good enough". Concretely, I prefer dcompute to my former GPU development language, C++/CUDA: quicker development, more readable, easier to make non-trivial kernels "live in registers", better launch API, ... Since I've not used C# at all I'd like to hear from those who have. If you know of any C# GPU programmers with reasoned opinions about dlang/dcompute, good or bad, please ask them to comment. | |||
Permalink
Reply
