El multihilo por hardware es común en las computadoras personales (la mayoría de los sistemas Intel x86 admiten dos subprocesos por núcleo), servidores (POWER7, 4 hilos por núcleo; SPARC T5, 8 hilos por núcleo; SPARC64 VII +, 2 hilos por núcleo; Itanium 9500, 2 hilos por núcleo; y x86 de Intel), procesadores de red (comúnmente con 4 hilos por núcleo), y incluso la versión anterior de Intel Atom (2 subprocesos por núcleo), pero el multihilo parece ser notablemente menos común en sistemas integrados fuera de la red.
Si bien MIPS desarrolló una Extensión específica de aplicaciones de subprocesamiento múltiple específicamente para sistemas embebidos en los que implementaciones equivalentes de núcleo múltiple requerirían la licencia de más diseños de núcleos, usarían más área de chip y serían menos flexibles en ciertos aspectos, no es obvio que se haya utilizado ampliamente. (El documento técnico "Optimización del rendimiento, la potencia y el área en los diseños de SoC utilizando procesadores multiproceso MIPS® " ofrece una visión general de algunos argumentos a su favor, pero uno debe considerar la fuente.)
(Por supuesto, la mayoría de los sistemas integrados no publicitan estos detalles, pero parece , debido a mi exposición muy limitada, el uso de multihilo no se usa ampliamente).
Uno podría considerar varios mecanismos de registro en la sombra (o en bancos) como formas muy limitadas de multiprocesamiento de encendido en evento (SoEMT). La presencia más común de tales mecanismos hace que sea aún más extraño que ni siquiera se adopte SoEMT.
Obviamente, el multihilo no sería atractivo para todos los usos. Se aplicarían las compensaciones asociadas con los recursos compartidos frente a los dedicados. (Un recurso compartido puede asignarse de manera más flexible a diferentes usuarios, pero compartir puede sacrificar la optimización por oportunidades de especialización y tiende a requerir un mejor manejo de la contención. Para el uso de la energía, las compensaciones para multihilo frente a multinúcleo, especialmente multipolar heterogéneo, pueden ser complejas y dependiente de la carga de trabajo.)
Dado que muchos sistemas integrados tienen requisitos de recursos bien definidos y muchos tienen requisitos de rendimiento en tiempo real (ambos pueden reducir las ventajas de una asignación de recursos más flexible), la multihebra puede no ser especialmente atractiva para tales sistemas. Incluso la mentalidad de los diseñadores de sistemas integrados podría desviar un poco las elecciones de la flexibilidad.
(Tenga en cuenta que un núcleo de multiproceso no requiere que las tareas sean de multiproceso, aunque se requeriría un SO para protegerse de las condiciones de carrera en sus propios datos. En el lado positivo, con el intercambio de información local memoria / memoria caché L1, los bloqueos tendrían menos gastos generales que con múltiples núcleos. Alternativamente, uno podría tener un sistema operativo por hilo de hardware. Además, el concepto general de multihilo puede admitir una variedad de alternativas de programación desde la asignación de ranuras fijas hasta la ejecución inmediata y dinámica. programación ponderada con múltiples factores de peso.)
También sospecho que la falta de familiaridad con la implementación del hardware (y la validación) de los subprocesos múltiples y con el uso de dicho hardware también puede impedir la adopción. Incluso con una infraestructura de desarrollo de software madura, el subprocesamiento múltiple podría inherentemente agregar más complejidad (con costos de desarrollo y confiabilidad) que beneficios en otras áreas.
Para los microcontroladores, las tuberías simples y el retardo de acceso a la memoria predecible reducirían el beneficio de los subprocesos múltiples intercalados. Además, la fracción del área de chip utilizada para el núcleo es tan pequeña (y los costos de licencia pueden ser muy pequeños y el diseño con licencia no es posible por instancias), por lo que agregar multiproceso no es atractivo en comparación con la adición de más núcleos idénticos; Agregar multihilo es mucho menos costoso en área que agregar núcleos. (La codificación más cercana al metal, como es más común allí, también desalentaría la diversidad en los tipos de núcleos y mucho menos la diversidad dinámica en el rendimiento).
¿Las anteriores son las únicas razones por las que el multihilo no es más común en los sistemas integrados? ¿Qué cambios podrían hacer que los subprocesos múltiples sean más comunes en los sistemas integrados?