2009-06-30 17 views
16

Linus Torvalds solía trabajar para una empresa de procesadores llamada Transmeta. El procesador que hicieron era un objeto basado en RISC en el núcleo. Si mal no recuerdo, la idea era que el núcleo ejecutara una "capa de emulación de procesador" arbitraria y actualizable (podría ser x86, powerpc, etc.), que traducía los códigos de operación de alto nivel en el conjunto de instrucciones básicas de RISC.¿A dónde se dirigió el código morphing?

¿Qué le sucedió a esta idea y, en su opinión, cuáles fueron los pros y contras y las situaciones en las que dicho enfoque podría haber tenido una ventaja (en términos de programación)?

+2

+1 Pregunta muy interesante. Estoy esperando a que alguien traduzca el reproductor Flash x86 a ARM. :-) – Zifre

+0

Code morphing vio un renacimiento en el núcleo NVIDIA * Denver * utilizado por primera vez en la tableta HTC Google Nexus 9 (cuyo Tegra K1 SoC tiene dos * núcleos Denver *). Internamente, es 7-ancho VLIW en orden. NVIDIA llama a la tecnología de codificación de código "optimización de código dinámico". Básicamente, traduce y optimiza el código ARMv8-A en tiempo de ejecución para el núcleo subyacente y guarda el resultado en un bloque de memoria dedicado. En condiciones ideales (p.código repetitivo y predecible), funciona casi como el escritorio * Haswell *; en condiciones menos que ideales, puede no ser mucho más rápido que Cortex-A53. – bwDraco

+0

Tengo un Nexus 9 y lo uso bastante; en las tareas más sencillas de un solo hilo, funciona bastante bien, pero adolece de un bajo rendimiento cuando se le pide que haga muchas cosas a la vez. Tener solo dos núcleos y no gustarle el código impredecible (donde las versiones optimizadas aún no están en la memoria caché y deben compilarse primero o no se ajustan por completo a la memoria caché de 128 MB) perjudica notablemente el rendimiento complejo de la carga de trabajo. El procesador tiene internamente un decodificador ARM como respaldo para el código que aún no se ha traducido y optimizado, pero es muy, pero muy lento. Las altas velocidades de reloj (2.3 GHz) lo compensan. – bwDraco

Respuesta

7

La empresa no funcionó tan bien como esperaba, y eventualmente fue adquirida por Novafora por su tecnología de ahorro de energía. (http://www.novafora.com/pr01-28-09.html)

De todas las cuentas que conozco, la tecnología simplemente no compite con los sistemas existentes. Se quedaron muy por debajo de sus números de rendimiento. Además, si bien es posible que haya otro traductor encima de su diseño VLIW, no conozco ningún producto que hayan producido. No recuerdo que el chip Crusoe pueda aceptar una descarga alternativa de microcódigo de "traducción".

Yo personalmente era dueño de un dispositivo que usaba un procesador Crusoe, y aunque sin duda cumplía con la duración de la batería, el rendimiento del dispositivo era pésimo. Parte de la culpa probablemente podría ser nivelada en la versión especial de Windows que usó, pero aún era lenta.

En el mejor de los casos, era bueno para el escritorio remoto portátil.

en mi humilde opinión, la tecnología tiene los mismos beneficios que el software de máquina virtual es como .Net y la JVM:

  • La ventaja es que es probable que puede acelerar el código más rápido con una solución de hardware (como IBM hace con son procesadores de acelerador de Java) que software puro JIT.
  • El inconveniente es que nunca se obtiene el rendimiento crudo que obtienen los procesadores que ejecutan el código nativo .

Desde algunas perspectivas se puede pensar en los chips x86 modernos como códigos morfos, aunque como muy especializados.Ellos traducen la arquitectura x86 a un conjunto de subinstrucción parecido a RISC más eficiente y luego los ejecutan.

Otro ejemplo de este tipo de tecnología podría ser FPGAs que pueden programarse para emular a nivel de circuito varios tipos de procesadores o circuitos brutos. Creo que algunos sistemas Cray pueden venir con "nodos aceleradores" de este tipo.

3

ventajas obvias:

  • Capacidad para ejecutar cualquier sistema operativo (Sólo tiene que activar la emulación del procesador para lo que se necesita)
  • Posibilidad (con el soporte del núcleo, por supuesto) de ejecutar binarios para diferentes arquitecturas en el mismo procesador/SO sin soporte de software.

con obvia:

  • capa de emulación adicional == == más sobrecarga procesador más rápido necesario para obtener un rendimiento equivalente para todo.
4

Por un lado, la mayoría de los procesadores CISC traducen internamente sus códigos de operación a uops microoperaciones que son similares a operaciones RISC. La canalización y los núcleos múltiples han cerrado la brecha en los procesadores RISC hasta el punto en que hay una diferencia muy pequeña entre ellos, en su caso. Si necesita compatibilidad cruzada desde la fuente C o desde otra interfaz de ensamblado, puede usar LLVM. http://llvm.org/

2

La mayoría de los procesadores modernos implementan sus conjuntos de instrucciones usando microcode. Hay muchas razones para esto, incluidas las cuestiones de compatibilidad, pero también existen otros motivos .

La distinción entre lo que es "hardware" y lo que es "software" es realmente difícil de hacer. Las máquinas virtuales modernas como JVM o CIL (.NET) también podrían implementarse en hardware, pero eso probablemente solo se haría usando microcódigo de todos modos.

Una de las razones para tener varias capas de abstracción en un sistema es que los programadores/ingenieros no tienen que pensar en detalles irrelevantes cuando están trabajando en un nivel superior.

Las bibliotecas del sistema operativo y del sistema también proporcionan capas de abstracción adicionales. Pero tener estas capas solo hace que el sistema sea "más lento" si no se necesitan las características que proporcionan (es decir, la programación de subprocesos realizada por el sistema operativo). No es una tarea fácil conseguir que su propio programador específico supere al que está en el kernel de Linux.

3

Yo diría que las reducciones de costos vienen con la cantidad, por lo que algo así como el chip Transmeta tiene que vender mucho volumen antes de que pueda competir en precio con los chips x86 de alto volumen existentes.

Si no recuerdo mal, el objetivo del chip Transmeta era que era de baja potencia. Tener menos compuertas de silicio para ir y venir en cada ciclo de reloj ahorra energía. El código morphing era para poder ejecutar un conjunto de instrucciones complejas (CISC) en un chip RISC de baja potencia.

El primer procesador de Transmeta, el Crusoe, no funcionó muy bien debido a problemas incluso al ejecutar software de referencia. Su segundo procesador, el Efficeon, logró usar menos energía que el Intel Atom (en la misma categoría de rendimiento), y funciona mejor que el Centrino en la misma envolvente de potencia.

Ahora, mirándolo desde el punto de vista del software y la flexibilidad como usted, Code Morphing es solo una forma de compilación Just-In-Time, con todos los beneficios y detrimentos de esa tecnología. Su código x86 esencialmente se ejecuta en una máquina virtual y es emulado por otro procesador. El mayor beneficio de la virtualización en este momento es la capacidad de compartir un solo procesador entre muchas máquinas virtuales para que tenga menos ciclos de CPU inactivos, lo que es más eficiente (costo de hardware y costo de energía).

Me parece que el cambio de código, al igual que cualquier otra forma de virtualización, se trata de ser más eficiente con los recursos.

3

Para otro acercamiento a la virtualización de ISA x86 asistida por hardware, es posible que desee leer sobre la CPU Loongson 3.

Cuestiones relacionadas