Here is my two cents on this... Something like OpenMP has already been tried in Python, although it really hasn't made it out into the wild. Here is the link:
http://www.cs.utk.edu/~luszczek/pubs/plw-200605.pdf Using markup or directives has never really become a very popular way of handling parallelism. I am not sure why, but OpenMP has never really caught on like MPI even though MPI is more painful for many things. I think it would be much better to use the language (Python) itself to handle these things as the language is already extremely powerful. But, I think the actual parallel constructs should be kept out of Cython proper. In general I think it is much better to develop libraries, not new language syntax. Obviously, Cython itself is a distinct language, but I think considerable effort must be made to prevent feature creep. I am not against new features, but it is easy to get carried away with these things. It is much more important to make the existing features and syntax more robust. This is why most successful languages develop in a rather conservative manner. I would suggest a good way of evaluating new ideas is to ask to question "what would Guido say?" Of course, Cython is not Python, but we all hope the two don't stray far from each other. Lots of projects have begun using Cython lately, which is really great. This makes it more important than ever to focus on the core language rather than wild new features. Plus, there are a number of other projects that are already having great success in tackling parallelism in Python. If people are interested in parallelism, I highly recommend getting involved in those existing efforts. Cheers, Brian On Fri, Jun 20, 2008 at 9:36 PM, rahul garg <[EMAIL PROTECTED]> wrote: > Hi. > > I am working on a proposal to add some kind of a mechanism for a Python > programmer to specify that a loop should be parallel. Think OpenMP style > parallel for loops. For people not familiar with OpenMP, it provides a very > simple parallel programming constructs which are specified as "pragma" > directives. A compiler is free to skip them if it doesnt implement OpenMP. > In OpenMP, you can specify some loops as parallel loops and the compiler and > runtime take care of spawning threads etc. Compiler automatically spawns > threads at the start of a parallel loop and joins at the end. > > The objective is to add such optional annotations which the Python > interpreter will ignore but which can (but is not mandatorily) be used by a > compiler such as Cython or my compiler unPython. The annotations will be > added to only certain predefined type of loops since parallel iteration over > generic objects is not possible. I am writing a detailed proposal document > and will post for your consideration in 1-2 days. However it would be great > if someone has some ideas about this already or if you can point to similar > work in Python or other languages. I know a "parfor" has been added to > Matlab. I do not know if Cython has such a facility. > > My original suggestion : > > "pragma parallel for" > for i in xrange(n):x[i] = y[i] > > On numpy-discussion list, two better alternatives were suggested. > > #pragma:parallel for > for i in xrange(n):x[i] = y[i] > > with parallel(i): > for i in xrange(n):x[i] = y[i] > > I was told that IPython already does something similar to "with parallel(i)" > and I am looking into it. > I think we can also do something like : > > for i in prange(i): x[i] = y[i] > > prange can simply default to xrange when running on the interpreter but the > compiler can think of prange as a special object. > I selfishly want to avoid annotations specified in comments since my > compiler cannot see comments :) > > Semantics needs to be defined properly. For example, exceptions cannot be > raised in proper order in parallel loops. > Any ideas/suggestions/flames? OpenMP has many more features such as > reduction variables. OpenMP is a very simple parallel programming model and > introducing something similar in Python can be really helpful. > > For an implementation perspectives, it will be a little challenging to > generate code while avoiding the GIL but it can be done in simple cases. > > thanks, > rahul > > > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev > > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
