CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 15 Nov 2019 22:57

Todos los horarios son UTC + 1 hora




Nuevo tema Responder al tema  [ 44 mensajes ]  Ir a página 1, 2, 3  Siguiente
Autor Mensaje
NotaPublicado: 14 Feb 2009 20:03 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
Hola. Quiero comentar una noticia que he leído en el RAIF que está provocando que me salgan ronchas... :?

A Andrew Plotkin se le ha ocurrido que para acelerar el actual LENTÍSIMO funcionamiento de las nuevas aventuras Glulx generadas por I7 se implemente un nuevo sistema de ACELERAMIENTO DE RUTINAS.

Concretamente, lo que propone (y todo indica que ya es casi un cambio oficial) es que las rutinas de la librería Inform que sean muy ocupadas y que esté demostrado que funcionen lento (o las que el resto de programadores luego queramos acelerar) sea declaradas de una forma especial mediante un par de opcodes.

De esta forma, cada una de estas rutinas "lentas" será REEMPLAZADA POR EL INTÉRPRETE con una versión optimizada por el propio intérprete. Es decir, por ejemplo, si la rutina X de la librería I7 es lenta, entonces el intérprete Glulx podrá implementarla por sí mismo en una versión más rápida.

Toda la info aquí:
http://groups.google.cl/group/rec.arts.int-fiction/browse_thread/thread/14821d50f86c5b2e

Esto, sinceramente, me parece una abominación. Sobre todo porque la ventaja de Inform sobre, por ejemplo TADS, era que la librería estaba completamente creada en lenguaje Inform. En cambio, TADS incorporaba parte del parser en el código del intérprete. Y era poco personalible. Ahora Andrew propone que Glulx vaya por el mismo camino...

Los intérpretres viejos seguran usando las rutina codificadas en Inform, y los nuevos podrán reemplazar estas rutinas con sus propias versiones optimizadas.

¿Y qué pasará cuando salga una nueva versión de la Lib que tenga una de esas rutinas esenciales cambiada o más nueva? El intérprete implementará una versión vieja de esa rutina?

Joder... que todo este asunto me parece que está yendo muy muy muuuuuuuy mal encaminado. El intérprete ya no sería puro... sino que sería como un híbrido... no sé. No me agrada.

¿Qué opinan ustedes?

A mí me parece que es mala solución para el problema de la lentitud en Glulx... Me da la sensación que es como una salida desesperada, una solución forzada...

Saludos!
Eliuk.

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


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 14 Feb 2009 21:28 
Desconectado
Implementador
Implementador
Avatar de Usuario

Registrado: 07 Sep 2004 21:52
Mensajes: 1897
Hombre, a mi me suena a que el compilador detectará esas rutinas usuales y lentorras y las sustituirá por código máquina Glulx para mayor rapides. A mi no me parece ninguna abominación, sobre todo porque el usuario final no se verá afectado. Vamos, que tu no tienes porqué programar esos opcodes a mano.

Al menos eso he entendido...

_________________
Ruber "Urbatain" Eaglenest.
------------------------
http://www.indieorama.com/author/rubereaglenest/


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 14 Feb 2009 22:44 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 15 Dic 2004 21:28
Mensajes: 2302
Yo estoy de acuerdo con Eliuk, me parece una mala decisión de diseño lo de incluir código dependiente de Inform dentro de los intérpretes (en plural porque se supone que cada intérprete lo deberá implementar), esto a primera vista tiene una gran desventaja de dependencia: si se actualiza Inform tendrán que actualizarse los intérpretes (a menos que no cambien las porciones de código optimizado). Incluso puede que algunas aventuras compiladas con cierta versión de Inform no sean compatibles con ciertos intérpretes (cosa que ya se estaba empezando a dar antes de esto, ahora se agravará mucho más). También se va a crear una barrera aún mayor (de la que ya había) para la creación de nuevos intérpretes ya que esta tarea será más compleja y habrá que coordinarse con Inform*. Además Inform no es el único compilador que genera código glulx, ¿por qué se le tiene que dar un trato de favor a Inform frente a otros? (bueno, ahí ya entraríamos en cuestiones políticas).

