Thread overview
Calling D from Ruby for GPU computing
July 25
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
July 26
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.
July 26
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


July 26
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-for-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
July 26
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