Steve Holden wrote:
> Karthik Gurusamy wrote:
>
>> On Jul 1, 12:38 pm, dlomsak <[EMAIL PROTECTED]> wrote:
>
> [...]
>
>>
>> I have found the stop-and-go between two processes on the same machine
>> leads to very poor throughput. By stop-and-go, I mean the producer and
>> consumer are constantly getting on and off of the CPU since the pipe
>> gets full (or empty for consumer). Note that a producer can't run at
>> its top speed as the scheduler will pull it out since it's output pipe
>> got filled up.
This is in fact true, but the overheads of CPython are so large
that you don't usually see it. If message passing in CPython is slow,
it's usually because the marshalling cost is too high. As I mentioned
previously, try "pack" instead of "pickle" or "repr" if you control
the interface on both ends of the connection.
I've used QNX, the message-passing real time operating system,
extensively. QNX has the proper mechanisms to handle interprocess
communication efficiently; we could pipe uncompressed video through
the message passing system and only use 3% of the CPU per stream.
QNX deals with the "stop and go" problem properly; interprocess
communication via MsgSend and MsgReceive works more like a subroutine
call than a queued I/O operation. In the normal case, you pay for
a byte copy and a context switch for a message pass, but it's
not necessary to take a trip through the scheduler.
Not many operating systems get this right. Minix 3 does,
and there are infrequently used facilities in NT that almost do.
But pipes, sockets, and System V IPC as in Linux all take you through
the scheduler extra times. This is a killer if there's another compute
bound process running; on each message pass you lose your turn for
the CPU.
(There have been worse operating systems. The classic MacOS allows
you one (1) message pass per clock tick, or 60 messages per second.)
John Nagle
--
http://mail.python.org/mailman/listinfo/python-list
