¿Cuáles son las diferencias entre los módulos de subprocesamiento y multiprocesamiento?

Estoy aprendiendo a usar los módulos threadingy multiprocessingen Python para ejecutar ciertas operaciones en paralelo y acelerar mi código.

Me resulta difícil (tal vez porque no tengo ninguna base teórica al respecto) entender cuál es la diferencia entre un threading.Thread()objeto y multiprocessing.Process()uno.

Además, no me queda del todo claro cómo instanciar una cola de trabajos y tener solo 4 (por ejemplo) de ellos ejecutándose en paralelo, mientras el otro espera a que se liberen recursos antes de ejecutarse.

Los ejemplos de la documentación los encuentro claros, pero no muy exhaustivos; Tan pronto como intento complicar un poco las cosas, recibo muchos errores extraños (como un método que no se puede conservar en vinagre, etc.).

Entonces, ¿cuándo debo utilizar los módulos threadingy ?multiprocessing

¿Puedes vincularme a algunos recursos que expliquen los conceptos detrás de estos dos módulos y cómo usarlos correctamente para tareas complejas?

Aug 08 '13 04:08 lucacerone

Pueden existir varios subprocesos en un solo proceso. Los subprocesos que pertenecen al mismo proceso comparten la misma área de memoria (pueden leer y escribir en las mismas variables y pueden interferir entre sí). Por el contrario, diferentes procesos viven en diferentes áreas de la memoria y cada uno de ellos tiene sus propias variables. Para comunicarse, los procesos tienen que utilizar otros canales (archivos, tuberías o sockets).

Si desea paralelizar un cálculo, probablemente necesitará subprocesos múltiples, porque probablemente desee que los subprocesos cooperen en la misma memoria.

Hablando de rendimiento, los subprocesos son más rápidos de crear y administrar que los procesos (porque el sistema operativo no necesita asignar un área de memoria virtual completamente nueva), y la comunicación entre subprocesos suele ser más rápida que la comunicación entre procesos. Pero los hilos son más difíciles de programar. Los subprocesos pueden interferir entre sí y pueden escribir en la memoria de los demás, pero la forma en que esto sucede no siempre es obvia (debido a varios factores, principalmente reordenamiento de instrucciones y almacenamiento en caché de memoria), por lo que necesitará primitivas de sincronización para controlar el acceso. a tus variables.

Aug 07 '2013 21:08 Giulio Franco

Citas de documentación de Python

He resaltado las citas clave de la documentación de Python sobre Process vs Threads y GIL en: ¿ Qué es el bloqueo global del intérprete (GIL) en CPython?

Experimentos de proceso versus hilo

Hice un poco de evaluación comparativa para mostrar la diferencia de manera más concreta.

En el punto de referencia, cronometré el trabajo vinculado a CPU y IO para varios números de subprocesos en una CPU de 8 hiperprocesos . El trabajo suministrado por subproceso es siempre el mismo, de modo que más subprocesos significa más trabajo total suministrado.

Los resultados fueron:

Datos de la trama .

Significado de cada sección:

• "CPU vinculado": cuánto tiempo tardan todos los subprocesos/procesos en finalizar una cantidad fija de trabajo vinculado a la CPU para cada subproceso. La cantidad de trabajo por subproceso es fija, por lo que, por ejemplo, cuando se utilizan 2 subprocesos, se realiza el doble del trabajo total.

  Interpretación: los subprocesos siempre fueron más lentos porque luchaban por el bloqueo de la CPU

• "CPU enlazada/subprocesos": el gráfico anterior dividido por el número de subprocesos. Esto da el tiempo promedio que tomó terminar cada unidad de trabajo. Observamos que:

  • para los subprocesos, esto es constante: el doble de trabajo tarda el doble de tiempo en finalizar. Por lo tanto, no hubo ningún paralelismo.

  • para los procesos, esto disminuye hasta 4x y luego permanece constante. Por lo tanto, se paralelizó bien hasta 4x y pudo ejecutar las cosas más rápido, pero no escaló más allá de eso.

    Habría esperado escalar hasta 8x ya que estoy en una máquina Hyperthread de 4 núcleos y 8.

    Compare esto con un trabajo vinculado a la CPU C POSIX que alcanza la aceleración esperada de 8x: ¿Qué significan "real", "usuario" y "sys" en la salida de time(1)?

    TODO: No sé el motivo de esto, debe haber otras ineficiencias de Python en juego.

