[Numpy-discussion] NumPy to CPU+GPU compiler, looking for tests
Tue Oct 23 10:59:00 CDT 2012
Thanks! I did not know about the project. Looking into it.
On Tue, Oct 23, 2012 at 11:41 AM, Frédéric Bastien <firstname.lastname@example.org> wrote:
> Did you saw the gpu nd array project? We try to do something similar
> but only for the GPU.
> On Sun, Oct 21, 2012 at 2:57 PM, Rahul Garg <email@example.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.
>> On Sun, Oct 21, 2012 at 12:01 PM, Aron Ahmadia <firstname.lastname@example.org> 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:
>>> Here is my simple attempt at Cythonizing Jed's Octave code:
>>> 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.
>>> On Sun, Oct 21, 2012 at 3:27 PM, Rahul Garg <email@example.com> wrote:
>>>> 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.)
>>>> NumPy-Discussion mailing list
>>> NumPy-Discussion mailing list
>> NumPy-Discussion mailing list
> NumPy-Discussion mailing list
More information about the NumPy-Discussion