En el fondo esto, tal y como yo lo veo, solo es una medida de "echar balones fuera" de un problema de Inform 7 que dada su complejidad tiene problemas de optimización en el código generado, lo mejor sería atacar ese problema en Inform y no echarle el muerto a los intérpretes.

Otra cosa que me ha llamado la atención leyendo el hilo en RAIF es que los anglos en general se cuestionan poco todo lo que venga de las "figuras relevantes" (por llamarles de algún modo), poco espíritu crítico les veo.

* Obviamente esto sería en parte "opcional" en el sentido de que pueden haber intérpretes que no lo implementen, aunque con la penalización de la velocidad.


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 15 Feb 2009 00:07 
Desconectado
Implementador
Implementador
Avatar de Usuario

Registrado: 10 Mar 2004 21:40
Mensajes: 1444
Ubicación: Nímgar, Ciudad Lunar
Deberían reescribir el I7 en forma de un I8 confilosofía cercana, pero sin lenguaje natural y un tamaño mucho más reducido.

Eso seria optimizable.

Por otra parte Eliuk te pasa por hacerles caso....

:P

_________________
Mel Hython
------------------
http://mel-hython.blogspot.com/


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 15 Feb 2009 01:31 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5308
Ubicación: Coruña
Mel Hython escribió:
Deberían reescribir el I7 en forma de un I8 confilosofía cercana, pero sin lenguaje natural y un tamaño mucho más reducido.

Eso seria optimizable.


Realmente me extraña que no haya formas de optimizar el código generado por I7 con técnicas de análisis estático. En general, es muy normal que el código generado automáticamente sea ineficiente de base (porque suele ser mucho más fácil generarlo así); pero hay técnicas para optimizarlo después. Es lo que se suele hacer en la mayoría de los compiladores.

Otra cosa es que los desarrolladores de I7 no tengan tiempo para ponerse a hacer estas cosas, claro. Eso sería totalmente comprensible.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 15 Feb 2009 13:46 
Desconectado
Implementador
Implementador
Avatar de Usuario

Registrado: 10 Mar 2004 21:40
Mensajes: 1444
Ubicación: Nímgar, Ciudad Lunar
¿Los? El problema tiene nombre de Almirante. Que yo sepa lo ha llevado demasiado tiempo como proyecto secreto personal.

_________________
Mel Hython
------------------
http://mel-hython.blogspot.com/


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 18 Feb 2009 23:31 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 24 Ago 2007 00:41
Mensajes: 2023
Ubicación: Chile
Yo, sinceramente, no creo que el problema principal de I7 sea tanto la "optimización del código". Es cierto que NI hace un trabajo un poco "bruto" a la hora de transforman codigo en lenguaje natural a I6 (cosas como redundancias y parecidos, pero nada muy grave, la verdad).

Siento que el problema no es tanto que el codigo sea "optimizable", sino que la propia complejidad de I7 a llegado a grados tales que los VIEJOS INTERPRETES (seamos realistas, tenemos Glulxe y Git para Glulx y Frotz para Z) cuando fueron programados no estaban preparados para manejar tan complejas estructuras de código. Casi todos los intérpretes de Glulx actuales (más usados y probados) son "hijos" de Glulxe o Git (a su vez, todos los de Z casi sin excepción descienden de Frotz), cuando se programaron aquellos intérpretes se consideraron los esquemas actuales que tenían las aventuras Glulx para ese entonces. I7 es increíblemente mucho más complejo y el codigo, evidentemente, mucho más pesado de ejecutar (se hacen muchas más cosas, de fondo, por ejemplo, en un turno de juego).

