Re: DCompute is now in the master branch of LDC
On Tuesday, 30 May 2017 at 02:46:12 UTC, Walter Bright wrote: On 5/29/2017 6:10 PM, Nicholas Wilson wrote: there are also GitHub topics [1] which I will also properly fill out. I just done a pass over the README.md [1]: https://github.com/blog/2309-introducing-topics Good. Making the content google-friendly is also extremely important. Back in the early daze of D, I knew that "D" was not google-able, so I was careful to always have the phrase "D programming language" somewhere in text about D, and I'd harangue others to do the same. Since google knows about "D" now, this is less important. I suspect that this will have less of an effect dcompute as "dcompute" is likely to have a far greater signal to noise ratio than "D" in its infancy simply due to its frequency on the web, but I take your point. I also plan on getting the documentation up to snuff because I know the effect that will have. I have experience learning with OpenCL (less successful, confusing documentation) and CUDA (more successful, coherent documentation). Yes there are other reasons as to the relative successes of OpenCL vs CUDA, but if we are trying to take marketshare from OpenCL and CUDA of both new and experienced users of heterogenous computing good documentation will go a long way.
Re: DCompute is now in the master branch of LDC
On 5/29/2017 6:10 PM, Nicholas Wilson wrote: there are also GitHub topics [1] which I will also properly fill out. I just done a pass over the README.md [1]: https://github.com/blog/2309-introducing-topics Good. Making the content google-friendly is also extremely important. Back in the early daze of D, I knew that "D" was not google-able, so I was careful to always have the phrase "D programming language" somewhere in text about D, and I'd harangue others to do the same. Since google knows about "D" now, this is less important.
Re: DCompute is now in the master branch of LDC
On Tuesday, 30 May 2017 at 00:12:51 UTC, Walter Bright wrote: On 5/29/2017 3:52 PM, Nicholas Wilson wrote: How about calling it D-GPU ? I bet you'd get a lot more clicks on a name like that. Thanks, I called it dcompute because naming things is right up there with cache invalidation. Calling it D-GPU would be misleading because there should be no reason you can't use the generated SPIRV on DSPs, FPGAs and whatever else there is an OpenCL runtime for. From https://github.com/libmir/dcompute : "This project is a set of libraries designed to work with a modified ldc to enable native execution of D on GPUs (and other more exotic target of OpenCL, hereafter just 'GPUs')." OK, I should probably reword that. The clicks should be rectifiable with a good title and description. Many years ago, D immutable types were called 'invariant'. People always asked what invariant meant, and we'd reply "invariant types are immutable" and then they'd understand. After going through that for the thousandth time, we renamed 'invariant' to 'immutable', and the questions ceased. The trouble is, all I usually see is simply "DCompute". I have to click on a link or do some searching to see what it is for. There's nothing to suggest that it's for me if I'm interested in using D for FPGA programming. Google isn't going to index it under "FPGA". I'm sorry about being pushy about this, but I really want DCompute to succeed, and the current name will impair this. Having the right name and branding is extremely important. A descriptive title could be: "D-GPU: native D code running on GPUs, FPGAs and DSPs" Well the GitHub project description is "Native execution of D on GPUs" I don't want to do false advertising for features that I don't have yet but I will update to reflect this, I'll be surprised if google doesn't pick up on 'dlang fpga' along with DHDL. there are also GitHub topics [1] which I will also properly fill out. I just done a pass over the README.md [1]: https://github.com/blog/2309-introducing-topics
Re: DCompute is now in the master branch of LDC
On 5/29/2017 3:52 PM, Nicholas Wilson wrote: How about calling it D-GPU ? I bet you'd get a lot more clicks on a name like that. Thanks, I called it dcompute because naming things is right up there with cache invalidation. Calling it D-GPU would be misleading because there should be no reason you can't use the generated SPIRV on DSPs, FPGAs and whatever else there is an OpenCL runtime for. From https://github.com/libmir/dcompute : "This project is a set of libraries designed to work with a modified ldc to enable native execution of D on GPUs (and other more exotic target of OpenCL, hereafter just 'GPUs')." The clicks should be rectifiable with a good title and description. Many years ago, D immutable types were called 'invariant'. People always asked what invariant meant, and we'd reply "invariant types are immutable" and then they'd understand. After going through that for the thousandth time, we renamed 'invariant' to 'immutable', and the questions ceased. The trouble is, all I usually see is simply "DCompute". I have to click on a link or do some searching to see what it is for. There's nothing to suggest that it's for me if I'm interested in using D for FPGA programming. Google isn't going to index it under "FPGA". I'm sorry about being pushy about this, but I really want DCompute to succeed, and the current name will impair this. Having the right name and branding is extremely important. A descriptive title could be: "D-GPU: native D code running on GPUs, FPGAs and DSPs"
Re: "Programming in D" is up-to-date
On 05/29/2017 03:06 PM, Wulfklaue wrote: > The book is great ( got it recently ) but there are some things that may > make be better. Thank you for your feedback. :) > 87 in memory management the > experimental unsafe memory management is not written about. Yes, there are things I would like to add (and change) but it's not clear whether I will ever be in a state of mind to carry on with such a task. It felt very natural while it lasted. I'm not sure anymore. > But if you > want to make follow up chapters, it requires people to rebuy the > newer book. Yes and no, because all the material would always be available anyway. > Is it maybe not better to split the book into several more smaller > versions? Making it more easy to carry or extend? Like Basic 1, Advanced > 2, ... Makes sense and others had suggested that as well. One complication would be different cover design for each book. (Even if not the general concept, the book cover image is for that specific number of pages (with some leeway)). > And a last one: coloring... My vision is not exactly the best and i > noticed that colored code is much more easy to read in books. If there > the possibility for a colored ( more expensive ) version in the future? There was no option of color printing when I considered printers (or perhaps it was too expensive to even consider; I don't remember). However, if you can live with the pdf version of the book, the code samples are in color: http://ddili.org/ders/d.en/Programming_in_D.pdf It's the same content and format as the printed book, except it is generated from a different CSS file. Ali
Re: DCompute is now in the master branch of LDC
On Monday, 29 May 2017 at 20:36:26 UTC, Walter Bright wrote: On 5/29/2017 2:33 AM, Nicholas Wilson wrote: Hi all, I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my fork[1] of LLVM for SPIRV. Someone (sorry I've forgotten who!) at dconf said they'd make a docker image of the dependencies (ldc llvm), if you're reading please let me know! Or if someone else wants to do it thats good too. I'm still quite busy until July (honours thesis), but if anyone wanting to contribute to either the runtime stuff [2](all D), LDC [3] or LLVM [1](mostly C++) I'm happy to answer any questions, providing testing and performance feedback on diverse systems is also appreciated. Feel free to drop a line at https://gitter.im/libmir/public [1]: https://github.com/thewilsonator/llvm/tree/compute [2]: https://github.com/libmir/dcompute [3]: https://github.com/ldc-developers/ldc Congratulations! This is great work, and a great contribution. May I suggest, however, that the name DCompute is a bit generic, and provides no hint that it provides GPU programming for D. How about calling it D-GPU ? I bet you'd get a lot more clicks on a name like that. Thanks, I called it dcompute because naming things is right up there with cache invalidation. Calling it D-GPU would be misleading because there should be no reason you can't use the generated SPIRV on DSPs, FPGAs and whatever else there is an OpenCL runtime for. The clicks should be rectifiable with a good title and description.
Re: "Programming in D" is up-to-date
Hi Ali, The book is great ( got it recently ) but there are some things that may make be better. I found the book a bit unwieldy ( hardcover ) version. With its 700+ pages, its kind of hard to take anywhere. When i take it to work and back home, its like carrying a brick with me :) Another issue that i noticed is that the current format makes it impossible to extend the book. For example, 87 in memory management the experimental unsafe memory management is not written about. But if you want to make follow up chapters, it requires people to rebuy the newer book. Is it maybe not better to split the book into several more smaller versions? Making it more easy to carry or extend? Like Basic 1, Advanced 2, ... And a last one: coloring... My vision is not exactly the best and i noticed that colored code is much more easy to read in books. If there the possibility for a colored ( more expensive ) version in the future?
Re: DCompute is now in the master branch of LDC
On 29/05/2017 10:52 AM, Nicholas Wilson wrote: On Monday, 29 May 2017 at 09:39:53 UTC, rikki cattermole wrote: On 29/05/2017 10:33 AM, Nicholas Wilson wrote: Hi all, I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my fork[1] of LLVM for SPIRV. Someone (sorry I've forgotten who!) at dconf said they'd make a docker image of the dependencies (ldc llvm), if you're reading please let me know! Or if someone else wants to do it thats good too. I'm still quite busy until July (honours thesis), but if anyone wanting to contribute to either the runtime stuff [2](all D), LDC [3] or LLVM [1](mostly C++) I'm happy to answer any questions, providing testing and performance feedback on diverse systems is also appreciated. Feel free to drop a line at https://gitter.im/libmir/public [1]: https://github.com/thewilsonator/llvm/tree/compute [2]: https://github.com/libmir/dcompute [3]: https://github.com/ldc-developers/ldc Can someone please write up a post e.g. for the D blog to act as the official announcement (with a quick tutorial)? That way we can announce it to the wider programming community. I promised Mike a blog post at dconf, but I'd prefer this to be done after I hand in my thesis, so that I can: a) concentrate on it and b) keep the ball rolling after it is announced. I will be working for Laeeth next semester with some time reserved for dcompute and much more time available as I'll only be doing one (or possibly two units, with a lot of time waiting for tanks to reach steady state). Plus I think if people start to get familiar with the project then the efforts will be much more coordinated once the announcement is made and therefore by perception more attractive to potential users not already familiar with D. Ok so announce only within D community atm. Good to know :)
Re: DCompute is now in the master branch of LDC
On Monday, 29 May 2017 at 09:39:53 UTC, rikki cattermole wrote: On 29/05/2017 10:33 AM, Nicholas Wilson wrote: Hi all, I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my fork[1] of LLVM for SPIRV. Someone (sorry I've forgotten who!) at dconf said they'd make a docker image of the dependencies (ldc llvm), if you're reading please let me know! Or if someone else wants to do it thats good too. I'm still quite busy until July (honours thesis), but if anyone wanting to contribute to either the runtime stuff [2](all D), LDC [3] or LLVM [1](mostly C++) I'm happy to answer any questions, providing testing and performance feedback on diverse systems is also appreciated. Feel free to drop a line at https://gitter.im/libmir/public [1]: https://github.com/thewilsonator/llvm/tree/compute [2]: https://github.com/libmir/dcompute [3]: https://github.com/ldc-developers/ldc Can someone please write up a post e.g. for the D blog to act as the official announcement (with a quick tutorial)? That way we can announce it to the wider programming community. I promised Mike a blog post at dconf, but I'd prefer this to be done after I hand in my thesis, so that I can: a) concentrate on it and b) keep the ball rolling after it is announced. I will be working for Laeeth next semester with some time reserved for dcompute and much more time available as I'll only be doing one (or possibly two units, with a lot of time waiting for tanks to reach steady state). Plus I think if people start to get familiar with the project then the efforts will be much more coordinated once the announcement is made and therefore by perception more attractive to potential users not already familiar with D.
Re: DCompute is now in the master branch of LDC
On 29/05/2017 10:33 AM, Nicholas Wilson wrote: Hi all, I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my fork[1] of LLVM for SPIRV. Someone (sorry I've forgotten who!) at dconf said they'd make a docker image of the dependencies (ldc llvm), if you're reading please let me know! Or if someone else wants to do it thats good too. I'm still quite busy until July (honours thesis), but if anyone wanting to contribute to either the runtime stuff [2](all D), LDC [3] or LLVM [1](mostly C++) I'm happy to answer any questions, providing testing and performance feedback on diverse systems is also appreciated. Feel free to drop a line at https://gitter.im/libmir/public [1]: https://github.com/thewilsonator/llvm/tree/compute [2]: https://github.com/libmir/dcompute [3]: https://github.com/ldc-developers/ldc Can someone please write up a post e.g. for the D blog to act as the official announcement (with a quick tutorial)? That way we can announce it to the wider programming community.
DCompute is now in the master branch of LDC
Hi all, I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my fork[1] of LLVM for SPIRV. Someone (sorry I've forgotten who!) at dconf said they'd make a docker image of the dependencies (ldc llvm), if you're reading please let me know! Or if someone else wants to do it thats good too. I'm still quite busy until July (honours thesis), but if anyone wanting to contribute to either the runtime stuff [2](all D), LDC [3] or LLVM [1](mostly C++) I'm happy to answer any questions, providing testing and performance feedback on diverse systems is also appreciated. Feel free to drop a line at https://gitter.im/libmir/public [1]: https://github.com/thewilsonator/llvm/tree/compute [2]: https://github.com/libmir/dcompute [3]: https://github.com/ldc-developers/ldc
