2010-07-31 20 views
9

Hace algunos años, en el entorno de Windows, realicé algunas pruebas, al permitir el uso intensivo de más de varias instancias de cómputo de CPU + acceso a memoria + acceso intensivo de I/O. Desarrollé 2 versiones: una se está ejecutando en multiprocesamiento, otra se está ejecutando en multiproceso.Diferencia de rendimiento para multiproceso y multiproceso

Descubrí que el rendimiento es mucho mejor para el procesamiento múltiple. Leo en otro lugar (pero no puedo recordar el sitio).

que establece que la razón es que bajo multi-threading, que están "luchando" para una única tubería de la memoria y la tubería de E/S, lo que empeora el rendimiento en comparación con multi-procesamiento

Sin embargo, Ya no puedo encontrar ese artículo. Me preguntaba, hasta el día de hoy, si el siguiente sigue siendo cierto.

En Windows, que tiene el código de algoritmo plazo bajo multi-proceso, hay una alta probabilidad de que el rendimiento será mejor que multi-threading.

Respuesta

5

Depende de cuánto deben comunicarse los distintos hilos o procesos (utilizaré el término colectivo "tareas" para ambos), especialmente al compartir memoria: eso es fácil, barato y rápido para los hilos, pero en absoluto para procesos, entonces, si está sucediendo mucho, apuesto a que el rendimiento de los procesos es y no a yendo a vencer los hilos '.

Además, los procesos (especialmente en Windows) son "más pesados" para comenzar, por lo que si se produce una gran cantidad de "tareas iniciadas", nuevamente los hilos pueden superar fácilmente los procesos en términos de rendimiento.

A continuación, puede tener CPU con "hyperthreading", que puede ejecutar (al menos) dos hilos en un núcleo muy rápidamente, pero no procesos (ya que los hilos "hyperthreaded" no pueden usar espacios de direcciones distintos) - - otro caso en el que los hilos pueden ganar en rendimiento.

Si ninguna de estas consideraciones se aplica, entonces la carrera no debería ser mejor que un empate, de todos modos.

1

No estoy seguro de qué significa la frase. Está muy cerca de tonterías.

Lo principal que comparten los subprocesos en proceso es el espacio de direcciones de la memoria virtual.

0

No creo que esto sea cierto. En términos generales, una aplicación multiproceso se ejecutará más rápido que la misma aplicación diseñada como procesos múltiples en Windows. Existen varias razones por las que su prueba podría haber tenido un mejor rendimiento en el caso de procesos múltiples.

Lo primero que me viene a la mente es el intercambio falso. En las pruebas de subprocesos múltiples, es posible que los subprocesos hayan estado compartiendo líneas de caché sin querer. Esto sucede cuando diferentes subprocesos acceden a diferentes ubicaciones de memoria que están físicamente cerca (dentro de unos pocos bytes). Esto hace que las dos CPUs compitan continuamente sobre la misma línea de caché y esto degrada severamente el rendimiento. Eso no puede suceder en el caso de procesos múltiples porque los procesos tienen espacios de direcciones completamente separados.

+0

Um, el hecho de que los espacios de direcciones virtuales estén en la zona de pruebas no le dice mucho acerca de su diseño en la memoria física. Depende de cuán grandes sean las solicitudes de VirtualAlloc (o lo que sea), y si los procesos/subprocesos están realizando operaciones de almacenamiento de carga cerca de los límites de dichos bloques. –

-2

Encontré que esto también es cierto. pero creo que tiene algo que ver con la programación. porque si lo ejecuta el tiempo suficiente, los procesos múltiples son tan rápidos como los subprocesos múltiples. ese número es de aproximadamente 10 segundos. si el algoritmo necesita ejecutarse durante 10 segundos. los procesos múltiples son tan rápidos como multi-hilo.pero si solo necesita ser ejecutado por menos de 1 segundo. los procesos múltiples son mucho, mucho más rápidos que los multi hilos.