On 25 July 2010 19:26, Jesse Noller <jnol...@gmail.com> wrote: > On Sat, Jul 24, 2010 at 10:08 AM, Guido van Rossum <gu...@python.org> wrote:
>> - Concurrency and parallelism: Russel Winder and Sarah Mount pushed >> the idea of CSP >> (http://en.wikipedia.org/wiki/Communicating_sequential_processes) in >> several talks at the conference. They (at least Russell) emphasized >> the difference between concurrency (interleaved event streams) and >> parallelism (using many processors to speed things up). Their >> prediction is that as machines with many processing cores become more >> prevalent, the relevant architecture will change from cores sharing a >> single coherent memory (the model on which threads are based) to one >> where each core has a limited amount of private memory, and >> communication is done via message passing between the cores. This >> gives them (and me :-) hope that the GIL won't be a problem as long as >> we adopt a parallel processing model. Two competing models are the >> Actor model, which is based on asynchronous communication, and CSP, >> which is synchronous (when a writer writes to a channel, it blocks >> until a reader reads that value -- a rendezvous). At least Sarah >> suggested that both models are important. She also mentioned that a >> merger is under consideration between the two major CSP-for-Python >> packages, Py-CSP and Python-CSP. I also believe that the merger will >> be based on the stdlib multiprocessing package, but I'm not sure. I do >> expect that we may get some suggestions from that corner to make some >> minor changes to details of multiprocessing (and perhaps threading), >> and I think we should be open to those (I expect these will be good >> suggestions for small tweaks, not major overhauls). > > I'm open to changes; but remain skeptical the CSP will suddenly take > over the world :) > > There's other, competing philosophies and toolkits out there as well. > Additionally; the patches would have to be relicensed - python-csp is > under GPLv2 AFAICT. Thanks for this write-up. Just a few things to follow-up from the comments here... * There is a discussion taking place, as we speak on the python-csp list, about merging PyCSP and python-csp. Like I said in the talk, it's really a matter of details more than anything else and will likely go ahead, hopefully soon. The issue of licensing is one thing we are talking about. * We do currently use threading and multiprocessing. I think we could achieve a big performance boost by loosing mp and moving to a C implementation of much of our own work, but only because so much of mp is pure Python and implementing a message-passing library requires some rather idiosyncratic programming. That's really an implementation detail for us though, so please don't read it as a comment about mp or threading in general. * In terms of the Python standard library, python-csp was very much written with our own purposes in mind, and in order to provide a platform for the CSP "paradigm" of programming to be used in a Pythonic style. Multiprocessing as it currently stands is great, and provides good support for the sort of design patterns that are currently very common in concurrent and parallel programming, like process-safe queues and so on. That's brilliant, but I would like to see the Python stdlib support a wider range of programming styles, including but not exclusive to message-passing concurrency. java.util.concurrent does this very nicely and has a wide range of constructs such as barriers, futures and so on. Python has are a wide range of packages outside the standard library (trellis, pycells, python-csp, STM implementations, and so on) but not so much that comes inside the stdlib. I think that's a shame. I won't bang on about this too much here, we'll write up some code over the next few months and when there's something more concrete and fully-baked to discuss I think it would a really useful discussion to have. Thanks, Sarah -- Sarah Mount, Senior Lecturer, University of Wolverhampton website: http://www.snim2.org/ twitter: @snim2 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
