Using python as primary language

[Martin Vilcans]

On Nov 10, 2007 12:48 AM, Rhamphoryncus <rhamph 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
problem?

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.

-- 
martin at librador.com
http://www.librador.com