Es posible que los intérpretes hayan sido programados teniendo en cuenta sólo los esquemas actuales a la fecha de su creación (quizá no optimizando cosas que podrían haberse hecho mejor). O es posible también que la especificación de Glulx, por ejemplo, no esté del todo preparada (a la hora de materalizarla en un Interprete) para calculos tan exhaustivos como los que tienen las aventuras de I7 (aunque debo hacer constar, como no, que las aventuras Z adolecen de los mismos problemas de lentitud...)

Saludos!

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


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 19 Feb 2009 00:38 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 15 Dic 2004 21:28
Mensajes: 2302
Pues en esto último no estoy de acuerdo contigo, Eliuk, los intérpretes Z o Glulx realmente no son intérpretes en sentido clásico (como por ejemplo un intérprete BASIC), son más parecidos a máquinas virtuales que ejecutan directamente bytecode. Quizá se podrían optimizar más, pero yo creo que la parte que tiene más peso en el rendimiento es la del código generado, es decir si se optimizara el compilador (o el preprocesador de inform 7) se obtendría mucha más ganacia que intentando optimizar los intérpretes que en el fondo son más sencillos que el compilador, pues ya les llega el bytecode que ya debería estar optimizado. Es como si un compilador de una máquina real generara código defectuoso y fuera el procesador de la máquina el que tuviera que optimizarlo en tiempo de ejecución, no tiene mucho sentido, mejor hacerlo bien desde la base, ¿no?

Además la complejidad de Inform 7 ¿es realmente necesaria? o mejor dicho, ¿es evitable?, al fin y al cabo todo lo que se puede hacer en Inform 7 se puede hacer en Inform 6, y sabemos que una misma aventura hecha en Inform 6 no tendrá los problemas de rendimiento que tiene en Inform 7. Conclusión: el problema de rendimiento está en Inform 7.


Arriba
 Perfil  
 
 Asunto: I7
NotaPublicado: 19 Feb 2009 10:31 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 23 Abr 2004 08:49
Mensajes: 2918
Ubicación: España (Galicia)
Hola !

Creo que ambos tenéis razón. Presi acierta parcialmente cuando dice que el problema no son los intérpretes (o al menos no en su supuesta antigüedad). Eliuk acierta cuando dice que por ejemplo, se hacen muchas más cosas de fondo en cada turno en I7 que en cada turno de I6. Claro es que en I6, por defecto, no se hace casi nada.

Todo ésto viene derivado de que I7 automatiza muchas cosas, y provee de muchos comportamientos comunes en muchas aventuras, que tú puedes usar ... o no. Pero lo uses o no, eso ocupa espacio.

Soluciones:

Por la parte de Presi:

- Analizar el código generado o el código a traducir, ver qué componentes se usan, modularizar la librería e incluir sólo aquellos componentes que se usan.

- Aún así, es posible que una aventura utilice todos los componentes: es necesario optimizar los módulos de manera que hagan lo que hacen en el mínimo de tiempo y recursos.

Por la parte de Eliuk:

