Cálculo de Mips para software integrado

Question

Me han preguntado recientemente (y en varias ocasiones) los clientes acerca de MIPS necesarios para ejecutar nuestro software. Por lo general, pudimos deshacernos de estas preguntas explicando al cliente que esto realmente depende de la CPU/OS/HW (nuestro software es altamente portátil) y/o caso de uso (es decir, cómo se usa nuestro software).

Pero tengo una última, no solo muy terca, pero además proporciona buenas razones para ser terco. :) Quiere una estimación porque no está seguro de tener suficiente poder para ejecutar nuestro software, por lo que comprar el software antes de esta estimación no es lógico. (No podemos proporcionar la demostración/evaluación, ya que requerirá una gran cantidad de trabajo para ejecutar en esta plataforma específica.)

Y ahora la pregunta: ¿Alguien tiene una experiencia con esa tarea en cualquier pieza de HW con cualquier software? Cualquier ejemplo de la vida real será realmente útil. Tengo una opción para ejecutar nuestro software en muchos sistemas operativos y muchos hardware. Entonces, si conoce alguna herramienta para tal estimación en cualquier hardware, existe la posibilidad de que pueda usarlo o al menos tener una idea. Para saber, solo sé cómo medir la carga de la CPU en eCosPro OS.

Editar:

El uso de la sonda es en realidad una buena idea, suponiendo que yo pueda crear un ambiente de control en el que sólo el software se está ejecutando toda la instrucción que puedo contar es mío, y supongo que la sonda tiene una interfaz para hazlo. En realidad tengo algunos depuradores de hardware diferentes y si alguien tiene experiencia en cómo hacerlo será realmente bueno, de cualquier manera voy a leer algunos documentos mañana y espero encontrar algo en esta dirección.

Answer 1

OK se da cuenta de que esto está plagado de advertencias & advertencias - velocidades de CPU, velocidades de memoria, hits de caché, descargas de tablas de páginas MMU, contención de bus, etc. ... (si se trata de un sistema embebido) significativamente en la decisión ....

Habiendo dicho eso .... lo que haría es esto. Obtenga un sistema operativo en tiempo real (quédese conmigo), tal vez algo como FreeRTOS (gratis, qué sorpresa) o u/C-OS-II (no gratis para uso comercial, tal vez $ 3K). Estos núcleos le permiten instrumentar el código para contar los ciclos de CPU inactivos (bucle de giro de la tarea inactiva).

Ejecute toda la aplicación (o la aplicación del cliente) como la única tarea (no inactiva) de una placa en la que ustedes estén de acuerdo (por ejemplo, la placa MPC860, la placa ARM7, etc.). Mida el% de CPU en la placa a través de RTOS. (por ejemplo, "en la placa Flibber funcionando a 60 MHz, nuestra aplicación usó el 12% de la CPU.")

Sin que estos le proporcionen más, o viceversa, eso suena como una longitud bastante razonable para ellos.

Lo bueno es que una vez que haya hecho esto, puede volver a utilizar el trabajo para otros objetivos y/o tableros, tal vez las cifras le ayudarán a aumentar las ventas y/o optimizar/optimizar su software.

¡Buena suerte!

Answer 2

¿Tiene un simulador o sonda de depuración que le puede dar un recuento de instrucciones? Ni siquiera necesita hacerlo para la plataforma de destino correcta, bastará con un recuento aproximado de instrucciones.

Si todo lo demás falla, ejecútelo en la plataforma a la que tenga acceso, escale el tiempo de ejecución con el cociente de su MHz/cliente's-MHz. Esto debería darle una estimación aproximada muy de qué tipo de tiempos de ejecución experimentará el cliente.

Answer 3

I/S es una métrica "débil" para un sistema con un sistema operativo.

En el meollo de la cuestión, lo que tiene que hacer es

