makefile - tipos - unidad de control funcion
Fabricación de GNU: ¿el número de trabajos debe ser igual al número de núcleos de CPU en un sistema? (7)
Parece haber cierta controversia sobre si se supone que el número de trabajos en la creación de GNU es igual al número de núcleos, o si se puede optimizar el tiempo de construcción agregando un trabajo adicional que se puede poner en cola mientras los demás "funcionan" .
¿Es mejor usar -j4 o -j5 en un sistema de cuatro núcleos?
¿Has visto (o hecho) alguna evaluación comparativa que respalde una u otra?
Acabo de recibir un procesador Athlon II X2 Regor con un Foxconn M / B y 4 GB de memoria G-Skill.
Puse mi ''cat / proc / cpuinfo'' y ''free'' al final de esto para que otros puedan ver mis especificaciones. Es un Athlon II x2 de doble núcleo con 4 GB de RAM.
uname -a on default slackware 14.0 kernel is 3.2.45.
Descargué el siguiente paso kernel source (linux-3.2.46) a / archive4;
lo tar -xjvf linux-3.2.46.tar.bz2 ( tar -xjvf linux-3.2.46.tar.bz2 );
cd''d en el directorio ( cd linux-3.2.46 );
y copió la configuración del kernel por defecto ( cp /usr/src/linux/.config . );
utilizó make oldconfig para preparar la configuración del kernel 3.2.46;
luego ejecutó make con varios conjuros de -jX.
Probé los tiempos de cada ejecución emitiendo make después del comando time, por ejemplo, ''time make -j2''. Entre cada ejecución, ''m-rf'' el árbol de Linux-3.2.46 y lo volví a extraer, copié el /usr/src/linux/.config predeterminado en el directorio, ejecuté make oldconfig y luego hice mi prueba ''make -jX'' de nuevo .
simple "hacer":
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'' rinde:
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
rendimiento ''libre'':
bob@Moses:/archive4$ free
total used free shared buffers cached
Mem: 3991304 3834564 156740 0 519220 2515308
Desde mi experiencia, debe haber algunos beneficios de rendimiento al agregar trabajos adicionales. Es simplemente porque la E / S de disco es uno de los cuellos de botella además de la CPU. Sin embargo, no es fácil decidir sobre el número de trabajos adicionales, ya que está altamente interconectado con la cantidad de núcleos y tipos de disco que se utilizan.
En última instancia, tendrá que hacer algunos puntos de referencia para determinar el mejor número para usar en su compilación, ¡pero recuerde que la CPU no es el único recurso que importa!
Si tiene una construcció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 trabajar más moviendo el disco hacia adelante y hacia atrás para servir a todos los diferentes trabajos (dependiendo de muchos factores, como qué tan bien maneja el sistema operativo el caché de disco, soporte de colas de comandos nativos por el disco, etc.).
Y luego tienes núcleos "reales" versus hiper-threading. Puede o no beneficiarse de los trabajos de desove para cada hiper-hilo. Nuevamente, deberá comparar para saberlo.
No puedo decir que haya probado específicamente #cores + 1 , pero en nuestros sistemas (Intel i7 940, 4 núcleos de hyperthreaded, mucha RAM y unidades VelociRaptor) y nuestra compilación (compilación de C ++ a gran escala que es alternativamente CPU y yo / O obligado) hay muy poca diferencia entre -j4 y -j8. (Tal vez sea 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 menor. :)
He ejecutado mi proyecto casero en mi 4-core con hyperthreading laptop y grabé los resultados. Este es un proyecto bastante 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 una SSD rápida.
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 al recuento de núcleos aumenta el rendimiento de forma casi lineal. El tiempo real bajó de 2.5 minutos a 1.0 minuto (2.5 veces más rápido), pero el tiempo empleado durante la compilación aumentó de 2.11 a 2.50 minutos. El sistema notó apenas una carga adicional en este bit.
- Escalar desde el recuento de núcleos hasta el recuento de subprocesos incrementó 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 con las solicitudes y la conmutación de tareas, lo que hace que se use 17.7 segundos de tiempo. La ventaja es de aproximadamente 6.5 segundos en un tiempo de compilación de 53.5 segundos, lo que representa una aceleración del 12%.
- Escalar desde el conteo de hilos hasta el doble conteo de hilos no dio una aceleración significativa. Los tiempos en 12 y 15 son, probablemente, anomalías estadísticas que puede ignorar. El tiempo total empleado aumenta ligeramente, al igual que el tiempo del sistema. Ambas cosas se deben probablemente a una mayor conmutación de tareas. No hay ningún beneficio para esto.
Mi suposición ahora mismo: si haces algo más en tu computadora, usa el recuento de núcleos. Si no lo hace, use el conteo de hilos. Superarlo no muestra ningún beneficio. En algún momento se limitarán a la memoria y se 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 tardía, lo que me da la sospecha de que hubo alguna limitación térmica para los 8 o más trabajos. Esto muestra que para este tamaño de proyecto no hay memoria o límite de rendimiento en vigor. Sin embargo, es un proyecto pequeño, teniendo en cuenta 8GB de memoria para compilar.
Solo como ref:
Desde la sección Spawning Multiple Build Jobs en LKD :
donde n es la cantidad de trabajos para generar. La práctica habitual es engendrar uno o dos trabajos por procesador. Por ejemplo, en una máquina de procesador dual, uno podría hacer
$ make j4
Yo diría que lo mejor que puede hacer es compararlo usted mismo en su entorno particular y carga de trabajo. Parece que hay demasiadas variables (tamaño / número de archivos fuente, memoria disponible, almacenamiento en caché de disco, si el directorio de origen y los encabezados del sistema se encuentran en diferentes discos, etc.) para una respuesta única para todos.
Mi experiencia personal (en una MacBook Pro de 2 núcleos) es que -j2 es significativamente más rápido que -j1, pero más allá de eso (-j3, -j4, etc.) no hay una aceleración mensurable. Entonces, para mi entorno "jobs == number of cores" parece ser una buena respuesta. (YMMV)
Yo, personalmente, uso make -jn donde n es "number of cores" + 1.
No puedo, sin embargo, dar una explicación científica: he visto a mucha gente usando la misma configuración y me dieron muy buenos resultados hasta ahora.
De todos modos, debes tener cuidado porque algunas cadenas de fabricación simplemente no son compatibles con la opción --jobs , y pueden conducir a resultados inesperados. Si experimenta errores de dependencia extraños, simplemente intente make sin --jobs .