[Python-3000] An impassioned plea for true multithreading
cspencer at cinci.rr.com
Tue Jun 26 20:47:14 CEST 2007
I know this is probably futile, but I'm going to ask anyway.
Since I have not the time (or ability) to code this, I am not even
submitting a PEP. I'm throwing this out there on the wind.
Since we're doing a lot of work that breaks backwards
compatibility, one more piece of breakage needs to happen. We need to
have true multithreading.
1. Most people who bought a computer in the past year bought a
dual-core processor with it. Quad-cores are going to take over the
market in 2008. To not be able to take advantage of these extra cores
is an inherent language disadvantage. Yes, you can run more than one
process and do some sort of IPC, but it requires a lot more work for
the coder and a lot more complexity in the code (ie more bugs).
2. It makes writing servers so much more easy on Windows systems (you
know, the OS without an effective "fork" mechanism). To simply stick
fingers in your ears and yelling "LA LA LA" in the hopes Windows will
go away is not effective language design.
3. C# and Java have true multithreading. Ruby doesn't. Let's get it
before Ruby does.
4. It will actually speed up the Python interpreter. Not at first,
but I'm certain there's a level of parallelism in the Python bytecode
that can be exploited by threaded branch prediction and concurrent
processing. For example, a generator that figures out its next value
BEFORE being called, so it's a simple return of a value when the
iteration is called. I speculate that with true multitasking, an
optimized python interpreter will appear within a year to take
advantage of these possibilities.
I hope the thoughts behind this email aren't outweighed by the
fact that it didn't go through the proper channels. Thank you for
Christoper L. Spencer
CTO ROXX, LLC
4515 Leslie Ave.
EMAIL: cspencer at cinci.rr.com
More information about the Python-3000