GNU make: ¿el número de trabajos debe ser igual al número de núcleos de CPU en un sistema?

He ejecutado mi proyecto casero en mi computadora portátil de 4 núcleos con hyperthreading y he registrado los resultados. Este es un proyecto bastante pesado para el compilador, pero incluye una prueba unitaria de 17.7 segundos al final. Las compilaciones no son muy intensivas en IO; hay mucha memoria disponible y si no el resto está en un SSD rápido.

1 job        real   2m27.929s    user   2m11.352s    sys    0m11.964s    
2 jobs       real   1m22.901s    user   2m13.800s    sys    0m9.532s
3 jobs       real   1m6.434s     user   2m29.024s    sys    0m10.532s
4 jobs       real   0m59.847s    user   2m50.336s    sys    0m12.656s
5 jobs       real   0m58.657s    user   3m24.384s    sys    0m14.112s
6 jobs       real   0m57.100s    user   3m51.776s    sys    0m16.128s
7 jobs       real   0m56.304s    user   4m15.500s    sys    0m16.992s
8 jobs       real   0m53.513s    user   4m38.456s    sys    0m17.724s
9 jobs       real   0m53.371s    user   4m37.344s    sys    0m17.676s
10 jobs      real   0m53.350s    user   4m37.384s    sys    0m17.752s
11 jobs      real   0m53.834s    user   4m43.644s    sys    0m18.568s
12 jobs      real   0m52.187s    user   4m32.400s    sys    0m17.476s
13 jobs      real   0m53.834s    user   4m40.900s    sys    0m17.660s
14 jobs      real   0m53.901s    user   4m37.076s    sys    0m17.408s
15 jobs      real   0m55.975s    user   4m43.588s    sys    0m18.504s
16 jobs      real   0m53.764s    user   4m40.856s    sys    0m18.244s
inf jobs     real   0m51.812s    user   4m21.200s    sys    0m16.812s

Resultados básicos:

• Escalar a la cuenta de núcleo aumenta el rendimiento casi linealmente. El tiempo real bajó de 2,5 minutos a 1,0 minutos (2,5 veces más rápido), pero el tiempo necesario durante la compilación aumentó de 2.11 a 2.50 minutos. El sistema apenas notó ninguna carga adicional en esta broca.
• El escalado del conteo de núcleos al conteo de subprocesos aumentó enormemente la carga del usuario, de 2.50 minutos a 4.38 minutos. Esta casi duplicación es más probable porque las otras instancias del compilador querían usar los mismos recursos de CPU al mismo tiempo. El sistema se está cargando un poco más de solicitudes y conmutación de tareas, lo que hace que vaya a 17.7 segundos de tiempo utilizar. La ventaja es de aproximadamente 6,5 segundos en tiempo de compilación de 53.5 segundos, haciendo un 12% aceleración.
• Escala de hilos para duplicar hilos no dio ninguna aceleración significativa. Los tiempos de 12 y 15 son probablemente anomalías estadísticas que puedes ignorar. El tiempo total tomado aumenta ligeramente, al igual que el tiempo del sistema. Ambos son probablemente debido al aumento de la conmutación de tareas. Esto no tiene ningún beneficio.

Mi conjetura en este momento: Si haces algo más en tu computadora, usa la cuenta central. Si no lo hace, utilice el número de hilos. Excederlo no muestra ningún beneficio. En algún momento se volverán memoria limitada y colapsarán debido a eso, haciendo que la compilación sea mucho más lenta. La línea" inf " se agregó en una fecha mucho más tarde, lo que me dio la sospecha de que había un cierto estrangulamiento térmico para los trabajos de 8+. Esto muestra que para este tamaño de proyecto no hay límite de memoria o rendimiento en efecto. Sin embargo, es un proyecto pequeño, con 8 GB de memoria para compilar.

Yo, personalmente, uso make -j n donde n es "número de núcleos" + 1.

Sin embargo, no puedo dar una explicación científica: he visto a muchas personas usando los mismos ajustes y me han dado resultados bastante buenos hasta ahora.

De todos modos, hay que tener cuidado porque algunas cadenas de marcas simplemente no son compatibles con la opción --jobs, y pueden conducir a resultados inesperados. Si está experimentando extraños errores de dependencia, simplemente intente make sin --jobs.

En última instancia, tendrá que hacer algunos puntos de referencia para determinar el mejor número para usar para su compilación, pero recuerde que la CPU no es el único recurso que importa.

