CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 24 Oct 2017 03:17

Todos los horarios son UTC + 1 hora




Nuevo tema Responder al tema  [ 11 mensajes ] 
Autor Mensaje
NotaPublicado: 30 Jul 2012 14:59 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1855
Anuncio de Glk 0.7.4

El otro hilo que menciona, sobre arranque rápido (que he leido por encima y parece que se trata de incrustar una "partida grabada" junto con la obra, para evitar inicializaciones costosas), es http://www.intfiction.org/forum/viewtop ... f=7&t=5389


Arriba
 Perfil  
 
NotaPublicado: 01 Ago 2012 19:29 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2021
Ubicación: Chile
Joder, ¿ya pillaste el motivo por el que a Plotkin se le ocurrió esto ahora? Todavía no saben cómo diablos solucionar el problema de la lentitud de I7 (y esta variante es nueva: la lentitud en la inicialización). La solución es asquerosa. No tengo otras palabras para definirlo. Y gradualmente Glk se ha ido convirtiendo en un montón de mierda, en una abominación llena de parches.

Citar:
So the author compiles the game, blorbs it up with a zero-length data chunk, and runs it. There is now an autorestore save file ready to do. The author then blorbs the game up *again*, replacing the zero-length chunk with this new save data. This is a hassle (and you have to repeat it every time you recompile your game, because you need the save data to be compatible). But it's easily scriptable.


Yo es que este tipo de decisiones no las entiendo... sobre todo viniendo de gente capacitada.

TADS3 carga muchísimo más cosas y va raudo como el rayo.

No tengo intenciones de seguir dando soporte a nada con Glk. Una pena :-/

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/


Arriba
 Perfil  
 
NotaPublicado: 02 Ago 2012 15:58 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1855
Eliuk Blau escribió:
Joder, ¿ya pillaste el motivo por el que a Plotkin se le ocurrió esto ahora? Todavía no saben cómo diablos solucionar el problema de la lentitud de I7 (y esta variante es nueva: la lentitud en la inicialización). La solución es asquerosa. No tengo otras palabras para definirlo. Y gradualmente Glk se ha ido convirtiendo en un montón de mierda, en una abominación llena de parches.

Citar:
So the author compiles the game, blorbs it up with a zero-length data chunk, and runs it. There is now an autorestore save file ready to do. The author then blorbs the game up *again*, replacing the zero-length chunk with this new save data. This is a hassle (and you have to repeat it every time you recompile your game, because you need the save data to be compatible). But it's easily scriptable.


Yo es que este tipo de decisiones no las entiendo... sobre todo viniendo de gente capacitada.

TADS3 carga muchísimo más cosas y va raudo como el rayo.

En TADS existe un método que no es tan diferente. Se explica en el capítulo Program Initalization, del System Manual. El use-case que se menciona ahí es "Derived information". Parece que está mucho mejor integrado en el proceso de compilado+enlazado. Supongo que la idea para Inform7 (el "easily scriptable" del texto que citas) es que sea transparente también al autor si utiliza la herramienta adecuada.

No sé si el ejemplo que se menciona
zarf escribió:
(E.g., Reliques of Tolti-Aph burns bazillions of Glulx CPU cycles in "when play begins" code.)
es sobre datos (carga de tablas o similar) o si es preparación de reglas u algún otro proceso ineficiente de Inform. ¿Alguien sabe?

Si entiendo bien la situación, ahí podría residir la diferencia más notable y es que intentar "saltarse" código ineficiente generado por el compilador de Inform mediante la precarga parece un hack. Si ese es el único tema de fondo... estoy contigo, Eliuk, pero... qué sabre yo. Lo mismo intentar optimizar más el compilador no merece la pena.


Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2012 03:21 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2021
Ubicación: Chile
dddddd escribió:
No sé si el ejemplo que se menciona
zarf escribió:
(E.g., Reliques of Tolti-Aph burns bazillions of Glulx CPU cycles in "when play begins" code.)
es sobre datos (carga de tablas o similar) o si es preparación de reglas u algún otro proceso ineficiente de Inform. ¿Alguien sabe?

