Propiedades ARM8/ARMv4 para la comparación cualitativa entre diseños de procesadores RISC, CISC y MISC

No vas a poder llegar a un resultado de manera concluyente, no es posible. La evaluación comparativa siempre es subjetiva y, a menudo, se puede usar y se usa para dar el resultado deseado (A es mejor, B es mejor, C es mejor, etc.).

El número de instrucciones no es relevante, al igual que el número de registros, etc. El número de transistores es interesante, pero comparar un solo chip soc con un procesador que requiere chips externos para proporcionar la misma funcionalidad. O un chip puede tener grandes partes desactivadas en cualquier momento en relación con el otro, o puede tener una gran parte desactivada para completar el punto de referencia, o uno puede tener más transistores, pero cambiarlos con menos frecuencia que el otro que tiene menos. posiblemente conduciendo a un consumo de energía diferente.

Intel fabrica y vende chips que tienen (gran parte) de sus cosas adentro. Arm no fabrica chips, vende IP. Al igual que la rapidez con la que se ejecuta este programa en forma de código fuente, varía ampliamente según las opciones del compilador, el procesador, etc. Esa misma IP puede consumir cantidades de energía muy diferentes según la biblioteca de celdas y la fundición y el proceso utilizado para implementarlo. Misma arquitectura, misma frecuencia de reloj, diferente consumo de energía. Entonces, de inmediato estás comparando manzanas con naranjas de otra manera. No puedo pensar en un caso real en el que el núcleo del brazo sea todo lo que hay en el chip, generalmente envuelves el brazo en el chip con muchas cosas, cosas que con el otro procesador estarían fuera del chip. La comparación adecuada sería todo el sistema, no solo la potencia del procesador.

Esto lo lleva a las diferencias de reloj, un procesador puede ser mucho más eficiente que otro y puede realizar el mismo punto de referencia a una frecuencia de reloj diferente o, de lo contrario, usar menos hardware o energía o lo que sea. Es muy fácil escribir un punto de referencia que se ejecuta en una pequeña placa de microcontrolador alimentada por batería que usa menos energía que una computadora x86, incluso si el x86 está o podría estar muy bajo. Igual de fácil es escribir un punto de referencia que se ejecute a la velocidad del rayo en un x86 que le lleve una eternidad a ese microcontrolador. Incluso si los registraste igual o pudiste.

Solo los compiladores hacen que la misma computadora ejecute el mismo código fuente y velocidades muy diferentes. Simplemente no es posible comparar dos sistemas de esta manera excepto indicando claramente el punto de referencia exacto. Este código específico compilado para velocidad utilizando este compilador que se verificó manualmente para producir esta calidad de código optimizado, se ejecutó en este sistema específico con el sistema consumiendo tanta energía. Este otro sistema que usa este compilador verificado a mano para proporcionar una optimización similar, requirió esta frecuencia de reloj y esta cantidad de energía para ejecutarse aproximadamente al mismo tiempo. Repita para cada una de las infinitas aplicaciones de referencia que podrían interesar a los usuarios.

La comparación mips/mhz se basa en gran medida en el compilador y la aplicación, grandes variaciones en mips en el mismo sistema sin cambios de hardware. De ninguna manera puedes realmente comparar dos procesadores con este método. Mips publicados a mhz es solo marketing, ignóralo. Del mismo modo, puede confiar tanto en el consumo de energía publicado como en los números de mips/mhz, se basó en algún punto de referencia, si su aplicación no es el mismo punto de referencia, ¿de qué sirve?

Necesitará crear una serie de sistemas (disponer cada diseño de placa específico para el punto de referencia) e intentar reducir el número de variables, o idealmente adoptar el enfoque de hacer que el sistema mínimo básico, la optimización máxima, sea capaz de ejecutar el punto de referencia en exactamente X cantidad de tiempo. Repita para el otro sistema, luego compare el consumo de energía de todo el sistema durante la ejecución de ese punto de referencia. Repita para los millones de puntos de referencia diferentes, para obtener una comparación justa y general, puede que no sea posible reducir los resultados de manera concluyente.

Para una diferencia de arquitectura, lo ideal es que los procesadores se construyan en la misma fundición utilizando la misma biblioteca de celdas y el mismo proceso, etc. Si está dispuesto y puede licenciar núcleos de la competencia, llene los chips al mismo nivel, use velocidades de bus similares y tanto hardware externo similar (los buses del sistema son sin duda diferentes, hacer un bus común a partir de ellos podría dar una ventaja injusta). La misma cantidad de cachés con las mismas ventajas, etc. Es posible que tenga una mejor oportunidad de hacer una comparación que realmente parezca real. Esta sería la única forma de encontrar algo plausible, el mismo punto de referencia ejecutado en diferentes arquitecturas hechas en la misma fundición, la misma biblioteca de celdas, el mismo proceso, el mismo tamaño de caché, el mismo dram, etc. Todavía se pueden manipular los puntos de referencia para hacer cualquiera de los dos. el consumidor de energía más rápido o más bajo.

Lo que sería más interesante es una comparación empírica. Tome o cree puntos de referencia uno a la vez, observe las diversas formas de generar código a partir del compilador. Examine los autobuses que puede examinar, tenga una idea de los tamaños de búsqueda. Si es posible, con las instrucciones de longitud de palabra fija frente a variable, ¿puede saber en los buses dónde se toman las decisiones de longitud variable? , ahora puedes ejecutar. ¿Cuánto tiene que estar atascado cerca del decodificador para que sea eficiente? ¿Cuánto tienes que desechar y buscar si hay una rama, qué tan rápido sucede esto? Debe observar la cantidad de código para realizar tareas similares, debido a la diferente cantidad de registros (reales o virtuales) (x86 está microcodificado o muchos lo están, arm no está microcodificado) con qué frecuencia el código tiene que intercambiar registros en la pila (muy fácil de escribir puntos de referencia que castigan una arquitectura en relación con otra por esto). x86 puede almacenar más programas en el caché del mismo tamaño que un brazo, pero el brazo es más determinista al decodificar ese código. x86 incurre en más castigos de alineación que el brazo, ya que se presta a no alinearse donde se fomenta o se fuerza el brazo. ¿Puede construir puntos de referencia que muestren una ventaja para cada conjunto de instrucciones? Debería ser muy fácil hacer un bucle que se ajuste a las instrucciones x86 dentro de un caché de cierto tamaño, pero no se ajuste a las instrucciones de brazo en el caché del mismo tamaño. podría ser fácil tener un punto de referencia que se bifurque mucho y que pueda mostrar ventajas de brazos o al menos calzar un predictor de rama frente a otro. los relojes y la energía todavía están fuera de escena,

De todos modos, eso fue una tangente, no puede comparar dos procesadores de esta manera y hacer que los que saben acepten los resultados como algo significativo. Las masas pueden ser engañadas, pero no aquellos que saben lo que está pasando. Demostrando empíricamente ventajas y desventajas, que pueden ser más factibles e interesantes para todos. comparar opencores en la misma fpga, eso también podría ser interesante, pero un chip de procesador comercial en una placa comercial, en comparación con IP que se puede implementar de muchas maneras diferentes en muchas placas diferentes, simplemente no será plausible.