Como estoy interesado en la inteligencia artificial, recientemente decidí probar Lisp. Después de compilar un muy basic application con el compilador de lisp común sbcl noté que el binario resultante era muy grande (alrededor de 43MB). Estoy interesado en el motivo de eso. ¿Es este un problema común para el ceceo (común) y cuál es el trasfondo técnico de este comportamiento?Lisp binary size
Hay varias arquitecturas diferentes en las implementaciones de Common Lisp:
Típicamente el intérprete y el bacalao de bytes El motor usa la menor cantidad de memoria. CLISP por lo tanto es muy pequeño. SBCL OTOH genera un código nativo relativamente grande.
En segundo lugar, hay varias maneras diferentes de crear aplicaciones:
Además de algunos más como compilando a DLL.
SBCL básicamente lo hace 1. Vacia la memoria que contiene los datos y el código, e incluye el tiempo de ejecución. Por lo tanto, todo lo que tenga en el sistema en ejecución (documentación, enlaces de código fuente, listas de argumentos, nombres de símbolos, información de depuración, el compilador en sí, ...) se descargará en la imagen + tiempo de ejecución. Además, el código nativo generado por SBCL es grande, existe potencialmente mucha información de código en la memoria de tiempo de ejecución y SBCL incluye toda su propia funcionalidad (incluido el compilador).
Durante el desarrollo, a menudo se trabaja (s/ed) con tales aplicaciones o imágenes sin optimizar (con el tiempo de ejecución externo) para ahorrar tiempo para cargar código y datos. Lo he usado yo mismo con imágenes que eran más grandes que 100MB.
LispWorks, por ejemplo, tiene 1 y 2. Tiene un proceso de entrega en el que puede eliminar elementos de forma selectiva (como la documentación, algunas funcionalidades como el compilador, referencias de origen, ...). Esto también está usando un agitador de árbol, que puede eliminar la funcionalidad no utilizada.
Optimizar una imagen también podría significar escribirla de alguna manera comprimida y descomprimirla en el inicio. SBCL permite esto, por ejemplo.
La variante 3 se realizó en el pasado, pero actualmente no está en uso (excepto en algunas herramientas y aplicaciones especializadas). Thinlisp, Stella, CycL, ... son tales herramientas de entrega. En el pasado, también había un proveedor comercial para dicha herramienta (pero esto ya no existe, IIRC, el último propietario de la misma es/era Oracle). Actualización: realmente mocl, lo hace un reciente generador de aplicaciones Common Lisp para iOS y Android. Toma un gran subconjunto de Common Lisp y lo compila en aplicaciones móviles pequeñas e independientes. Por ejemplo, en iOS genera código C compacto para el compilador de C proporcionado por Apple.
¡Gracias, eso es lo que estaba buscando! –
ECL compila en C y produce ejecutables bastante pequeños mediante el uso de bibliotecas compartidas, pero está limitado de muchas maneras. –
ECL tiene compilador/intérprete de códigos de bytes y compilación para el código nativo a través del compilador de C. ECL es generalmente más lento que SBCL y CCL, pero produce binarios muy pequeños. No estoy seguro de qué significa @SamuelEdwinWard por limitaciones (excepto por el hecho de que es más lento): es bastante completo y tiene varias funciones. ¿Podría explicar un poco sobre eso? –