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 <[email protected]> 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 > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