- Cuando se crearon los intérpretes para máquina Z, no se sabía hacer más que reducir el código a bytecode, e interpretar ese bytecode. Este es el mismo sistema que utilizaba SmallTalk, por ejemplo, y es lo que hizo que no triunfara ni remotamente como lenguaje de programación para cosas "serias". Tiempo después, apareció Java, y Java sí triunfó. Con muchas salvedades, es rápido; es capaz de hacer algo que máquinas como la Z no hacen: compilar el código a medida que lo ejecutan (JIT'er, le llaman, de Just in time). De esta manera, la segunda vez que una función es ejecutada, va tan rápido como iría en C++. Sólo hay que darle tiempo a Java para que compile las funciones más importantes (hotspots, las llaman). La solución, por tanto, es hacer lo mismo en Z y Glulx. Quizás al principio de una aventura vayan un poco lentas, pero después irán a gran velocidad.

Conclusión:

Nadie se va a poner a programar un Jitter para la máquina Z o Glulx. Probablemente, los creadores de I7 (si es que realmente hay más de uno), no tienen tiempo para optimizar la librería ni crear un analizador que identifica sólo aquello que se usa.

De lo que sí están seguro los desarrolladores son de ciertas funciones que se llevan el x% del tiempo entre cada turno. La solución de JIT'er "cutre" es: impleméntalas directamente en tu intérprete, y nosotros las llamamos en lugar del código de la librería.

Así, nadie tiene que pegarse el curro del Jitter (el cual, por cierto, tiene que ser distinto según se compile para procesadores Intel [PC's], PPC [Macs' "antiguos"], Sparc [máquina Sun antiguas], o ARM [PDA's y móviles]).

Y el código irá igual de rápido.

Eso sí, cambia la librería y ... la fastidiaste. Una forma de "solucionar" ésto es hacer un buen sistema de versionado, de manera que si la MV detecta que la librería es otra que la que él está "optimizado" para ejecutar, no optimice nada. O, al menos, que se puedan desactivar estas formas de optimización.

En cualquier caso, cualquier cambio de la librería tendrá que llevar pareja la actualización de los intérpretes.

EDITADO: Un intérprete hecho en JAVA como JAG, podría solucionar estos problemas indirectamente, ya que el intérprete en sí irá rápido.

Salud !

Baltasar

_________________
-- Baltasar, el arquero


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 19 Feb 2009 11:33 
Desconectado
Implementador
Implementador
Avatar de Usuario

Registrado: 18 Mar 2004 19:26
Mensajes: 1458
Ubicación: Barcelona
Pues vaya lío de siglas. A mi me gusta la forma sencilla de poner imágenes en Superglús.

_________________
http://xaviercarrascosa.com/ficcion-interactiva/


Arriba
 Perfil  
 
 Asunto: Superglús
NotaPublicado: 19 Feb 2009 11:44 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 23 Abr 2004 08:49
Mensajes: 2918
Ubicación: España (Galicia)
Hola !

grendelkhan escribió:
Pues vaya lío de siglas. A mi me gusta la forma sencilla de poner imágenes en Superglús.


Superglús es mucho más sencillo, es cierto, pero recuerda que también esa sencillez le hace más "sordo" que a cualquier aventura de I6/I7. Hay que trabajarse mucho la librería como para alcanzar algo similar.

Y ese grado de entendimiento, de jugabilidad, es a lo que estamos acostumbrados. Lo que caiga por debajo nos parece "mal", léanse los "problemas" con Quest o Adrift.

Yo lo sé de primera mano porque programé "Náufrago" en Superglús. Incluso siendo una aventura pequeña, el betatesteo fue horroroso.

http://caad.es/baltasarq/naufragodicen.htm

¡Fíjate en los comentarios!

Salud !

Baltasar

_________________
-- Baltasar, el arquero


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 19 Feb 2009 11:57 
Desconectado
Implementador
Implementador
Avatar de Usuario

Registrado: 10 Mar 2004 21:40
Mensajes: 1444
Ubicación: Nímgar, Ciudad Lunar
Se notaba el esfuerzo en evitar la sordera, pero aún así a veces parecía un tanto sordo.

Pero yo creo que el mayor error fue plantearlo como con lenguaje natural. Esto no ha mejorado la experiencia de los no programadores, lo transforma en demasiado verboso y la cantidad de sintaxis a recordar se dispara.

Este último factor debe hacer el compilador una suerte de horror de complejidad y bastante debe tener Nelson con hacer que funcione como para preocuparse en la optimización.

Por otra parte se carga con demasiadas cosas algunas muy útiles y otras no tanto (¿escenas? ¿realmente eso es taaan útil como para que venga de fábrica? ¿unidades métricas?). Deberían construir un I8 desde cero, basado en reglas y con algunos de los avances de I7 (como el tratamiento de acciones para PNJs y almacenadas, las facilidades con el mapeado...) pero sin sintaxis en lenguaje natural y sacar todo lo accesorio a librerías.

Y sobre esa base que funcione, ya plantearse un IDE (que no un lenguaje) que use el lenguaje natural como base.

Creo que I7 peca demasiado de la idea romántica de que el propio listado de la aventura sea una obra literaria en sí mismo, lo que no tiene ninguna utilidad, aunque sea 'mono'.

_________________
Mel Hython
------------------
http://mel-hython.blogspot.com/


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 19 Feb 2009 13:00 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 15 Dic 2004 21:28
Mensajes: 2302
Mel Hython escribió:
pero sin sintaxis en lenguaje natural


Pero ¿qué dices?, si precisamente ese es su mayor reclamo. ;)

Mel Hython escribió:
Creo que I7 peca demasiado de la idea romántica de que el propio listado de la aventura sea una obra literaria en sí mismo, lo que no tiene ninguna utilidad, aunque sea 'mono'.


En cualquier caso, estoy de acuerdo.


Arriba
 Perfil  
 
 Asunto: Re: I7
NotaPublicado: 19 Feb 2009 17:38 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 15 Dic 2004 21:28
Mensajes: 2302
baltasarq escribió:
Eliuk acierta cuando dice que por ejemplo, se hacen muchas más cosas de fondo en cada turno en I7 que en cada turno de I6. Claro es que en I6, por defecto, no se hace casi nada.

Todo ésto viene derivado de que I7 automatiza muchas cosas, y provee de muchos comportamientos comunes en muchas aventuras, que tú puedes usar ... o no. Pero lo uses o no, eso ocupa espacio.

De acuerdo, pero la cuestión es: ¿de verdad Inform 7 hace tantas cosas por turno como para justificar la pérdida de rendimiento? En algunas aventuras se han observado tiempos de espera de alrededor de un segundo en máquinas actuales, lo que en mi opinión es mucho.

Imaginemos que se implementan en Inform 6 a mano todas esas cosas extras por turno que hace Inform 7, ¿se ejecutaría más rápido una misma aventura en Inform 6? Si la respuesta es "sí" entonces Inform 7 tiene un problema de rendimiento independientemente de intérpretes u otras consideraciones.

baltasarq escribió:
EDITADO: Un intérprete hecho en JAVA como JAG, podría solucionar estos problemas indirectamente, ya que el intérprete en sí irá rápido.

Yo no estoy tan seguro, el hecho de que tengas JIT en JAVA solo hará rápida la capa de JAVA, es decir la acercará en rendimiento a código nativo, pero por encima de ella sigues teniendo el intérprete que no hace JIT sobre código Glulx o Z.



P.D.: Solo un pequeño apunte sobre arquitecturas no x86:
baltasarq escribió:
PPC [Macs' "antiguos"], Sparc [máquina Sun antiguas]

PowerPC no solo viene en Macs antiguos, todas las consolas de videojuegos actuales no portátiles están basadas en esta arquitectura.
Y SPARC se sigue vendiendo en servidores Sun de gama alta.


Arriba
 Perfil  
 
 Asunto: Re: I7
NotaPublicado: 23 Feb 2009 17:42 
Desconectado
Archivero
Archivero

Registrado: 19 Nov 2008 12:32
Mensajes: 268
hola!
presi escribió:
En algunas aventuras se han observado tiempos de espera de alrededor de un segundo en máquinas actuales, lo que en mi opinión es mucho.


que yo recuerde, I7 demora más ciclos cuando se mete con las expresiones regulares, o en extensiones que capturan la entrada (o la salida), o cuando tiene que calcular paths extensos (entre localidades o entre nodos-de-lo-que-sea). No parece ser el tipo comun de cosas que haria una aventurilla, pero sin duda merecen revisarse esos algoritmos.

Por otro lado -y esto ya es sapo de otro pozo- pienso que una demora en los tiempos de espera (demora aleatoria, si es posible) hacen más 'natural' al juego.

Croac!

_________________
I7 Spanish / Notas de desarrollo


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 44 mensajes ]  Ir a página 1, 2, 3  Siguiente

Todos los horarios son UTC + 1 hora


¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 5 invitados


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