[Numpy-discussion] NumPy to CPU+GPU compiler, looking for tests

Frédéric Bastien nouiz@nouiz....
Tue Oct 23 10:41:11 CDT 2012


Did you saw the gpu nd array project? We try to do something similar
but only for the GPU.

https://github.com/inducer/compyte/wiki

Fred

On Sun, Oct 21, 2012 at 2:57 PM, Rahul Garg <rahulgarg44@gmail.com> wrote:
> Thanks! I need to add support for eig and inv (will do this week, at
> least for CPU) but other than that, I should definitely be able to
> handle those kinds of benchmarks.
>
> rahul
>
> On Sun, Oct 21, 2012 at 12:01 PM, Aron Ahmadia <aron@ahmadia.net> wrote:
>> Hi Rahul,
>>
>> Very cool!  I'm looking forward to seeing some performance results!  Anders
>> Logg posted a computational challenge to G+ about a month ago, and we got
>> entries in Octave, Fortran, Python, and Julia (all implementing the same
>> solution from Jed Brown).  The challenge is here:
>>
>> https://plus.google.com/116518787475147930287/posts/jiULACjiGnW
>>
>> Here is my simple attempt at Cythonizing Jed's Octave code:
>>
>> https://gist.github.com/3893361
>>
>> The best solution in Fortran took 38 microseconds.  The best Python solution
>> clocked in at around 445.  The Julia solution implemented by Jed took around
>> 224 microseconds, a good LLVM solution should come close to or beat that.
>>
>> Hope this helps.
>>
>> Aron
>>
>> On Sun, Oct 21, 2012 at 3:27 PM, Rahul Garg <rahulgarg44@gmail.com> wrote:
>>>
>>> Hi.
>>>
>>> I am a PhD student at McGill University and I am developing a compiler
>>> for Python for CPUs and GPUs. For CPUs, I build upon LLVM. For GPUs, I
>>> generate OpenCL and I have also implemented some library functions on
>>> the GPU myself. The restriction that it is only for numerical code and
>>> intended for NumPy users. The compiler is aware of simple things in
>>> NumPy like matrix multiplication, slicing operators, strided layouts,
>>> some library functions (though limited at this time) and the negative
>>> indexing semantics etc. However, the compiler is not limited to vector
>>> code. Scalar code or manually written loops also work. However, only
>>> numerical datatypes are supported with no support for lists, dicts,
>>> classes etc. First class functions are not currently supported but are
>>> on the roadmap. You will have to add some type annotations to your
>>> functions. If you have a compatible GPU, you can also use the GPU by
>>> indicating which parts to run on the GPU. Otherwise you can just use
>>> it to run your code on the CPU.
>>>
>>> As an example, simple scalar code like fibonacci function works fine.
>>> Simple loops like those used in stencil-type computations are also
>>> working. Parallel-for loops are also provided and working. Simple
>>> vector oriented code is also working fine on both CPU and GPU.  The
>>> system is being tested on Ubuntu 12.04 and tested with Python 2.7
>>> (though I think should work with other Python 2.x variants). For GPUs,
>>> I am ensuring that the system works with AMD and Nvidia GPUs.
>>>
>>> The compiler is in early stages and I am looking for test cases. The
>>> project will be open-sourced in November under Apache 2 and thereafter
>>> will be developed in an open repo. If you have some simple code that I
>>> can use as a benchmark that I can use to test and evaluate the
>>> compiler, that will be very helpful. Some annotations will be
>>> required, which I can help you write. I will be VERY grateful to
>>> anyone who can provide test cases. In turn, it will help improve the
>>> compiler and everyone will benefit.
>>>
>>> Some of you may be wondering how it compares to Numba. Well it is
>>> essentially very similar in the idea.  So why build a new compiler
>>> then? Actually the project I am building is not specific to Python.  I
>>> am building a far more general compiler infrastructure for array
>>> languages, and Python frontend is just one small part of the project.
>>> For example, I am also working on a MATLAB frontend.
>>>
>>> (Some of you may remember me from an earlier compiler project which
>>> unfortunately went nowhere. This is a different project and this time
>>> I am determined to convert it into a usable system. I realize the
>>> proof is in the pudding, so I hope to convince people by releasing
>>> code soon.)
>>>
>>> thanks,
>>> Rahul
>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion


More information about the NumPy-Discussion mailing list