Una optimización "mágica" para bibliotecas dinámicas en GNU/Linux

Tengo un proyecto con una batería de casos de prueba que tarda horas en completarse. Esta semana encontré una opción de compilación que con un mínimo esfuerzo me redujo el tiempo total de la prueba en 37% (muchísimo!). Y por supuesto que no es -O# (sería muy obvio), y tampoco es LTO (pero algo tiene que ver). Es algo un poco más escondido y menos obvio, que al menos yo no sabía, así que lo comparto.

Embeber recursos dentro de un ejecutable en GNU/Linux

Trabajando en un nuevo proyecto que tiene que ver con visualización y usa OpenGL me encontré con el problema de cómo distribuir los shaders. Los shaders son, para este caso, simplemente archivos que el ejecutable necesita encontrar. Mi problema es que quiero un ejecutable que no requiera de otros archivos, porque eso puede generarme algunos inconvenientes.

La pregunta es entonces ¿cómo embeber recursos en un ejecutable en GNU/Linux? ¿Cómo hago que esos archivos extra estén dentro del ejecutable, y cómo los recupero desde mi código C++? La respuesta es simple, nada de otro mundo; pero creo que poco conocida. No es la primera vez que tengo este problema, pero en las anteriores no sabía ni había podido encontrar la respuesta.

Finalmente, el paso a wx3 y unicode en Zinjai y PSeInt

Hace años que me quejo de mí mismo por estar atado a la versión 2.8.12 en modo ansi de wxWidgets. Siempre decía que el cambio a las versiones 3.x, junto con el paso al modo unicode, requería muuucho trabajo. Necesario, sí, pero demasiado para el poco tiempo que disponía. El problema de macOS y los 64bits me obligó a concretar en parte la tan postergada migración de PSeInt. Quedaron conviviendo ambas versiones, y de a poco la versión 3 fue ganando terreno. Sin embargo, culpa de estos cambios aparecieron errores nuevos, algunos bastante notorios.

Reduciendo las dependencias de PSeInt en GNU/Linux

Así como me vi obligado a repensar el "paquete" de PSeInt para macOS a raíz del problema de los 64bits; tuve problemas similares en GNU/Linux. Para empezar, una de las principales bibliotecas del sistema que necesito ya no aparece en todas las distribuciones. Por seguir, una nueva que agregué por el tema del renderizado de texto también trajo sus problemas.

Los desafíos de portar PSeInt a macOS Catalina (3/3): Los últimos detalles

Ya conté los problemas y soluciones para poner en marcha un toolchain para las nuevas versiones de macOS, y la migración del código de wx 2 ansi a wx 3 unicode, en GNU/Linux. Solo me faltaba combinar todo esto para ver si andaba en macOS, si tenía un paquete para publicar en el sitio. Por supuesto que no anduvo a la primera. He aquí los últimos detalles de esta historia.

Los desafíos de portar PSeInt a macOS Catalina (2/3): PSeInt vs. wxWidgets

Siguiendo con la serie de problemas y soluciones relacionados a la compilación de PSeInt para macOS Catalina, ahora toca hablar de la relación entre PSeInt y la biblioteca wxWidgets. Resumiendo: PSeInt estaba escrito para una versión muuuy vieja de wx; y además cuando lo empecé había dos formas de compilar wx, y PSeInt usaba la que ya casi no existe. Por esto, aún teniendo un toolchain nuevo que puede compilar una wx nueva, el código de PSeInt requirió de muchísimos cambios y ajustes.

Los desafíos de portar PSeInt a macOS Catalina (1/3): El Toolchain

Finalmente PSeInt anda (eso parece) en macOS de 64bits! Las versiones anteriores eran de 32bits, y la novedad en macOS Catalina es que ya no acepta aplicaciones de 32bits. Las versiones previas de macOS habían empezada a avisar que en cualquier momento esto iba a suceder. Pensé que esperarían más tiempo, pero no, pasó, y PSeInt no estaba listo.

¿Por qué? ¿No es simplemente recompilar todo con otras banderas? Resulta que no, que tenía vaaarios problemas. El primero de ellos era obtener acceso fácil (automatizable con scripts) y permanente (no una mac prestada, algo que tenga siempre en mi propio sistema) a un toolchain adecuado.

Combinando plantillas en ZinjaI

