Motor de red / multihilo / multi-core / multi-cpu: ¿Cómo decidir el número óptimo de hilos?

Estoy usando un programa (*) en unix / linux (varios tipos) en varios servidores y clústeres, el programa admite subprocesos múltiples. Puedo especificar cuántos hilos quiero mediante la opción de línea de comando.

En términos generales, ¿cómo puedo determinar cuántos hilos debo especificar para el subprocesamiento múltiple (para obtener la velocidad máxima)?

¿Debería la cantidad de subprocesos ser menor / igual a la cantidad de subprocesos de hardware que admite la CPU respectiva? ¿Hay alguna regla general o punto de partida?

En caso afirmativo, ¿cómo puedo saber cuántos subprocesos de hardware admite una CPU?

También debo mencionar que las computadoras en las que ejecuto esto normalmente tienen múltiples CPU, cada una con varios núcleos. No está claro si un núcleo = un hilo.

(*) El programa que uso es bwa, un programa para alinear secuencias de ADN. Pero mi pregunta es de naturaleza general.

Bueno, hay algunas partes en esta pregunta: en general, una buena regla general es no ejecutar más subprocesos que los procesadores lógicos, aunque esto generalmente es para todo el sistema y puede depender de la carga. Para saber cuántos núcleos de procesador físico tiene, puede usar cat /proc/sysinfo. Imprimirá un conjunto de líneas para cada núcleo lógico, así que desplácese hacia abajo y mire el último (tengo 8 casi idénticas en mi sistema de cuatro núcleos, HT)

processor       : 7
vendor_id       : GenuineIntel
cpu family      : 6
model           : 58
model name      : Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
stepping        : 9
microcode       : 0x16
cpu MHz         : 3401.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 3
cpu cores       : 4
apicid          : 7
initial apicid  : 7
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 6819.66
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management: 

Seleccionaré las líneas importantes aquí Id. Físico: 0 (este es el primer socket; si usa más de un socket, verifique el procesador y los núcleos de la CPU para cada jd físico; si este es un número mayor que 0, tiene múltiples enchufes)

Procesador: 7 (este número comienza desde 0, hasta n-1, este es el octavo núcleo lógico en su zócalo - mirando el número más grande que tiene para un conjunto de valores que comparten una identificación física)

núcleos de la CPU: 4 (tengo 4 núcleos físicos; esto será lo mismo para cada núcleo, y dado que SMP generalmente usa núcleos idénticos, debería ser el mismo en un sistema de doble socket)

Mi procesador debería permitirme ejecutar 8 subprocesos simultáneamente, suponiendo un núcleo por subproceso. Dicho esto, dependiendo del tiempo de ejecución y otros factores, es posible que pueda escapar con más

SO tiene bastantes preguntas sobre esto y, al elegir dos de ellas, las respuestas a esta pregunta sugieren que un hilo por núcleo lógico es una buena idea, aunque este sugiere que puede ir más arriba. Como tal, desafortunadamente la respuesta es comenzar con un subproceso por proceso y ajustarlo más alto, lo que puede ser un número increíblemente alto de subprocesos, si no son de larga ejecución, subprocesos hambrientos de memoria.

Grid Engine es un programa específico que hace que tu pregunta sea discutible si realmente la estás usando. El objetivo es administrar recursos y trabajos en todos los sistemas para que los usuarios finales no tengan que pensar en ese nivel de detalle.

Introducción

El software Oracle Grid Engine es un sistema de gestión de recursos distribuidos (DRM) que permite una mayor utilización, un mejor rendimiento de la carga de trabajo y una mayor productividad del usuario final a partir de los recursos informáticos existentes. Al seleccionar de manera transparente los recursos que mejor se adaptan a cada segmento de trabajo, el software Oracle Grid Engine puede distribuir la carga de trabajo de manera eficiente en todo el grupo de recursos mientras protege a los usuarios finales del trabajo interno del clúster de cómputo

Ref: Guía para principiantes en el sitio web de Oracle Grid Engine .