ron escribió:ZX81, una pregunta !
Basándome en experiencias de otros coders que han decidido portar sus emus de Java a C, ganando mucho y teniendo un nuevo emulador que no depende de un runtime de ejecución, que además podrás compilar en Linux, Win y Mac ¿ porque no portas tu JSSpeccy a C ?
Tan solo es saber que opinas al respecto y que pasa por tu cabeza, ya que tu JSpeccy a mi me parece un buen candidato a ello.
Originalmente, allá por el siglo pasado, yo quería hacer un emulador en C++ usando las librerías Qt. De hecho,
ftp://ftp.worldofspectrum.org/pub/sincl ... 0.9.tar.gz es el mudo testigo de mis primeras pruebas. Ahora, si tienes tiempo y suficiente curiosidad, intenta hacer una prueba. Te pillas un Linux normalito, especialmente una de estas distribuciones modernas que no te instalan todo por defecto, te bajas el último Fuse y que reto a que lo compiles con soporte de todo lo que puede llevar. En la época en la que Fuse no estaba en los repositorios de las principales distribuciones había que compilárselo uno mismo y te aseguro que no estaba al alcance de mucha gente esa proeza. En esta Fedora 20 que estoy utilizando, Fuse está enlazado con 71 librerías dinámicas diferentes. Y cuando hayas acabado, compílalo en Windows (32 y 64 bits, please) con un compilador que no sea el Visual Studio. Y cuando acabes con ese segundo, lo repites en MacOS-X. Y cuando hayas acabado, te pillas un Unix distinto (AIX, Solaris, HP-UX) y lo compilas también ahí.
Mucho antes de que hayas llegado al final, ya sabrás porqué decidí cambiar de tercio y escribirlo en Java. Como está probado en un montón de sistemas y funciona todo en todas partes, creo que he cumplido con mi objetivo con creces, y eso que no tengo en casa más que Linux para probar. Solo tengo una curiosidad, y es saber cómo se ejecutaría en una máquina con procesador ARM de esas que venden ahora como Smart TV.
Yo no sé en el caso de otros emus de máquinas más complejas cuanto se ganaría por pasarlo a C++ (a C ni se me ocurriría). Pero el consumo de CPU en una máquina dual core a 24 Ghz da como para que a máxima velocidad la carga de cintas funcione al 6000%. Curiosamente, haciendo eso mismo en esa misma máquina, Fuse no va mucho más deprisa (¿se ha molestado alguien en probarlo, o funcionamos únicamente por habladurías como las viejas de los pueblos?). El caso es que yo mismo me obcequé en hacer el core Z80 lo más rápido posible, y luego resulta que haciendo profiling del emulador, un frame tarda habitualmente mucho menos de 2 ms, la décima parte del tiempo.
¿Qué ganaría entonces pasándolo a C++?. ¿Satisfacer a los maniáticos de Java?. Creo que necesito una razón mejor para hacer ese ingente trabajo. Hablamos de más de 20k líneas de código y aún eso no es lo importante, porque muchas cosas, como el sonido, se manejan de manera MUY distinta en Linux, Windows y MacOS-X (por no hablar de otros sistemas), y los compiladores no son todos el GCC, y ni siquiera se puede contar con que siempre tengas la última o penúltima versión de GCC, lo que significa multiplicación de problemas. Como sería un emulador "nuevo", no estaría en los repos de las distros de Linux, con lo que la gente se lo tendría que compilar ella misma (la situación de Fuse hace aún menos de 5 años).
Si hubiera visto que el emulador, haciendo lo máximo posible de que hubiera sido capaz, funcionaba a paso de tortuga y que resultaba inútil, hubiera cambiado de tercio. Pero es que se ha probado en máquinas de hace cerca de 10 años y funciona al 100% de velocidad (aunque cargue a solo el 900%). Java existe en casi todos los sistemas populares y es gratis (y será, porque la OpenJDK se encarga de eso). Esconde todas las diferencias grandes y pequeñas entre sistemas y me puedo centrar en lo que importa, cosa no baladí en un proyecto que cada vez es más grande y el que lo mantiene es uno solo.
Ahora soy yo el que pregunta para que se le responda con la mayor sinceridad, ¿existe alguna
razón técnica de peso y bien fundada para hacer el trabajazo que supone reescribir el emulador en C++?- Awaiting answers...