Si entiendo bien la situación, ahí podría residir la diferencia más notable y es que intentar "saltarse" código ineficiente generado por el compilador de Inform mediante la precarga parece un hack. Si ese es el único tema de fondo... estoy contigo, Eliuk, pero... qué sabre yo. Lo mismo intentar optimizar más el compilador no merece la pena.


Es justamente eso. Tolti-Aph (y algunas otras aventuras, sobre todo las de Emily) generan montones de tablas de datos para codificar cosas como respuestas, o laberintos, o mapeados, o IA, etc. Pero todo en runtime. Y todo eso se genera un montón de carga que Glulx (o I7, ya ni siquiera tengo clara la diferencia entre estos dos), no son capaces de procesar en tiempos sensatos.

En el caso de Tolti-Aph, y según recuerdo, la carga de inicialización consistía en el sistema de juego de Rol que se ha programado para la aventura, que requiere de decenas de reglas de calculo muy à la I7. Eso se puede mirar en el propio código. Y muchas de esas reglas mapean tablas y otros tipos de estructuras de datos en runtime. Y estamos hablando de una VM que no sabe nada de multihilos o multiprocesos o paralelismo ni nada... así que los tiempos de cálculos se van al carajo y se producen esos cuellos de botella. Y en lugar de arreglarlos de la manera correcta, los "parchean" con una solución que requiere de "snapshots" post-calculo, de un estado donde el procesado de los datos ya ha sido realizado. Es que es una ingeniería, pero de la mala... joder :-/

TADS3 tiene estructuras de datos muy complejas y no veo que cruja por ello. Pero Glulx+I7 se delata estrepitosamente... y me parece que gran parte de la culpa es del enorme monstruo parcheado que es ahora Glulx y Glk y de la falta de optimización evidente del preprocesador NI y de la propia librería... El compilador de Inform está muy bien... pero NI genera código extremadamente estúpido. Y Glulx no puede con él. Si no puede, y además la mejoras requieren el decantar en montones de "parches", la solución EVIDENTE es replantearselo todo y crear una nueva VM diseñada exclusivamente para I7 y para las exigencias MODERNAS que I7 está explotando. Pero en fin... que en asuntos de vacas sagradas... los mortales sobramos. xD

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/


Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2012 14:41 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4614
Entendiendo que la solución es una cutrada,como lo fue la anterior, también hay que entender que a veces la solución correcta es mas difícil o laboriosa que la solución "parche". Con las edades y responsabilidades que gastan (gastamos) ya algunos, es posible que esta solución no solo sea la mas rápida, sino que sea la única alcanzable.

Insisto en que entiendo que pueda considerarse incorrecta desde el punto de vista técnico, pero a veces hay que ser flexibles para llegar a un objetivo.

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com


Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2012 16:06 
Desconectado
Betatester
Betatester
Avatar de Usuario

Registrado: 24 Dic 2010 14:37
Mensajes: 889
Acabo de descargar ROTA sin apañar ni nada de aquí:

http://www.caad.es/informate/infsp/Reli ... index.html

(900kb, para una aventura sin ninguna multimie... multimedia, así que tiene un porrón de líneas de código, tablas y demás) Le he pedido a mi gárgola viejuna (sin actualizar ni nada) que la ejecute y me ha dado el prompt de manera instantánea.

