5

I have read that select and multi-threaded programming were low performing IO models, for example this IBM developerworks article on high perfomance IO.

I do not understand how synchronising/aynchronising : Blocking/Non-Blocking is improving the performance. Why is AIO the best option here?

Rup
  • 33,765
  • 9
  • 83
  • 112
Anerudhan Gopal
  • 379
  • 4
  • 13
  • 2
    I find the question clear. The link contains the comparison of various I/O models and says that `AIO` is better than `select`, which I too find dubious, especially given some of the provided examples containing a busy wait `while ( aio_error( &my_aiocb ) == EINPROGRESS ) ;`. – avakar Jan 04 '12 at 09:49
  • @avakar: Would you thus say that the *performance* here is related to execution time / responsiveness ? – Matthieu M. Jan 04 '12 at 09:55
  • @MatthieuM., yes, that's how I understood it. – avakar Jan 04 '12 at 09:56
  • @thiton Performance scenarios: Say i)10 threads are reading 4 kb payload continuosly from 10 clients using Unix Domain Sockets ii) the 10 Fd are on a select system call ( same Proto Payload as above) iii) The 10 fd are on a Aio loop as specified in the link .. – Anerudhan Gopal Jan 04 '12 at 09:59
  • @AnerudhanGopal: Thanks for the question edit, it is much clearer with the link and the explicit question. +1. – thiton Jan 04 '12 at 10:05

4 Answers4

4

Being asynchronous and/or non-blocking does not provide any inherent speed boost to individual IO operations within a system, if it is going to take x milliseconds to read from the disk that’s what it will take.

The advantage of these approaches shows true in multi-threaded environments (or environments where operation can continue despite delayed IO) by allowing the IO operations to be effectively separately from the main thread of execution. The perceived performance increase from this is due to the decreased number resources used to simply wait for IO to return or unblock.

A good comparison of asynchronous and non-blocking is available in this thread.

Community
  • 1
  • 1
Turix
  • 178
  • 3
  • 9
  • 1
    The may be more than one 'main thread of execution', (see IOCP). AIO also wins because more work is pushed into the kernel & so reduces ring-cycles and avoidable copying. – Martin James Jan 04 '12 at 11:49
1

Blocking an entire process while waiting for a single IO to finish isn't efficient if there are other things the process could be doing. AIO is one means of allowing the process to do other things while the system is doing IO for it; multithreading is another. The difference between using multiple threads or using AIO is largely one of design; in a typical server, for example, it's much easier to use multiple threads, and there shouldn't be much difference in performance. For other applications, AIO might be simpler and/or give more performance. It's another tool to be considered, but it doesn't apply everywhere.

James Kanze
  • 150,581
  • 18
  • 184
  • 329
0

In a threaded environment it is bad for a single thread to block longer than necessary because it keeps other threads from doing work. To prevent this asynchronous non-blocking IO is used. A common library for this is Boost.Asio.

pmr
  • 58,701
  • 10
  • 113
  • 156
  • 1
    When a single thread blocks indefinitely for a "read" or "recv", is it not that the other threads get CPU to compute ..?? I thought ( am still under the impression) the thread must relinquish the CPU unless and until the blocking is removed by some sort of signal from the kernel to this thread .. – Anerudhan Gopal Jan 04 '12 at 09:55
  • 1
    Why would one thread blocking tie up other threads? It can't hold mutexes etc., or if it did you wouldn't be able to write the same code with AIO. – Rup Jan 04 '12 at 09:56
0

Consider this: when your program reaches a point where it needs to wait for user to enter some text, you have two choices: wait until he does, and CPU is doing nothing meanwhile, or you can block current program and use CPU to do other useful computations. After the user inputs you can unblock your program and continue. This way you could improve performance.

atoMerz
  • 7,534
  • 16
  • 61
  • 101
  • "you have two choices: wait until he does, and CPU is doing nothing meanwhile" .. Is it not that other thread will be implicitly called by then ?? – Anerudhan Gopal Jan 04 '12 at 09:57
  • @AnerudhanGopal, well you're right, it's not exactly nothing, others threads will get their chances too, but since the IO thread is not block every time it get a chance it will waste CPU, until user inputs something. – atoMerz Jan 06 '12 at 09:54