Muy lentamente, la variedad de complementos para ZinjaI va creciendo. La mayoría de ellos corresponden a bibliotecas como GLUT, wxWidgets, OpenCV, SFML, SQLite, etc. Entre otras cosas, lo principal que provee la biblioteca es una configuración de las opciones de compilación y enlazado lista para poner un proyecto en marcha en tres clicks. Esto sería probablemente lo más difícil de reemplazar para muchos usuarios. No me simpatiza, pero las consultas que recibo me demuestran que muy pocos se toman el tiempo de entender qué hacen realmente el compilador y el IDE por debajo; y se limitan a usar la configuración que viene con la plantilla como caja negra... mientras funcione.

Organización de los archivos de un proyecto (parte 2)

En en el post anterior comenté sobre los motivos para organizar los archivos de un proyecto de una forma más estructurada que la que ofrece ZinjaI al crear un proyecto, y sobre una estructura de subcarpetas más o menos habitual en proyectos medianos. Ahora toca ver cómo adaptar el proyecto de ZinjaI a esta nueva organización.

Organización de los archivos de un proyecto (parte 1)

Casi todas las plantillas de proyecto de ZinjaI crean una única carpeta en la que los fuentes, el archivo de proyecto y eventuales extras van juntos, y solo se separan en una subcarpeta (debug/release) los archivos generados en la compilación. Esto es lo más directo para empezar, y funciona bien cuando es un proyecto pequeño.

Pero cuando los binarios empiezan a requerir archivos de datos/recursos, el proyecto crece y tenemos varias decenas de fuentes, la arquitectura se complejiza y empezamos a dividir en módulos o bibliotecas, etc; entonces esa organización se vuelve engorrosa, la carpeta del proyecto, una ensalada; y hay que hacer algo al respecto.

La mayoría de los alumnos no considera esto hasta que es demasiado tarde, simplemente por falta de experiencia (o al menos eso me pasó a mí y lo aprendí por las malas).

¿Qué va en el instalador?

Supongamos que hicimos una aplicación con ZinjaI, y ahora la queremos distribuir. No vamos a pretender que cualquier usuario que quiera usar la aplicación deba instalar ZinjaI, los complementos y conseguirse el código fuente, ¿no? ¿No? ¿Nooo? !NO! Lo razonable es armar un instalador que copie en el sistema del usuario el ejecutable de nuestra aplicación y cualquier otra cosa que esta necesite. De eso habla este post; de cómo generar ese ejecutable y cómo determinar qué más necesita.

MinGW64 disponible como complemento para ZinjaI

Finalmente logré hacerme un poco de tiempo para completar la compilación de las bibliotecas de la sección complementos con mingw64, y empaquetar todo, también al mismísimo compilador. Dejó aquí instrucciones para instalar y usar esto, junto con algunas aclaraciones importantes para quienes no tengan del todo claro qué implica el cambio de compilador.

Nota obvia: Este post es solo para quienes utilizan ZinjaI en Windows; ya que en GNU/Linux el compilador no depende de ZinjaI, sino de la distribución de GNU/Linux que se use.

Release vs. Debug

He visto cosas que ustedes no creerían: programadores haciendo benchmarks de código sin optimizar, generando instaladores con ejecutables en modo debug, desdoblando loops a mano, haciendo inlining mediante copy-paste, distribuyendo los .o y olvidándose los dlls, rayos-C++ brillar en la oscuridad cerca de la puerta de Tannhäuser... Y hablo de alumnos avanzados de la carrera, hasta algunos egresados.

Pensaba en escribir un post sobre cómo distribuir un programa generado con ZinjaI (mayormente sobre qué va en el instalador), pero inmediatamente noté que un punto importante era de esto de compilar en modo "release"... y entonces me parece mejor aclarar ese punto antes de continuar, y dejar lo del instalador para la próxima.

Actualizando MinGW

El toolchain que incluía hasta hace 2 días el instalador de ZinjaI para Windows estaba muy desactualizado. En el momento en que lo armé, la versión más reciente de gcc disponible era la 4.8. Actualmente ya está por liberarse la 6.3, aunque las 5.x son las consideradas más estables. Hace rato que quería actualizar lo que uso en ZinjaI, pero en Windows, cada actualización implicaba muchísimos dolores de cabeza.

Aplicando cambios sin reiniciar en C/C++ (toma 2 -cont.)