Con el mismo ordenador me he descargado la última versión de 15 meses y un día, de la página del CAAD (35 megas :(), he clickado en el .bat y me ha tardado un rato en arrancar la aplicación JAVA y después de eso se ha tirado al menos dos o tres segundos cargando cosas antes de empezar con la aventura en sí.

¿¿De qué ineficiencia de I7 estamos hablando exactamente?? Flipáis un poco, la verdad.

(Todo lo cuál no quiere decir que el Glulx no me parezca una máquina de mierda).


Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2012 16:57 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2021
Ubicación: Chile
Johan Paz escribió:
¿¿De qué ineficiencia de I7 estamos hablando exactamente?? Flipáis un poco, la verdad.


Viniendo de alguien que defiende a I7 a pies juntillos, aún reconociendo sus falencias...

En cualquier caso, estamos hablando de una ineficiencia reconocida por Andrew Plotkin (el creador de Glulx y Glk) y por el propio Graham Nelson. (Que en este caso, ya debería apartar tus dudas.)

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/


Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2012 17:14 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2021
Ubicación: Chile
Uto escribió:
Entendiendo que la solución es una cutrada,como lo fue la anterior, también hay que entender que a veces la solución correcta es mas difícil o laboriosa que la solución "parche". Con las edades y responsabilidades que gastan (gastamos) ya algunos, es posible que esta solución no solo sea la mas rápida, sino que sea la única alcanzable.

Insisto en que entiendo que pueda considerarse incorrecta desde el punto de vista técnico, pero a veces hay que ser flexibles para llegar a un objetivo.


Estoy de acuerdo, Uto, en todo lo que dices y me parece muy razonable todo. Y sí, como te digo, me parece correcto y estoy muy de acuerdo.

Mis comentarios anteriores vienen por el hecho de que después de tantos años se siga tal cual, y recurriendo a parches, en lugar de hacer todo bien desde el principio. El autor de Glulx ha usado mucho de su tiempo en proyectos relacionados con Glulx hechos desde cero (es solo cosa de mirar su web), e incluso pidió financiación para dedicarse sólo a creación de IF y a la mejora de Glulx, y recibió toda la financiación que pidió y más.

Y ha sido consecuente y ha estado mejorando Glulx. Eso no lo podemos negar (y tampoco digo que sea su obligación "atender" nuestras necesidades, porque todo lo hace como hobbie personal). Sin embargo, lo que me asombra es la falta de... no sé qué palabra usar... "sobriedad", "sensatez", en las desiciones (o prioridades). Con el mismo tiempo y con la misma financiación, hubiera sido lo óptimo crear algo nuevo desde cero, en lugar de seguir sumando y sumando parches horrendos.

Cuando una idea ya está gastada y hay que estirarla como un elástico... lo mejor es construir algo que dé el largo y que no se deba "estirar" (o que se pueda "volver a estirar" a futuro), con el el consecuente riesgo de que en determinado punto ya no dé más y termine cortándose.

Saludos :)

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/


Arriba
 Perfil  
 
NotaPublicado: 03 Ago 2012 22:33 
Desconectado
Betatester
Betatester
Avatar de Usuario

Registrado: 24 Dic 2010 14:37
Mensajes: 889
Eliuk Blau escribió:
Johan Paz escribió:
¿¿De qué ineficiencia de I7 estamos hablando exactamente?? Flipáis un poco, la verdad.


Viniendo de alguien que defiende a I7 a pies juntillos, aún reconociendo sus falencias...

En cualquier caso, estamos hablando de una ineficiencia reconocida por Andrew Plotkin (el creador de Glulx y Glk) y por el propio Graham Nelson. (Que en este caso, ya debería apartar tus dudas.)


I7 no es perfecto, y tiene muchos problemas. Pero lo que he dicho es completamente cierto y no cuesta nada hacer la prueba para hacer la comparativa. Las pruebas prácticas siempre son mejor que la teoría.

No digo que I7 no pueda tener problemas en la inicialización de alguna cosa muy muy grande, pero no es cierto que eso le pase en ROTA, basta con descargarlo y probarlo.

