3 ms·

Title should refer to concurrent IO, not parallel IO.

nine_k 9y ago
On the interpreter side, most of the I/O read time is waiting for an OS buffer to fill with the right amount of data. Waiting happens to occur "in parallel" when using async I/O. I suppose that sending is similar: you pass the OS a buffer, and wait for completion. Sending of the data occurs while you wait. So, if you can parallelize waits, the OS could be doing strictly parallel I/O for you (e.g. via two network interfaces, or network and disk), even though your code is concurrent but not parallel, and you don't run two sync OS I/O calls in parallel.
- zzzeek 9y ago
  > Waiting happens to occur "in parallel" when using async I/O. > and you don't run two sync OS I/O calls in parallel. you can run sync IO calls and wait for each in separate threads. the GIL is released for IO. the waiting is "in parallel" just as much with a threaded / blocking approach as with a non-blocking.
- barrkel 9y ago
  Waiting for multiple concurrent things to complete isn't parallelism, in the on-topic jargon meaning of the term. Parallelism is things physically being executed simultaneously, increasing throughput via physically multiple resources. The multiple IOs you're waiting on might be executing in parallel if you have e.g. a RAID array or SAN in the loop, but it's an implementation detail and isn't what the article is about.
zzzeek 9y ago
if I write a web crawler and send off requests to 100 web servers, then handle results as they come in, those 100 web servers are working in parallel to get me my data back. So while I can't process the IO in parallel I am parallelizing my workload. Without parallelism of some form, your program would take the entire time the non-concurrent form takes.
- barrkel 9y ago
  Those web servers are working concurrently; they may or may not be working in parallel, that's an implementation detail. Without examining the wait states on the processes, you can't easily say. The two terms mean something technically different. The article isn't about parallelism.

On the interpreter side, most of the I/O read time is waiting for an OS buffer to fill with the right amount of data. Waiting happens to occur "in parallel" when using async I/O. I suppose that sending is similar: you pass the OS a buffer, and wait for completion. Sending of the data occurs while you wait. So, if you can parallelize waits, the OS could be doing strictly parallel I/O for you (e.g. via two network interfaces, or network and disk), even though your code is concurrent but not parallel, and you don't run two sync OS I/O calls in parallel.

zzzeek 9y ago
> Waiting happens to occur "in parallel" when using async I/O. > and you don't run two sync OS I/O calls in parallel. you can run sync IO calls and wait for each in separate threads. the GIL is released for IO. the waiting is "in parallel" just as much with a threaded / blocking approach as with a non-blocking.
barrkel 9y ago
Waiting for multiple concurrent things to complete isn't parallelism, in the on-topic jargon meaning of the term. Parallelism is things physically being executed simultaneously, increasing throughput via physically multiple resources. The multiple IOs you're waiting on might be executing in parallel if you have e.g. a RAID array or SAN in the loop, but it's an implementation detail and isn't what the article is about.

zzzeek 9y ago

if I write a web crawler and send off requests to 100 web servers, then handle results as they come in, those 100 web servers are working in parallel to get me my data back. So while I can't process the IO in parallel I am parallelizing my workload. Without parallelism of some form, your program would take the entire time the non-concurrent form takes.

barrkel 9y ago
Those web servers are working concurrently; they may or may not be working in parallel, that's an implementation detail. Without examining the wait states on the processes, you can't easily say. The two terms mean something technically different. The article isn't about parallelism.