En Una crítica de Common Lisp escrita por Rodney A. Brooks y Richard P. Gabriel de Stanford en 1984, se discuten algunas decisiones de diseño retenidas por el comité de normalización de Common Lisp. Si bien la mayor parte de la discusión sigue siendo válida, hay dos declaraciones que se refieren a la tecnología disponible en ese momento y pueden ser falsas hoy.
Estas dos declaraciones son:
Se descartaron demasiados costos del lenguaje con la advertencia de que "cualquier buen compilador" puede hacerse cargo de ellos. Nadie ha escrito aún, ni es probable que lo haga sin un esfuerzo tremendo, un compilador que hace una fracción de los trucos que se esperan de él.
Como soy un principiante de Common Lisp, o incluso un aprendiz, no puedo ser más específico que los autores. Parecen indicar que se ha incorporado una gran generalidad y flexibilidad en varios aspectos del lenguaje, lo que hace que escribir un buen compilador sea bastante difícil.
En COMMON LISP se puso demasiado control sobre la aritmética de coma flotante. Y ciertamente, aunque se puede lograr el comportamiento correcto de un programa intensivo en coma flotante, el rendimiento puede variar enormemente.
Según tengo entendido, parece que escribir código numérico eficiente en Common Lisp es posible pero más desafiante de lo que tiene que ser.
Esto fue hace treinta años. ¿Cómo debería considerar esta declaración hoy si estoy dispuesto a escribir programas Common Lisp para una de las implementaciones comunes de software libre (CLISP, SBCL et al.)?
fuente
Respuestas:
El artículo es interesante en muchos sentidos.
La parte más interesante es esta: los autores falsificaron el artículo de 1984 solo dos años después, en 1986. Brooks y Gabriel desarrollaron un compilador Lisp altamente optimizado y lo vendieron comercialmente con mucho éxito durante varios años: Lucid Common Lisp (PDF).
El mantenimiento para este compilador Lisp todavía está disponible en LispWorks : ahora se llama Liquid Common Lisp .
Las optimizaciones del compilador de Liquid CL se documentan en el Capítulo 3 de la Guía avanzada del usuario : Optimización de los programas Lisp .
Se han escrito e implementado varias aplicaciones comerciales en Lucid CL. Por ejemplo, en mi ciudad natal, el primer sistema de información de transporte público para el HVV (Hamburger Verkehrsverbund) se implementó utilizando Lucid CL en una estación SPARC de SUN. Estaba disponible para el público en las estaciones de tren utilizando una gran pantalla táctil y en el centro de llamadas.
Lucid CL tuvo éxito porque su compilador de modo de producción creó aplicaciones rápidas de Common Lisp, principalmente para plataformas Unix / RISC.
Brooks y Gabriel están escribiendo sobre Lucid Common Lisp en 1986:
Por lo tanto, acababan de implementar lo que la Crítica A de Common Lisp decía que era difícil o imposible.
Hoy en día, las implementaciones más avanzadas están haciendo muchas optimizaciones, pero el hardware también es 1000 veces más rápido que lo que teníamos en 1984. Un VAX 11/780 tenía un MIPS (millones de instrucciones por segundo) y una máquina Lisp también estaba en ese rango Un Motorola 68000 tenía una frecuencia de reloj de 8 MHz.
La crítica sobre el rendimiento de coma flotante y el rendimiento generalmente variable sigue siendo válida, pero esto refleja la elección de los implementadores. Algunas implementaciones no se desarrollan como compiladores de alto rendimiento. Su enfoque principal podría ser la portabilidad, la compacidad u otra cosa y, por lo tanto, tienen diferentes objetivos de implementación.
Como usuario / desarrollador, uno no está obligado a escribir código portátil y usar todos los más de diez sistemas Common Lisp actualmente admitidos. Utilice la implementación que mejor se adapte al problema de la aplicación.
fuente
Cuando se escribió este documento en 1984, una computadora con 1 megabyte de RAM y un disco duro de 20 megabytes, capaz de sentarse en su escritorio, era un gran problema. Naturalmente, surgirán disputas sobre la practicidad de un lenguaje de tan alto nivel como Lisp en hardware tan espartano. Los avances tanto en hardware como en tecnología de compilación que han tenido lugar desde entonces han hecho que los programas Lisp sean mucho más fáciles de escribir y ejecutar, independientemente de cualquier ineficiencia numérica que pueda estar presente en el lenguaje.
Los programadores a menudo intercambian eficiencia computacional por eficiencia de programación. Lisp puede ser un lenguaje lento (en algunas implementaciones, pero también otros lenguajes), pero también tiene una reputación bien merecida por su rápido desarrollo, y muchos programas no requieren una infraestructura altamente optimizada para exhibir un rendimiento adecuado.
La elección de la implementación de Lisp puede afectar en gran medida el perfil de rendimiento de sus programas. Por ejemplo, CLISP admite fácilmente que "si su código es muy numérico, es posible que prefiera CMUCL". Varias implementaciones modernas de Lisp (y Scheme) le permiten especificar sugerencias de tipo numérico, lo que aumentará el rendimiento numérico.
En resumen, la situación es mucho mejor hoy de lo que era entonces.
fuente