Using python as primary language

[Rhamphoryncus]

On Nov 9, 1:45 pm, "Terry Reedy" <tjre... at udel.edu> wrote:
> "Martin Vilcans" <mar... at librador.com> wrote in message
>
> news:f782707a0711090754n5e2918adla2067057c469668b at mail.gmail.com...
> | But that's not what my question was about. It was about whether it
> | would make sense to, on the same python installation, select between
> | the GIL and fine-grained locks at startup. Because even if the locks
> | slows down the interpreter, if they let you utilize a 32 core CPU, it
> | may not be so bad anymore. Or am I missing something?
>
> 1. The need for some group to develop and maintain what anounts to a forked
> version of CPython.

That's pretty much what I'm doing.


> 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.


--
Adam Olsen, aka Rhamphoryncus