He leído que la programación selectiva y de subprocesos múltiples son modelos IO de bajo rendimiento, por ejemplo, IBM developerworks article on high perfomance IO.¿Por qué AIO es mejor que el procesamiento selectivo y de subprocesos IO múltiple?
No entiendo cómo sincronizar/sincronizar: Bloquear/No Bloquear está mejorando el rendimiento. ¿Por qué AIO es la mejor opción aquí?
Ser asíncrono y/o no bloquear no proporciona ningún aumento de velocidad inherente a las operaciones de IO individuales dentro de un sistema, si va a llevar x milisegundos leer desde el disco, eso es lo que llevará.
La ventaja de estos enfoques es cierta en entornos de subprocesos múltiples (o entornos donde la operación puede continuar a pesar del retardo de E/S) al permitir que las operaciones de E/S estén efectivamente separadas del hilo de ejecución principal. El aumento del rendimiento percibido de esto se debe a la disminución de recursos numéricos utilizados para simplemente esperar que IO regrese o se desbloquee.
En este thread está disponible una buena comparación de asincrónicos y no bloqueantes.
Puede haber más de un 'hilo principal de ejecución' (ver IOCP). AIO también gana porque se introduce más trabajo en el kernel y así se reducen los ciclos cíclicos y las copias evitables. –
En un entorno de subprocesos, es malo que un solo subproceso bloquee más tiempo del necesario porque evita que otros subprocesos funcionen. Para evitar esto, se utiliza IO no bloqueante asíncrono. Una biblioteca común para esto es Boost.Asio.
Cuando un único hilo bloquea indefinidamente una "lectura" o "recv", ¿no es que los otros hilos obtienen CPU para calcular? Pensé (todavía estoy bajo la impresión) que el hilo debe renunciar a la CPU a menos y hasta que el bloqueo sea eliminado por algún tipo de señal del kernel a este hilo ... –
¿Por qué un bloqueo de subprocesos ataría otros hilos? No puede contener mutexes, etc., o si lo hiciera, no podría escribir el mismo código con AIO. – Rup
Considere esto: cuando su programa llega a un punto en el que necesita esperar que el usuario ingrese texto, tiene dos opciones: esperar hasta que lo haga y la CPU no está haciendo nada mientras tanto, o puede bloquear el programa actual y usarlo CPU para hacer otros cálculos útiles. Después de las entradas del usuario, puede desbloquear su programa y continuar. De esta forma puedes mejorar el rendimiento.
"tiene dos opciones: esperar hasta que lo haga, y la CPU no está haciendo nada mientras tanto" ... ¿No se llamará implícitamente otro hilo para entonces? –
@AnerudhanGopal, bueno tienes razón, no es exactamente nada, otros hilos también tendrán sus oportunidades, pero como el hilo IO no está bloqueado cada vez que tiene la oportunidad, perderá CPU, hasta que el usuario ingrese algo. – atoMerz
Bloquear un proceso completo mientras se espera que termine un único IO no es eficiente si hay otras cosas que el proceso podría estar haciendo. AIO es una forma de permitir que el proceso haga otras cosas mientras el sistema está haciendo IO por él; multihilo es otro. La diferencia entre usando múltiples hilos o usando AIO es principalmente de diseño; en un servidor típico , por ejemplo, es mucho más fácil usar múltiples hilos, y no debería haber mucha diferencia en el rendimiento. Para otras aplicaciones , AIO podría ser más simple y/o proporcionar más rendimiento. Es otra herramienta a considerar, pero no se aplica en todas partes.
La pregunta es clara. El enlace contiene la comparación de varios modelos de E/S y dice que 'AIO' es mejor que' select', lo cual también me parece dudoso, especialmente teniendo en cuenta algunos de los ejemplos proporcionados que contienen una espera ocupada 'while (aio_error (& my_aiocb) == EINPROGRESS); '. – avakar
@avakar: ¿Diría usted que el * rendimiento * aquí está relacionado con el tiempo de ejecución/capacidad de respuesta? –
@MatthieuM. Sí, así es como lo entendí. – avakar