On 7/25/10 3:19 PM, "Gregory P. Smith" <g...@krypto.org> wrote:
> > On Sat, Jul 24, 2010 at 7:08 AM, Guido van Rossum <gu...@python.org> wrote: >> >> - Commit privileges: Maybe we've been too careful with only giving >> commit privileges to to experienced and trusted new developers. I >> spoke to Ezio Melotti and from his experience with getting commit >> privileges, it seems to be a case of "the lion is much more afraid of >> you than you are afraid of the lion". I.e. having got privileges he >> was very concerned about doing something wrong, worried about the >> complexity of SVN, and so on. Since we've got lots of people watching >> the commit stream, I think that there really shouldn't need to be a >> worry at all about a new committer doing something malicious, and >> there shouldn't be much worry about honest beginners' mistakes either >> -- the main worry remains that new committers don't use their >> privileges enough. So, my recommendation (which surely is a >> turn-around of my *own* attitude in the past) is to give out more >> commit privileges sooner. > > +1 agreed! > >> >> - 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 > > I do not believe this prediction. The dominant systems being deployed today > have 4,6,8,12 cores on a single memory bus with coherent memory. Sure, NUMA > is clearly the dominant architecture but any subdivisions will still have > multiple cores with access to the same coherent memory. We'll just end up > with multiples of that in one system. The future architecture is _not_ the > Cell processor. +1 And there is so much legacy software out there that depends on single coherency systems that it is unlikely such a memory architecture would become pervasive, given the hurdle of rewriting those programs, python programs included. >> 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). > > The async communication model is good regardless of individual architecture > because it more readily grows out beyond a single computer to a network of > computers when you want to scale an application up. So yes, anything we can > do to help that is good. +1 > Hoping that the GIL won't be a problem has been a strategy for over a decade. > It has failed. It is limiting what people can and will do with Python today. > It isn't going to magically un-become a problem. +1 FWIW: We use Python at Tabblo, straddled across Python 2.5.4 and 2.6.5. They work. And they work well. But we make light use of threads (mostly background I/O handling), and heavy use of multiple processes because we can't take advantage of our multi-core systems otherwise. -peter > _______________________________________________ > 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/peter.a.portante%40gmail.com _______________________________________________ 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
