¿Por qué las optimizaciones de todo el programa no son más frecuentes ahora?

Question

Pregunta principal: ¿Por qué los optimizadores de programas generales o incluso los especializados no forman parte de nuestra vida cotidiana?

empecé a pensar en esto después de leer SuperCompilers, de White paper LLC, que discute su método de "supercompiling" o metacompiling fuente de un programa de (generalmente) lograr una versión más rápida que hace la misma funcionalidad que el programa original. Básicamente, pasan por la ejecución de un programa y vuelven a compilar en el mismo idioma de destino. Al hacer esto, ocurren optimizaciones naturales; por ejemplo, una función de búsqueda binaria general podría estar especializada en la búsqueda binaria de una matriz de 100 elementos, si el programa de entrada utiliza matrices de 100 elementos con frecuencia.

Partial Evaluation es quizás un tipo más estrecho de optimización de todo el programa, donde la fuente del programa se reduce/evalúa en función de un conjunto fijo de entrada dejando abierta la entrada desconocida para su evaluación en tiempo de ejecución. Por ejemplo, una función general x^y, si se da que y = 5, se puede reducir a x^5 o tal vez algo así como (x * x) * (x * x) * x.

(Me disculpo por mis descripciones crudos de estas dos técnicas)

optimizaciones del programa Históricamente enteros, como los dos anteriores sería demasiado intensivo de memoria para llevar a cabo, pero con nuestras máquinas tienen gigas de memoria (o usar algo como la nube), ¿por qué no hemos visto muchos evaluadores parciales de código abierto y cosas así? He visto algunos, pero hubiera pensado que esto sería una parte regular de nuestra cadena de herramientas.

• ¿Es miedo (programador por temor a la transformación de su código al introducir errores)?
• ¿No vale la pena (es decir, para las aplicaciones web el cuello de botella es E/S, y este tipo de optimización parece estar ahorrando tiempo de CPU)?
• ¿Es este tipo de software tan difícil para escribir?
• ¿O es mi percepción de simplemente incorrecta?

Answer 1

Creo que es sobre todo que su percepción es incorrecta. La mayoría de los compiladores son compatibles con las optimizaciones de "todo el programa" (interprocedimiento) y la optimización guiada por perfil para guiar al optimizador en función del uso real.

La razón principal por la que la mayoría de la gente no se ha dado cuenta es que al final, estas diferencias apenas hacen la diferencia suficiente como para realmente darse cuenta de que se preocupan mucho por ellas. La disponibilidad general de estas herramientas también sucedió alrededor del tiempo en que simplemente no importaban mucho para la mayoría de los propósitos. Las CPU ahora son tan rápidas que nadie piensa dos veces antes de tener un código ejecutándose en una máquina virtual Java, que se ejecuta dentro de una máquina virtual VMWare (y ni siquiera sería particularmente raro tener una tercera máquina virtual capa).

Eso agrega gastos generales enanos la mejora que normalmente puede esperar de la optimización global. Para la mayoría de las personas, las diferencias de velocidad tienen que ser bastante grandes para importar nada más (y las mejoras de la optimización global rara vez califican).

Answer 2

Supongo que es un problema de huevo de gallina, déjame explicarte esto.

Con supercompilación (SC), el programador puede escribir código más abstracto sin pagar los costos de tiempo de ejecución (para la compilación de lanzamiento, puede ser poco práctico hacerlo para cada compilación de depuración).

Entonces, si hay (hoy) no hay SC, los programadores escriben código de "bajo nivel", por lo que nadie escribe un código mejor y necesita SC para hacer el trabajo pesado.

Lo único que puede evitar SC en el mundo real es la necesidad de un (muy) alto nivel de inteligencia para la supercompilación de todo el programa. OpenCog o cualquier otra AI AGI-ish pueden ser de gran ayuda para resolver este último problema. Este no es el caso si solo partes pequeñas deben ser SC'ed (como métodos únicos). Otra razón, que SC no es hoy en día común, es relativamente nueva (en comparación con una tecnología de compilación mucho más antigua), SC fue desarrollada en los años 70 y la escala de costos de compilación no lineal, por lo que no es un objetivo del grandes vendedores de compiladores

Con más código abstracto quiero decir

• posibilidad de escribir tipo de datos de código independiente, por lo que al final hacer plantillas/genéricos obsoletos (en su mayor parte)
• el programador puede invocar en cualquier punto cualquier tipo de intérprete, el SC debería en la mayoría de los casos ser capaz de optimizarlo completamente para que el resultado final se vea como una versión artesanal del código que el programador tiene en mente. Sin la necesidad de realizar el "desenrollado" manual y una productividad mucho más alta (porque el programador no necesita modificar el código de "bajo nivel", puede trabajar en un nivel mucho más alto

Answer 3

Gracias por preguntar qué Considero una pregunta profunda, y por favor perdonen mi llama ...

Evaluación parcial es un hermoso concepto cuya belleza se ha perdido por completo en el deseo interminable de construir herramientas inteligentes pero sin cerebro para sacar las cosas de las manos/las mentes de los programadores. Es por eso que no ha hecho mucho.

Siempre que escriba un programa m A que escribe un programa B (que es una habilidad básica que todo programador (en mi opinión) debe saber usar, y cuando se usa) está haciendo una evaluación parcial. Dado que algunos de los datos de entrada se conocen con anticipación y no cambian con frecuencia, no es necesario que el programa siga probando todo el tiempo. Puede tomar la información que casi nunca cambia y pasarla como entrada a A, y hacer que A imprima el programa B que simplemente "conoce" la entrada estática, por lo que todo lo que tiene que hacer es manejar la entrada dinámica impredecible.

Pero tan pronto como alguien intenta escribir una herramienta para hacer una evaluación parcial, están sacando el cerebro del programador del circuito, y eso es lo que lo mata.

Lo mismo vale para la optimización en general. Cuando el programador rinde su juicio a una herramienta, obtiene muy pocos resultados, porque no hay ninguna herramienta (al menos) que pueda comprender el código como lo hace el programador.

Sin duda, es que vale la pena intentar para hacer herramientas que entienden el código, así como el programador, pero es absurdo suponer que se ha hecho .