Hace tiempo, mucho tiempo... implemente los CALL, GOTO, etc... intente buscar un ejemplo, pero no encontre... asi que aca pongo uno
import "mod_say";
global
int a, i;
begin
a = 1;
say(a);
for (i = 0; i < 10; i++)
call inc_a;
say(a);
end
return;
inc_a:
a = a + 1 ;
return;
end
Beneficios de esto? son mucho mas rapidas que las funciones normales, consumen menos memoria, comparten las variables del proceso (en algunos casos puede ser ventaja y en otros desventajas)... y quizas otras mas que no se me ocurren...
Entiendo que sin el primer return ejecutaría la línea de inc_a: por ser una especie de label ¿cierto?
Anda, pues eso viene mejor que lo que hice con el motor de scroll tileado: coger el trozo de código que se repite, escribirlo en un fichero aparte, y poner una línea "include" donde debería ir esa "función" :D
¿Por casualidad recuerdas más o menos la versión en la que se implementó?
Por cierto, en Fenix se implementaron las "corutinas" (o las "rutinas", no recuerdo el nombre exacto, y seguro que lo ando confundiendo con alguno de C#). Se escribían como las funciones, pero si el compilador detectaba que no se usaban variables locales (y creo que globales), se almacenaba como corrutina, que es una función con menos carga a la hora de generarse en memoria y de ejecución más rápida. No sé si eso se trasladó a BennuGD.
Quote from: warrior_rockk on March 14, 2016, 11:42:35 AM
Entiendo que sin el primer return ejecutaría la línea de inc_a: por ser una especie de label ¿cierto?
cierto
Quote from: Drumpi on March 14, 2016, 04:40:57 PM
Anda, pues eso viene mejor que lo que hice con el motor de scroll tileado: coger el trozo de código que se repite, escribirlo en un fichero aparte, y poner una línea "include" donde debería ir esa "función" :D
¿Por casualidad recuerdas más o menos la versión en la que se implementó?
Por cierto, en Fenix se implementaron las "corutinas" (o las "rutinas", no recuerdo el nombre exacto, y seguro que lo ando confundiendo con alguno de C#). Se escribían como las funciones, pero si el compilador detectaba que no se usaban variables locales (y creo que globales), se almacenaba como corrutina, que es una función con menos carga a la hora de generarse en memoria y de ejecución más rápida. No sé si eso se trasladó a BennuGD.
hace mucho se implemento.
las "corutinas" que dices, son procesos que se comportan como funcion... sigue igual, pero sigue siendo pesado...
se pueden parametrizar?
Me temo que al ser un salto a etiqueta con retorno, no puedes parametrizarlo. Puedes crearte variables globales como parametros e iniciarlos con valores antes de llamar a la rutina...
no es necesario crear variables globales, siendo parte del mismo proceso que las llama, estas "rutinas" tienen acceso a las mismas variables del proceso "llamador", asi que directamente lees/tocas las variables que le ibas a pasar por parametro.
mmm, entiendo, buena idea. Voy a ver si puedo implementarlo en el motor de durezas para ver si mejora el rendimiento.
Splinter, vos que conoces bien Bennu, vos crees que eliminando un par de llamadas a funciones usando CALL en cada frame, deberia haber una mejora en el rendimiento ?
Quote from: JaViS on March 29, 2016, 01:55:29 PM
mmm, entiendo, buena idea. Voy a ver si puedo implementarlo en el motor de durezas para ver si mejora el rendimiento.
Splinter, vos que conoces bien Bennu, vos crees que eliminando un par de llamadas a funciones usando CALL en cada frame, deberia haber una mejora en el rendimiento ?
deberia... a menos que el cuello de botella este en el render... (puede pasar...)
Quote from: SplinterGU on March 29, 2016, 12:27:44 PM
no es necesario crear variables globales, siendo parte del mismo proceso que las llama, estas "rutinas" tienen acceso a las mismas variables del proceso "llamador", asi que directamente lees/tocas las variables que le ibas a pasar por parametro.
Pero, entiendo que, la utilidad de esto es llamar a esas rutinas desde otros procesos. En ese caso, ¿se comporta como una extensión de código del proceso que las llama? Con lo que, ¿puedes acceder a las variables del proceso que realiza el salto?
no, son dentro del mismo proceso.
mmm quizás no lo entendí bien.. Si sólo lo puedes usar dentro del mismo proceso, entonces no se comporta como una alternativa a usar funciones ya que, simplemente es código añadido a un proceso. ¿que utilidad tiene entonces?
que la puedes llamar desde muchas partes del mismo proceso, al igual que una funcion... si lo ves asi, una funcion tambien es codigo añadido a un fuente... lo unico que varia es el scope (y los parametros, claro esta)...
Es como si cogieras e hicieras un copy/paste de un trozo del proceso que se va a repetir. Según las normas de estilo, eso está mal, porque para eso se crearon las funciones, pero como crear una función tiene un coste de computación (reservar espacio, crear variables, copiar datos, destruir la función...) se supone que esto es más rápido.
A mi, en mi caso particular, no he obtenido una mejora visible (aunque tampoco he podido hacer una medición objetiva), y quizás sea más conveniente probar lo que me recomendaba Splinter de usar #define... u otra aproximación diferente al algoritmo.
yo note que el render le da una frenada impresionante al motor, tanto en version por soft como en opengl, quizas en algunos casos la bajada de rendimiento no esta en la logica sino en el render, o en la cantidad de cosas que renderea... creo que comente el caso donde con render opengl tengo un rendimiento de 1000fps y con la misma logica (con los mismos procesos, haciendo lo mismo constantemente) pero sin renderearlo a video (con graph=0 o incluso con un hardcode de no dumpear el grafico a video), el rendimiento se iba a 120 mil o 160 mil fps (algo asi)... ahi es terrible el delay que mete el render.
edit: y en esos casos se apreciaba rendimiento en el cambio de la logica, pero cuando activaba el video ya no habia mejoras de rendimiento.
A mi me ha pasado que en la prueba del scroll tileado, el cubrir parte de la ventana con otra aumentaba la velocidad, llegando a quintuplicarla.
Pero supongo que es normal.
Además, hace tiempo me leí el método de render y, sí, vale para todo y es muy reutilizable, pero se ejecutaba una vez por cada elemento dibujable en pantalla. Yo no creo que sepa hacerlo mejor, desde luego, pero quizás sí que habría que darle una vuelta para ver si se podría hacer de otra forma, no sé, ¿recolocar y ordenar los elementos y, después, pintarlos de una en el sdl_surface?
Pero vamos, Splinter, que si estás usando SDL con las distintas superficies, y dejando que sea SDL quien haga el render, seguramente se note una mejora notable (vamos, digo yo).