Prácticamente nunca, pero si fuera por intuición, me equivocaría más a menudo.
El problema probablemente radica en tratar de asignar costos a la programación de abstracciones de modelos.
La cuestión de cómo hacer que el código se ejecute rápido puede dividirse en
- como es el problema
- ¿Cómo es el modelo de programación ?
- ¿Cómo es el modelo de procesamiento ?
- ¿Cómo es la arquitectura ejecutora ?
Saber que el problema no suele ser un problema una vez que ya ha escrito un código e intenta optimizarlo, así que omita eso.
- ¿Qué temas debo estudiar para obtener un trabajo de probador de software como nuevo?
- Mi empresa me ofreció un puesto de gestión de línea en un entorno Agile / Scrum. ¿Tiene sentido?
- ¿Cuáles son los rasgos de un desarrollador de software promedio y cómo se mejora de un desarrollador de software promedio a un buen desarrollador?
- ¿Qué deben saber los ingenieros de software principiantes sobre ingeniería de software?
- ¿Es 'ágil' fundamentalmente opuesto a cómo operan las grandes empresas?
Un modelo de programación proporciona un conjunto de operaciones para expresar el problema. El conjunto seleccionado no es inherentemente rápido o lento, es correcto o incorrecto. Adjuntar costos a las operaciones en este nivel solo va a causar sorpresas cuando la tecnología cambie por debajo.
Un modelo de procesamiento es un nombre para la idea de alto nivel de cómo se implementan las operaciones en el modelo de programación. El detalle de este modelo mental puede variar desde “se ejecuta en la caja” hasta “este bucle se traduce en operaciones vectoriales porque tengo un compilador que reconoce la independencia de las iteraciones y un procesador con registros vectoriales de 4 valores de ancho” . Confiando en lo primero, el rendimiento estará lleno de sorpresas. Con algo como esto último, se puede elaborar un modelo de rendimiento , que es un conjunto de ecuaciones que relacionan las operaciones de software con las operaciones de hardware mediante el cálculo de qué familia de operaciones de hardware resultan de algunas de las operaciones del modelo de programación. Combine esto con pruebas sintéticas que se aproximen estadísticamente al costo de las operaciones de hardware particulares utilizadas, y comienza a parecer una estimación de las interacciones que tendrá el programa con la máquina en la que se está ejecutando.
La arquitectura de ejecución requiere conocimientos para saber qué operaciones de hardware están disponibles, determinar cuáles son utilizadas por el compilador y, por último, pero no menos importante, derivar los puntos de referencia que determinan las estimaciones de costos para las operaciones básicas.
Mi receta de libro de cocina iría:
- primero, lea sobre las operaciones de hardware de la arquitectura en ejecución,
- a continuación, muestree el rendimiento de un rango adecuado de sus primitivas usando varios patrones de acceso a memoria diferentes,
- luego, pruebe algunas construcciones simples para saber en qué lenguaje primitivo y compilador las asigna,
- derivar estimaciones de costos para programar primitivas de modelos como funciones que son paramétricas en el uso de la memoria y las instrucciones del procesador (quizás también comportamientos de tiempo de ejecución y del sistema operativo),
- y finalmente , mapee el problema en la opción más económica de primitivas del modelo de programación según las estimaciones.
(… además, mida qué tan bien funcionó al final …)
Los efectos de las operaciones de alto nivel siempre serán una sorpresa si espera que tengan un costo inherente, su costo siempre es el resultado de lo que está ejecutando su código, y eso no es una constante trivial. Al hacerlo de abajo hacia arriba, no hay sorpresas, porque más o menos planeaste lo que va a suceder.
Sin embargo, hacer todo esto es demasiado trabajo para una aplicación grande completa, así que primero escriba un código lento y correcto, haga un perfil de lo que lo detiene más y bucee con todo detalle solo en esa parte.
Es más problema, pero saca las sorpresas.