¿Tiene sentido generar más de un hilo por procesador?

Question

Desde un punto de vista lógico, una aplicación puede necesitar docenas o cientos de subprocesos, algunos de los cuales dormiremos la mayor parte del tiempo, pero muy pocos siempre se ejecutarán simultáneamente. La pregunta es: ¿tiene sentido generar más hilos concurrentes que los procesadores que hay en un sistema, o es un desperdicio?

He visto algunas aplicaciones de servidor que implementan un programador para administrar tareas lógicamente (a menudo llamadas trabajos), pero también generan muchos hilos, por lo que no veo dónde está el beneficio.

Gracias de antemano.

Answer 1

Sure. Si su software hace un uso frecuente de disco o red IO, a menudo puede mejorar el rendimiento agregando algunos hilos más. Esos hilos adicionales estarán despiertos y haciendo cosas mientras los otros hilos están bloqueando en IO.

Answer 2

Cada vez que tiene una tarea esperando una operación de E/S, tiene sentido encerrarla en un hilo y encenderla. Hay una gran probabilidad de que su hilo se suspenda mientras espera que finalice la operación de E/S. Cuando se despierte, el resultado estará esperándolo.

Answer 3

Porque todos los sistemas operativos modernos son tareas múltiples: cada hilo obtiene un tiempo compartido del procesador. En realidad, no es una ejecución simultánea, pero dado que el procesador puede manejar miles de solicitudes por segundo, es una ejecución simultánea "aparente".

Así que sí, si el caso lo necesita, tiene sentido para múltiples hilos en un solo procesador.

Answer 4

Una de las ventajas es cuando actualiza su hardware, que probablemente obtendrá más procesadores/núcleos.

Answer 5

La respuesta breve es "sí".

Incluso pensé que podría obtener más del multihilo en un entorno multiprocesador, sigue siendo una tecnología útil en una sola máquina procesadora, principalmente porque significa que delegará algo de trabajo al programador del proceso, que debería tener mucha mejor información que tienes.

Si no multihilo, que va a terminar haciendo el trabajo de programación a sí mismo, lo que podría ser una buena cosa si eso es lo que necesita, pero muy probable que haya tanto tedioso e ineficiente

Answer 6

Esto puede hacer sentido si

1. sus beneficios del diseño del programa, en que tiene tareas paralelas que se implementan mejor en las discusiones, o

2. algunos de sus temas están/o atado-I, para que no se utilizará el procesadores/núcleos por su cuenta.

Answer 7

Otros han hablado de situaciones en las que casi seguro tiene sentido (cuando se está haciendo cualquier tipo de IO lento).

Podría no ser una buena idea si:

• sus hilos están haciendo con destino CPU trabajo

y

• los hilos de cada uno desea utilizar una gran cantidad (es decir, significativo en comparación con el tamaño de caché) de la memoria que no se superpone

En este caso existe la posibilidad de causar fallas de caché innecesarias.

Answer 8

Descubrí que al escribir analizadores de datos que manejan conjuntos de datos más grandes en una red, es mejor crear un hilo para cada letra del alfabeto (perteneciente a los datos) y lograr que el programa tenga más CPU y memoria . La delimitación de E/S heredadas con las operaciones de red y disco es un cuello de botella importante por lo que también puede "comenzar" en los otros archivos de datos en lugar de hacer el trabajo secuencialmente.

En un núcleo cuádruple, sin duda tendría sentido iniciar más de cuatro hilos. Es poco probable que esos 4 hilos se distribuyan en más de uno de los núcleos, especialmente con las velocidades actuales del procesador.

Answer 9

Según Herb Sutter (uno de los principales expertos en concurrencia), uno de los Pillars of Concurrency es de respuesta y aislamiento Via asincrónicos Agentes. El resumen es:

Manténgase atento ejecutando tareas de forma independiente y tareas de forma asíncrona, comunicándose a través de mensajes.

Artículo excelente (¡y la serie como un todo!). Todavía estoy esperando el libro.