Por curiosidad me he descargado otras obras 'grandes' de I7 a ver...

  • Blue Lacuna: 5 Megas gblorb -sin gráficos ni sonidos ni nada, nada menos. Clicko en el fichero y el glulxe me da el prompt de manera inmediata.
  • Alabaster: 3 megas con gráficos. Clicko en el fichero y de nuevo prompt inmediato (las respuestas durante el juego no tanto, pero eso no es un problema de inicialización).

No digo que no existan problemas de inicialización, pero dichos problemas al menos en mis ordenadores no aparecen ni en ROTA, que es el que se estaba usando de ejemplo, ni en Blue Lacuna ni en Alabaster -que tiene problemas de rendimiento en otros aspectos.

No sé si el problema se presenta en ordenadores muchos más antiguos o en plataformas mucho más pequeñas como un smartphone, pero yo no los he visto de momento.


Arriba
 Perfil  
 
NotaPublicado: 05 Ago 2012 21:59 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1855
Entiendo perfectamente que se trató de evitar la optimización prematura y que muchas veces, como bien apuntáis, el hack es la solución más factible, dado tanto el contexto técnico como el personal.

En cuanto al tiempo de arranque... No se trata tanto de tiempo como de ciclos de la máquina. Johan mismo menciona otro tipo de implementaciones de la máquina y equipos menos potentes (imaginemos la que existe en JS, o un móvil) en las que la relación tiempo/ciclo es mucho más acusada, y ahí es donde se podría notar la ineficiencia del código generado.

He mirado el fuente enlazado y los "when play begins", aparte de un par de escritura, son:

Spoiler: Mostrar
Código:
When play begins:
   repeat with the patient running through people begin;
      change the permanent strength of the patient to the strength of the patient;
   end repeat.[* Especificar la fuerza permanente y la fuerza (actual), ambas, para todo el mundo en el juego puede ser tedioso. Para simplificar el asunto asumimos que todo el mundo comienza el juego con una salud fuerte, y a partir de ahí podemos deducir la fuerza permanente de la fuerza (actual).]

When play begins:
   calculate how many labyrinth rooms should have each shape;
   give shape to the shapeless labyrinth rooms;
   restore the labyrinth to its virgin state

When play begins:
   let the pack size be the number of out-of-the-pack things;
   let the total shuffled be 0;
   while the total shuffled is less than the pack size
   begin;
      let the next card be a random out-of-the-pack thing;
      move the next card to the encounters pack;
      let the total shuffled be the total shuffled plus 1;
   end while.


No he profundizado en las subrutinas que se llaman desde ahí, pero está claro que son bucles que afectan a muchos o todos los elementos del mundo. Si entiendo bien, al menos el primer caso es del tipo "Derived information".

Me llama la atención el uso del random en el último bloque (¿un mazo de cartas?). Si eso se hace en tiempo de empaquetado/ejecución/empaquetado, supongo que el jugador se encontrará siempre con el mismo mazo, algo que puede sorprender al autor y podría considerarse una regresión.


Arriba
 Perfil  
 
NotaPublicado: 07 Ago 2012 23:30 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2021
Ubicación: Chile
dddddd escribió:
Me llama la atención el uso del random en el último bloque (¿un mazo de cartas?). Si eso se hace en tiempo de empaquetado/ejecución/empaquetado, supongo que el jugador se encontrará siempre con el mismo mazo, algo que puede sorprender al autor y podría considerarse una regresión.


Genial! :lol: Me encanta :mrgreen: Repórtaselo a Plotkin a ver si se lo piensa de nuevo... 8)

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 11 mensajes ] 

Todos los horarios son UTC + 1 hora


¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado


No puede abrir nuevos temas en este Foro
No puede responder a temas en este Foro
No puede editar sus mensajes en este Foro
No puede borrar sus mensajes en este Foro

Buscar:
Saltar a:  
cron
Desarrollado por phpBB® Forum Software © phpBB Group
Traducción al español por Huan Manwë para phpBB-Es.COM