Si tiene una compilación que depende en gran medida del disco, por ejemplo, generar muchos trabajos en un sistema multinúcleo podría ser más lento, ya que el disco tendrá que hacer un trabajo adicional moviendo la cabeza del disco hacia adelante y hacia atrás para servir a todos los diferentes trabajos (dependiendo de muchos factores, como maneja la caché del disco, el soporte nativo de colas de comandos por el disco, etc.).

Y luego tienes núcleos "reales" versus hyper-threading. Usted puede o no beneficiarse de los trabajos de generación para cada hiper-hilo. De nuevo, tendrás que hacer benchmark para averiguarlo.

No puedo decir que haya probado específicamente # cores + 1, pero en nuestros sistemas (Intel i7 940, 4 núcleos hyperthreaded, mucha RAM y unidades VelociRaptor) y nuestra compilación (compilación de C++ a gran escala que está alternativamente vinculada a CPU y E / S) hay muy poca diferencia entre -j4 y -j8. (Es quizás un 15% mejor... pero ni cerca del doble de bueno.)

Si me voy a almorzar, usaré-j8, pero si quiero usar mi sistema para cualquier otra cosa mientras se está construyendo, usaré un número más bajo. :)

Acabo de recibir un Athlon II X2 Regor proc con un Foxconn M/B y 4 GB de memoria G-Skill.

Pongo mis 'cat /proc/cpuinfo' y 'free' al final de esto para que otros puedan ver mis especificaciones. Es un dual core Athlon II x2 con 4GB de RAM.

uname -a on default slackware 14.0 kernel is 3.2.45.

He descargado el siguiente paso kernel source (linux-3.2.46) a / archive4;

Extraído (tar -xjvf linux-3.2.46.tar.bz2);

Cd'd en el directorio (cd linux-3.2.46);

Y copió la configuración predeterminada del kernel (cp /usr/src/linux/.config .);

Usado make oldconfig para preparar la configuración del kernel 3.2.46;

Luego corrió hacer con varios encantamientos de-jX.

Probé los tiempos de cada ejecución emitiendo make after the time, e. g., "time make-j2". Entre cada ejecución I' rm-rf ' el árbol linux-3.2.46 y lo reexpresó, copió el /usr/src/linux/por defecto.config en el directorio, ejecuté make oldconfig y luego hice mi prueba' make-jX ' de nuevo.

"Marca" simple:

real    51m47.510s
user    47m52.228s
sys     3m44.985s
bob@Moses:/archive4/linux-3.2.46$

Como arriba pero con make - j2

real    27m3.194s
user    48m5.135s
sys     3m39.431s
bob@Moses:/archive4/linux-3.2.46$

Como arriba pero con make-j3

real    27m30.203s
user    48m43.821s
sys     3m42.309s
bob@Moses:/archive4/linux-3.2.46$

Como arriba pero con make-j4

real    27m32.023s
user    49m18.328s
sys     3m43.765s
bob@Moses:/archive4/linux-3.2.46$

Como arriba pero con make-j8

real    28m28.112s
user    50m34.445s
sys     3m49.877s
bob@Moses:/archive4/linux-3.2.46$

'cat /proc/cpuinfo' produce:

bob@Moses:/archive4$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 6
model name      : AMD Athlon(tm) II X2 270 Processor
stepping        : 3
microcode       : 0x10000c8
cpu MHz         : 3399.957
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmo
v pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rd
tscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor cx16 p
opcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowpre
fetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save
bogomips        : 6799.91
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 6
model name      : AMD Athlon(tm) II X2 270 Processor
stepping        : 3
microcode       : 0x10000c8
cpu MHz         : 3399.957
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmo
v pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rd
tscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor cx16 p
opcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowpre
fetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save
bogomips        : 6799.94
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

Rendimientos'libres':

bob@Moses:/archive4$ free
             total       used       free     shared    buffers     cached
Mem:       3991304    3834564     156740          0     519220    2515308

Al igual que un ref:

Desde Spawning Multiple Build Jobs sección en LKD :

Donde n es el número de trabajos a generar. La práctica habitual es generar uno o dos trabajos por procesador. Por ejemplo, en una máquina de doble procesador, uno podría hacer

Make make j4

Desde mi experiencia, debe haber algunos beneficios de rendimiento al agregar trabajos adicionales. Es simplemente porque la E/S del disco es uno de los cuellos de la botella además de la CPU. Sin embargo, no es fácil decidir el número de trabajos adicionales, ya que está altamente interconectado con el número de núcleos y tipos del disco que se utiliza.