Hace poco les conté cómo usar bibliotecas dinámicas para emular una suerte de "edit and continue" en cierto tipo de programas. La idea es simple: la parte que quería poder editar durante la ejecución (conjunto de clases y funciones) va a parar a una biblioteca dinámica. En lugar de dejar que el compilador la enlace al ejecutable, voy por la vía complicada y realizo la carga de la biblioteca "manualmente". Esto me da la posibilidad de descargarla y volverla a cargar en cualquier momento (cuando cambie). El post detallaba cómo hacerlo en GNU/Linux; pero ahora me di cuenta que en Windows hay cuatro problemas nuevos e interesantes para tener en cuenta.

La compilación según ZinjaI (parte I)

Para que al presionar F9 en ZinjaI podamos ver nuestro programa ejecutándose tienen que ocurrir unas cuantas cosas. La más importante de ellas, es la compilación de ese programa. ¿Cómo construye ZinjaI las llamadas a GCC necesarias para compilar un programa? La respuesta varía según el modo de trabajo. Para programas simple (cpp único sin proyecto) pasa una cosa, para un proyecto pasa otra. En ambos casos la respuesta es compleja e involucra información de muchas fuentes diferentes. En esta serie de posts voy a documentar qué ocurre exactamente al presionar F9 para entender de dónde sale cada partecita de cada paso, y especialmente cómo se llega a la llamada final a GCC.

ZinjaI en Windows: ¿Qué compilador elegir?

Existen muchos ports a Windows de GCC y de las demás herramientas/bibliotecas afines. En ZinjaI siempre usé MinGW. En su momento, hace unos años, era la opción por defecto casi sin pensarlo, pero la situación ha cambiado. Para empezar, MinGW ha quedado atado por definición a los 32 bits, mientras que la mayoría de las PCs modernas y sus sistemas operativos son de 64. Para seguir, el ritmo de actualización de MinGW se ha ralentizado bastante, o al menos eso parece en comparación con la velocidad a la que han avanzado las demás versiones. El problema es que las alternativas son muchas, hay nuevas decisiones que hacer para elegir una, y desde mi punto de vista no emerge una opción claramente ganadora de todo esto.

MinGW64 y otras variantes para ZinjaI en Windows

Se supone que ZinjaI está preparado para configurar fácilmente más de un posible compilador. En GNU/Linux, suelo alternar entre gcc y llvm-clang sin problemas. Pero en Windows, el cambio es un poquito más delicado, porque el compilador y demás herramientas afines que están como parte de ZinjaI, y no del sistema. Si bien se suponía que era posible hacerlo de todas formas, y que teóricamente el cambio debía ser simple y directo, de la teoría a la práctica suele haber un buen trecho, y por eso no le tenía plena confianza a esta funcionalidad. Pero hace unos días finalmente lo probé y verifiqué que (muy sorprendentemente) funciona justo como esperaba. Y esto es algo muy bueno, porque ya es hora de empezar a utilizar 64bits. En este post les cuento cómo configurar otro MinGW que no sea el que trae ZinjaI, tomando una versión alternativa de 64bits como ejemplo, qué tiene esto de bueno, y cuáles son por ahora las limitaciones.

Bibliotecas externas en versión debug

Siempre pensé que era mejor utilizar versiones "release" de las bibliotecas de terceros en mis proyectos, para todas las compilaciones, aún en mis versiones para debug. Es decir, que si mi programa usa una biblioteca B, al depurarlo me interesa solo depurar mi parte. Agregar la información de depuración de B sería agregar ruido. Hace poco comprobé que esto no siempre es recomendable. Es algo que ahora me parece muy obvio, pero la verdad es que antes no le había dado importancia. Nunca había usado intensivamente una versión debug de una biblioteca externa, y por eso no había notado las muchas ventajas que esto tiene.

Corrigiendo un ejecutable sin reiniciar la depuración

En este post les vengo a mostrar una funcionalidad nueva en ZinjaI, que verán en la próxima versión (a publicarse dentro de pocos días), y que bien presentada parece mágica, aunque está  lejos de serlo. Con el ejemplo adecuado, puedo hacer que se parezca al maravilloso Edit & Continue de Visual Studio (la funcionalidad que realmente me maravilla y envidio de ese IDE que tan poco conozco). Consiste en la posibilidad de modificar el ejecutable mientras se está ejecutando, durante una pausa en una depuración, alterando el código fuente, recompilando, y continuando luego de la pausa desde el mismo punto con el binario nuevo como si nada. Estoy a años luz de ofrecer algo como eso de verdad, pero puedo hacer algunos trucos simples para emularlo en casos muy muy particulares. Vean el video y luego sigan leyendo.