¿En qué circunstancias se ejecutarían 100 procesos del sistema operativo más rápido en 5 lotes en serie de 20 en lugar de todos en paralelo?

Multi-threading es atrozmente complicado. Hay innumerables formas en las que modificar aspectos particulares de su programa afectará el rendimiento. Aquí hay algunos que vienen a la mente:

Desea exactamente un hilo por cable (suponiendo que sus hilos pasen la mayor parte del tiempo trabajando tan duro como puedan). La eficiencia mejora rápidamente a medida que agrega más subprocesos hasta llegar al conteo del núcleo físico; después de eso, la eficiencia disminuye lentamente. La disminución se debe al gasto adicional de intercambio entre hilos todo el tiempo. Entonces, si tiene exactamente cinco núcleos, cinco lotes de veinte probablemente sea una buena idea (advertencia: si sus tareas son de longitud variable, puede perder algo de tiempo esperando a los rezagados mientras algunos núcleos hacen girar sus pulgares; tenga cuidado).

Aísle el acceso a la memoria para evitar colisiones de caché . Esto es complicado. Si dos núcleos diferentes intentan escribir en la misma área de memoria, dejan todo lo que están haciendo e invitan a todos a una fiesta de té para decidir quién escribió qué y cuándo. Las fiestas del té llevan años (el término real es colisiones de caché), así que evítelas. Cada hilo debe tener su propia área aislada para anotar sus resultados. Recoja los resultados en lotes más tarde.

Si todos los subprocesos funcionan en la misma memoria, verá una mejora modesta en el rendimiento si el procesamiento por lotes reduce la aparición de fiestas de té (por ejemplo, colisiones de caché).

Las tareas pequeñas no valen el subprocesamiento múltiple . Poner en marcha un hilo es bastante lento; Si el trabajo que realiza el subproceso es menor que el costo de iniciar un subproceso, verá una ganancia por lotes para reducir el recuento de subprocesos.

Esperar cerraduras es un desperdicio . Realmente desea evitar la necesidad de cerraduras en absoluto; todos los hilos pueden leer un área de datos comunes constantes sin un bloqueo, pero si tienen que escribir en un área común, necesita un bloqueo. Si su problema requiere bloqueos, trabaje duro para asegurarse de que los hilos casi siempre agarren el bloqueo con éxito en su primer intento; haga que sus secciones críticas sean muy rápidas e idealmente raras. Si puede agrupar algunas solicitudes antes de solicitar un bloqueo, esto podría reducir la contención y aumentar su rendimiento. Entonces ese es otro caso donde los lotes pueden ganar.

Eso es todo lo que tengo. En la práctica, debes medir todo y realizar experimentos; ¡Su problema podría comportarse de manera muy diferente al mío!

Si tiene 20 núcleos y los trabajos están todos vinculados al procesador (es decir, no se bloquean en E / S), el segundo escenario será más rápido. Ejecutar 100 procesos a la vez en esta situación solo causará mucha espera.

Sin embargo, es poco probable que sea la situación en la que se encuentra. Lo más probable es que tenga un número más moderado de núcleos (seamos generosos y digamos 8) y su trabajo bloquea la E / S. En este caso, debido a que los procesos se bloquean, puede ejecutar más de ellos que los núcleos a la vez. Cuántos, exactamente, depende. Es concebible que pueda ejecutar 100 trabajos en paralelo con un rendimiento decente y obtener mejores resultados que 5 lotes en serie de 20.

En pocas palabras: depende de la cantidad de procesadores y tipos de procesos (enlazados de E / S, enlazados a la CPU). Asumiremos por el argumento de que la RAM no es un problema. La única forma de saberlo con certeza es probar variaciones y ver qué funciona mejor en su caso.