www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Calling D from Ruby for GPU computing

reply Prasun Anand <prasunanand.bitsp gmail.com> writes:
Hi,

I wrote a Linear Mixed Model tool for Genome Wide Association 
Studies(GWAS) called
[faster_lmm_d](https://github.com/prasunanand/faster_lmm_d). It 
is built on LDC
and is faster than its Python alternative. Also, its the only 
GWAS tool with a GPU
backend.

I am interested in porting ` faster_lmm_d` to Ruby. Though, it is 
still a work in progress, I have written a blog about my findings.

Blog: 
http://www.prasunanand.com/gpu-computing/2017/07/25/gsoc17-calling-d-from-ruby-for-gpu-computing.html

I would love to hear your feedback.

Regards,
Prasun
Jul 25
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 25 July 2017 at 20:19:17 UTC, Prasun Anand wrote:
 Hi,

 I wrote a Linear Mixed Model tool for Genome Wide Association 
 Studies(GWAS) called
 [faster_lmm_d](https://github.com/prasunanand/faster_lmm_d). It 
 is built on LDC
 and is faster than its Python alternative. Also, its the only 
 GWAS tool with a GPU
 backend.

 I am interested in porting ` faster_lmm_d` to Ruby. Though, it 
 is still a work in progress, I have written a blog about my 
 findings.

 Blog: 
 http://www.prasunanand.com/gpu-computing/2017/07/25/gsoc17-calling-d-from-ruby-for-gpu-computing.html

 I would love to hear your feedback.

 Regards,
 Prasun
Pretty cool, any reason you didn't post this in announce instead? I'd be interested to hear your thoughts on ArrayFire as I'm looking for Ideas (not to mention feedback and projects!) for DCompute.
Jul 25
parent reply Prasun Anand <prasunanand.bitsp gmail.com> writes:
On Wednesday, 26 July 2017 at 01:14:56 UTC, Nicholas Wilson wrote:
 On Tuesday, 25 July 2017 at 20:19:17 UTC, Prasun Anand wrote:
 Hi,

 I wrote a Linear Mixed Model tool for Genome Wide Association 
 Studies(GWAS) called
 [faster_lmm_d](https://github.com/prasunanand/faster_lmm_d). 
 It is built on LDC
 and is faster than its Python alternative. Also, its the only 
 GWAS tool with a GPU
 backend.

 I am interested in porting ` faster_lmm_d` to Ruby. Though, it 
 is still a work in progress, I have written a blog about my 
 findings.

 Blog: 
 http://www.prasunanand.com/gpu-computing/2017/07/25/gsoc17-calling-d-from-ruby-for-gpu-computing.html

 I would love to hear your feedback.

 Regards,
 Prasun
Pretty cool, any reason you didn't post this in announce instead? I'd be interested to hear your thoughts on ArrayFire as I'm looking for Ideas (not to mention feedback and projects!) for DCompute.
Thanks Nicholas! I think ArrayFire is a great library and very promising. The abstractions it provides makes it very easy for GPU computing and in my opinion, these abstractions make the programmer too lazy to look under the hood and aim for better optimizations. ArrayFire being able to support CPU, OpenCL and CUDA all together is what makes it super awesome. I would be working on optimizations for CUDA backend of faster-lmm-d in near future, and I would be using dcompute a lot, to write the kernels in D. I posted this on LDC group as I would also like to pose a question to LDC community regarding **How do I bind D as a shared lib for ldc ? ** I am unable to find any good documentation regarding this. Regards, Prasun
Jul 25
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 26 July 2017 at 05:56:45 UTC, Prasun Anand wrote:
 On Wednesday, 26 July 2017 at 01:14:56 UTC, Nicholas Wilson 
 wrote:
 On Tuesday, 25 July 2017 at 20:19:17 UTC, Prasun Anand wrote:
 Hi,

 I wrote a Linear Mixed Model tool for Genome Wide Association 
 Studies(GWAS) called
 [faster_lmm_d](https://github.com/prasunanand/faster_lmm_d). 
 It is built on LDC
 and is faster than its Python alternative. Also, its the only 
 GWAS tool with a GPU
 backend.

 I am interested in porting ` faster_lmm_d` to Ruby. Though, 
 it is still a work in progress, I have written a blog about 
 my findings.

 Blog: 
 http://www.prasunanand.com/gpu-computing/2017/07/25/gsoc17-calling-d-from-ruby-for-gpu-computing.html

 I would love to hear your feedback.

 Regards,
 Prasun
Pretty cool, any reason you didn't post this in announce instead? I'd be interested to hear your thoughts on ArrayFire as I'm looking for Ideas (not to mention feedback and projects!) for DCompute.
Thanks Nicholas! I think ArrayFire is a great library and very promising. The abstractions it provides makes it very easy for GPU computing and in my opinion, these abstractions make the programmer too lazy to look under the hood and aim for better optimizations. ArrayFire being able to support CPU, OpenCL and CUDA all together is what makes it super awesome. I would be working on optimizations for CUDA backend of faster-lmm-d in near future, and I would be using dcompute a lot, to write the kernels in D.
Thanks, I'll keep that in mind. The OpenCL API is usable, I'm about halfway through the CUDA API and we will ba able to support both of them. I look forward to seeing what other people make with dcompute. I'm looking forward to using this in bioinformatics next semester.
 I posted this on LDC group as I would also like to pose a 
 question to LDC community regarding
I encourage you to post it there anyway, far fewer people read lists other than learn/general/announce and this is very interesting.
 **How do I bind D as a shared lib for ldc ? **
`ldc2 -shared files.d` should work
Jul 26
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-07-25 22:19, Prasun Anand wrote:
 Hi,
 
 I wrote a Linear Mixed Model tool for Genome Wide Association 
 Studies(GWAS) called
 [faster_lmm_d](https://github.com/prasunanand/faster_lmm_d). It is built 
 on LDC
 and is faster than its Python alternative. Also, its the only GWAS tool 
 with a GPU
 backend.
 
 I am interested in porting ` faster_lmm_d` to Ruby. Though, it is still 
 a work in progress, I have written a blog about my findings.
 
 Blog: 
 http://www.prasunanand.com/gpu-computing/2017/07/25/gsoc17-calling-d-from-ruby-fo
-gpu-computing.html 
 
 
 I would love to hear your feedback.
I would go with the approach of using the native C interface (ruby.h) from D. Perhaps add some wrappers to make the library simpler to use. I'm not sure about the garbage collector, if it's a good idea to use it or not. Note that anything that you return to the Ruby code would most likely need to be allocated using some functionality of ruby.h, to allocate the memory on the Ruby heap and not the D heap. -- /Jacob Carlborg
Jul 25