threads - ¿El multithreading tiene sentido para las operaciones vinculadas a IO?
thread model (7)
Creo que depende de una serie de factores, como el tipo de aplicación que está ejecutando, el número de usuarios simultáneos, etc.
Actualmente estoy trabajando en un proyecto que tiene un alto grado de operaciones lineales (lectura de archivos de principio a fin). Usamos un NAS para el almacenamiento, y estábamos preocupados por lo que sucedería si ejecutaramos varios hilos. Nuestro pensamiento inicial fue que nos retrasaría porque aumentaría la búsqueda de la cabeza. Así que hicimos algunas pruebas y descubrimos que la cantidad ideal de subprocesos es la misma que la cantidad de núcleos en la computadora.
Pero tu kilometraje puede variar.
Al realizar muchas operaciones de disco, ¿ayuda el multihilo, obstaculiza o no hace ninguna diferencia?
Por ejemplo, al copiar muchos archivos de una carpeta a otra.
Aclaración : entiendo que cuando se realicen otras operaciones, la simultaneidad obviamente marcará la diferencia. Si la tarea era abrir un archivo de imagen, convertir a otro formato y luego guardar, las operaciones del disco se pueden realizar al mismo tiempo que la manipulación de la imagen. Mi pregunta es cuando las únicas operaciones que se realizan son las operaciones de disco, ya sea que las colas concurrentes y la respuesta a las operaciones del disco sean mejores.
Creo que dificultaría las operaciones ... Solo tienes un controlador y una unidad.
Podría usar un segundo hilo para hacer la operación y un hilo principal que muestre una IU actualizada.
Creo que podría empeorar el rendimiento, porque los hilos múltiples competirán por los mismos recursos.
Puede probar el impacto de realizar operaciones de IO simultáneas en el mismo dispositivo copiando un conjunto de archivos de un lugar a otro y midiendo el tiempo, luego divida el conjunto en dos partes y haga las copias en paralelo ... la segunda opción ser sensiblemente más lento.
Eso depende de tu definición de "E / S obligado", pero generalmente el multihilo tiene dos efectos:
Use varias CPU simultáneamente (lo que no necesariamente ayudará si el cuello de botella es el disco en lugar de la CPU [s])
Use una CPU (con otro hilo) incluso cuando un hilo está bloqueado (por ejemplo, esperando la finalización de E / S)
No estoy seguro de que la respuesta de Konrad siempre sea correcta, sin embargo: como un contraejemplo, si "E / S encuadernado" solo significa "un hilo pasa la mayor parte del tiempo esperando la finalización de E / S en lugar de usar la CPU", pero no significa que "hemos alcanzado el límite de ancho de banda de E / S del sistema", entonces la IMO que tiene múltiples hilos (o E / S asíncrona) puede mejorar el rendimiento (habilitando más de una operación de E / S simultánea).
La mayoría de las respuestas hasta ahora han tenido que ver con el programador del sistema operativo. Sin embargo, hay un factor más importante que creo que llevaría a su respuesta. ¿Estás escribiendo en un único disco físico o en varios discos físicos?
Incluso si paraleliza con múltiples hilos ... IO a un solo disco físico es intrínsecamente una operación serializada. Cada hilo debería bloquearse, esperando su oportunidad de acceder al disco. En este caso, es probable que los hilos múltiples sean inútiles ... e incluso pueden generar problemas de contención.
Sin embargo, si está escribiendo múltiples flujos en múltiples discos físicos, procesarlos al mismo tiempo le dará un impulso en el rendimiento. Esto es particularmente cierto con discos administrados, como matrices RAID, dispositivos SAN, etc.
No creo que el problema tenga mucho que ver con el programador del sistema operativo, ya que tiene más que ver con los aspectos físicos de los discos en los que escribe.
No, no tiene sentido. En algún momento, las operaciones tienen que ser serializadas (por el sistema operativo). Por otro lado, dado que los SO modernos tienen que lidiar con múltiples procesos de todos modos, dudo que haya una sobrecarga adicional.
Puede hacerlo, simplemente porque cada vez que hay más trabajo para un subproceso (identificando el siguiente archivo para copiar) el SO lo despierta, por lo que los subprocesos son una forma simple de engancharse al planificador del SO y aún así escribir el código en un tradicional de forma secuencial, en lugar de tener que dividirlo en una máquina de estado con devoluciones de llamada.
Esto es principalmente una ayuda con programación clara en lugar de rendimiento.