1. averiguar la ruta de la instrucción del peor caso y contar el número de ciclos que se tarda en ejecutar (esto significa que la lectura de la asamblea para que la CPU y la revisión el manual de la CPU que te dice # de ciclos).
2. Ahora descubra sus limitaciones en tiempo real.
3. Luego, usa # 1 para los ciclos de peor caso. Ajuste la CPU hacia arriba/abajo hasta que encaje en las restricciones en tiempo real.
4. Agregue un factor de dulce de azúcar.

Answer 4

Lo primero que tendrá que hacer es buscar algún tipo de criterio para un funcionamiento correcto. Esto dependerá en gran medida de la naturaleza de la aplicación; sus criterios pueden incluir "debe ejecutar el código x en 3 ms" o "debe tener una latencia inferior a 100 ms". Cualquier criterio que no se relacione con una medición cuantitativa va a ser difícil, ya que será subjetivo.

Encontrar sus criterios para el funcionamiento correcto le permitirá encontrar las partes críticas del código.Tenga en cuenta que estos se pueden encontrar en casos de esquina en lugar de la operación normal.

Si esas partes críticas del código son pequeñas, entonces las instrucciones de recuento para su plataforma objetivo serán relativamente sencillas. Si tienes un simulador que puede ser aún más fácil. (Dependiendo del código puede necesitar hacer una maqueta para asegurarse de que se ejecute, pero probablemente sea más fácil que contar las instrucciones si tiene una gran cantidad de código para analizar)

Si su crítica el código es grande, entonces es posible que deba hacer algo similar a la sugerencia de JesperE. A menos que su aplicación esté dirigida a una industria increíblemente sensible a los precios, lo más probable es que el cliente esté dispuesto a aceptar un poco de holgura en los cálculos, por lo tanto, es mejor sobreestimar que sobreestimar sus requisitos de CPU.

Donde me diferenciaría de la sugerencia de JesperE es sugerir no concentrarse en MHz sino en el MIPS real de los objetivos. Por ejemplo, compila y ejecuta tu código en una plataforma de prueba, si tienes un generador de perfiles que puede ser mucho mejor. Luego compile su código para el objetivo del cliente y haga una comparación aproximada del número de instrucciones en el ejecutable resultante. Puede incorporar esta relación, junto con los MIPS relativos de los procesadores de prueba y destino, en el cálculo del tiempo de ejecución.

Answer 5

Usted dice que su software es altamente portátil, por lo que mi sugerencia sería ejecutar el software en la plataforma más cercana en la arquitectura del procesador, conjunto de instrucciones del procesador y tipo de memoria/bus periférico. Mida la rutina más larga que tiene que ejecutarse en tiempo real y luego haga una estimación de cuánto tiempo se ejecutará en su arquitectura.

Answer 6

La mayoría de depuradores modernos le dan la capacidad de ver las instrucciones consumidas, por ejemplo; RVDS. Además, puede usar emuladores de procesador para obtener una idea decente de las instrucciones consumidas sin ejecutar realmente en la plataforma (si su código es independiente, como un códec o un módulo criptográfico y no depende de la placa), tenga en cuenta que esto le dará instrucciones, no ciclos Los ciclos se verán afectados por los detalles de la placa (por ejemplo, estados de espera, acceso a memoria, etc.)

Answer 7

En dos de las arquitecturas de procesador que utilizo (MSP430F5X y AVR32) hay un registro de conteo cíclico de hardware integrado en el procesador.Normalmente tengo un esquema en el que, cuando el procesador no está ocupado, se coloca en un estado inactivo de baja potencia con el núcleo del procesador detenido. Entonces hay dos opciones para calcular la carga real del procesador. Puedo establecer un punto de interrupción en una función de temporizador periódica y leer el número de ciclos de procesador ejecutados o puedo instrumentar procesos particulares leyendo este registro al inicio y al final de su operación. El tiempo de inactividad del procesador no aparece en el conteo cíclico ya que la CPU se detiene por este tiempo.

No especifica la arquitectura de su procesador, pero esta capacidad puede estar presente.

Answer 8

RapiTime afirma que puede proporcionar una estimación probabilística del peor tiempo de ejecución para su objetivo. No lo he usado personalmente, pero he visto sus presentaciones ...

Si su objetivo es similar al de su cliente, probablemente pueda escalarlo para estimar el WCET en su plataforma. Luego pueden comparar eso con el tiempo "libre" que tiene su sistema actual.