Using python as primary language
rhamph at gmail.com
Mon Nov 12 18:41:17 CET 2007
On Nov 12, 2:28 am, "Martin Vilcans" <mar... at librador.com> wrote:
> On Nov 10, 2007 12:48 AM, Rhamphoryncus <rha... at gmail.com> wrote:
> > On Nov 9, 1:45 pm, "Terry Reedy" <tjre... at udel.edu> wrote:
> > > 2. If micro-locked Python ran, say, half as fast, then you can have a lot
> > > of IPC (interprocess communition) overhead and still be faster with
> > > multiple processes rather than multiple threads.
> > Of course you'd be faster still if you rewrote key portions in C.
> > That's usually not necessary though, so long as Python gives a roughly
> > constant overhead compared to C, which in this case would be true so
> > long as Python scaled up near 100% with the number of cores/threads.
> > The bigger question is one of usability. We could make a usability/
> > performance tradeoff if we had more options, and there's a lot that
> > can give good performance, but at this point they all offer poor to
> > moderate usability, none having good usability. The crux of the
> > "multicore crisis" is that lack of good usability.
> Certainly. I guess it would be possible to implement GIL-less
> threading in Python quite easily if we required the programmer to
> synchronize all data access (like the synchronized keyword in Java for
> example), but that gets harder to use. Am I right that this is the
> Actually, I would prefer to do parallell programming at a higher
> level. If Python can't do efficient threading at low level (such as in
> Java or C), then so be it. Perhaps multiple processes with message
> passing is the way to go. It just that it seems so... primitive.
What you've got to ask is "what is a message?" Can you define your
own class and use it as a message? Doing so seems very useful. If
you allow that you end up with something like Concurrent Pascal's
monitors (which enforce their boundary, so they lack the memory model
needed by java or C.)
Once you make message passing easy to use you end up with something
that looks very much like threads anyway, just lacking the shared-
state and the resulting memory model.
Adam Olsen, aka Rhamphoryncus
More information about the Python-list