• "Relación hilo/proceso": relación de las dos líneas anteriores. Esto nos muestra muy claramente el límite de aceleración de 4x.

• "Enlazado a IO": igual que "vinculado a CPU" pero con una tarea vinculada a IO

Conclusiones:

• para el trabajo vinculado a la CPU, el multiprocesamiento siempre es más rápido, presumiblemente debido al GIL
• para trabajos vinculados a IO. ambos tienen exactamente la misma velocidad

Código de prueba:

#!/usr/bin/env python3

import multiprocessing
import threading
import time
import sys

def cpu_func(result, niters):
    '''
    A useless CPU bound function.
    '''
    for i in range(niters):
        result = (result * result * i + 2 * result * i * i + 3) % 10000000
    return result

class CpuThread(threading.Thread):
    def __init__(self, niters):
        super().__init__()
        self.niters = niters
        self.result = 1
    def run(self):
        self.result = cpu_func(self.result, self.niters)

class CpuProcess(multiprocessing.Process):
    def __init__(self, niters):
        super().__init__()
        self.niters = niters
        self.result = 1
    def run(self):
        self.result = cpu_func(self.result, self.niters)

class IoThread(threading.Thread):
    def __init__(self, sleep):
        super().__init__()
        self.sleep = sleep
        self.result = self.sleep
    def run(self):
        time.sleep(self.sleep)

class IoProcess(multiprocessing.Process):
    def __init__(self, sleep):
        super().__init__()
        self.sleep = sleep
        self.result = self.sleep
    def run(self):
        time.sleep(self.sleep)

if __name__ == '__main__':
    cpu_n_iters = int(sys.argv[1])
    sleep = 1
    cpu_count = multiprocessing.cpu_count()
    input_params = [
        (CpuThread, cpu_n_iters),
        (CpuProcess, cpu_n_iters),
        (IoThread, sleep),
        (IoProcess, sleep),
    ]
    header = ['nthreads']
    for thread_class, _ in input_params:
        header.append(thread_class.__name__)
    print(' '.join(header))
    for nthreads in range(1, 2 * cpu_count):
        results = [nthreads]
        for thread_class, work_size in input_params:
            start_time = time.time()
            threads = []
            for i in range(nthreads):
                thread = thread_class(work_size)
                threads.append(thread)
                thread.start()
            for i, thread in enumerate(threads):
                thread.join()
            results.append(time.time() - start_time)
        print(' '.join('{:.6e}'.format(result) for result in results))

GitHub upstream + trazado de código en el mismo directorio .

Probado en Ubuntu 18.10, Python 3.6.7, en una computadora portátil Lenovo ThinkPad P51 con CPU: CPU Intel Core i7-7820HQ (4 núcleos / 8 subprocesos), RAM: 2x Samsung M471A2K43BB1-CRC (2x 16GiB), SSD: Samsung MZVLB512HAJQ- 000L7 (3000 MB/s).

Visualice qué subprocesos se están ejecutando en un momento dado

Esta publicación https://rohanvarma.me/GIL/ me enseñó que puedes ejecutar una devolución de llamada cada vez que se programa un hilo con el target=argumento dethreading.Thread y lo mismo para multiprocessing.Process.

Esto nos permite ver exactamente qué hilo se ejecuta en cada momento. Cuando termine esto, veremos algo como (hice este gráfico en particular):

            +--------------------------------------+
            + Active threads / processes           +
+-----------+--------------------------------------+
|Thread   1 |********     ************             |
|         2 |        *****            *************|
+-----------+--------------------------------------+
|Process  1 |***  ************** ******  ****      |
|         2 |** **** ****** ** ********* **********|
+-----------+--------------------------------------+
            + Time -->                             +
            +--------------------------------------+

lo que mostraría que:

• Los hilos están completamente serializados por GIL.
• Los procesos pueden ejecutarse en paralelo.

Feb 28 '2020 12:02 Ciro Santilli OurBigBook.com

Creo que este enlace responde a tu pregunta de una manera elegante.

Para ser breve, si uno de sus subproblemas tiene que esperar mientras otro finaliza, el subproceso múltiple es bueno (en operaciones pesadas de E/S, por ejemplo); por el contrario, si sus subproblemas realmente pudieran ocurrir al mismo tiempo, se sugiere el multiprocesamiento. Sin embargo, no creará más procesos que su número de núcleos.

May 13 '2015 04:05 ehfaafzv