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.
+1 Pregunta muy interesante. Estoy esperando a que alguien traduzca el reproductor Flash x86 a ARM. :-) – Zifre
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
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