> I have been in touch with the author. The implemenation was never complete. > PLW project never actually implemented full parallel annotations. They were > proposed but not implemented.
This would explain why the project really never showed up on the radar. >> >> 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. > > It is becoming more widespread now. Every single system/chip/compiler vendor > I know of is pushing this. The advent of multicores is a big reason for this > since parallelism is now moving into the mainstream from HPC. One other > reason why OpenMP hasnt caught on is that compilers have taken many years to > mature. GCC for example had no support for OpenMP till very recently. For > OpenMP, its still usually better to use vendor compilers than GCC. > > In the Python world, MPI has been popular. Because, as it happens, Python > offers you NO WAY to handle parallelism any other way except a process based > way. Very true - threads aren't very useful in Python for CPU bound parallelism. But, I think there is another reason that MPI has become dominant and it is exactly related to the reasons you mention about compilers and OpenMP. The reality is that it is much easier in general to write a solid cross platform library (MPI) than a compiler (OpenMP). It is also much easier to tell someone "just use this library" than "use this compiler". > What will Guido say is the wrong thing to ask in this case. This is not a > question of language syntax. What we are discussing is not new syntax sugar > over some existing facility. What we are discussing is a system facility. Some of the proposals do involve modifying the language grammar. True, some of the proposals (prange) don't require this, but the pragma directive ones do. For these directives to work, the grammar of the language does have to be changed - even though the grammar changes are backwards compatible (I guess that puts them in the "sugar" category), but they are still changes. > Let me stress once again. WE ARE NOT DISCSSING SYNTAX. We are discussing a > system facility. And as it happens, this system facility cannot be handled > any other way except either > a) writing a compiler that can produce parallel C code > b) writing a modified CPython. > c) writing a JIT that can produce parallel code at runtime. similar to a. > > As we dont have the option b or c, we have to go through the route a. If > you simply dont care about the system facility being provided (loop based > parallelism), thats a different issue. I am not sure who the "WE" is here, but some of the proposals on the table require modifying the grammar of cython/unpython (unless I am missing something). I meant to comment on those proposals. > Since I am not a Cython developer, I will of course not comment on this. I > will however point out that I am also writing a compiler called unPython > which focuses a lot on numpy and I am 100% sure that I am going to add a > parallel loop. Even if the syntax I add turns out ugly, thats fine with me > as long as people get to write parallel code. Even a slightly ugly Python > syntax is a lot better than writing manually C code. Thus I propose that I > am going ahead with my implementation, for now based on prange. I think the prange proposal is a very solid one and look forward to see what becomes of this. > So in summary, I am going ahead right now and will come back and report in a > month or so. Great! Cheers, Brian > 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
