Pregunta sobre rendimiento: Process o Function?

alicesimu · November 06, 2016, 05:37:01 PM

hola

esto es una pregunta que me hago cuando:

debo programar una operacion:


FUNCTION GAMEPAD();
PRIVATE
	V_UP,V_DOWN,V_RIGHT,V_LEFT;
BEGIN

		BOT_EMPUJ=KEY(_ENTER);if(not BOT_EMPUJ);BOT_EMPUJ=KEY(_SPACE);end
		V_UP=KEY(_UP);if(not V_UP);V_UP=KEY(_w);end
		V_DOWN=KEY(_DOWN);if(not V_DOWN);V_DOWN=KEY(_s);end
		V_RIGHT=KEY(_RIGHT);if(not V_RIGHT);V_RIGHT=KEY(_d);end
		V_LEFT=KEY(_LEFT);if(not V_LEFT);V_LEFT=KEY(_a);end

		iF(V_UP XOR V_DOWN XOR V_RIGHT XOR V_LEFT);
			iF(V_UP);DIRECION_JUGADOR=1;end
			if(V_DOWN);DIRECION_JUGADOR=4;END
			iF(V_RIGHT);DIRECION_JUGADOR=2;end
			if(V_LEFT);DIRECION_JUGADOR=8;END
		ELSE
			DIRECION_JUGADOR=0;
		END
	
END

Es una funcion que solo maneja el tema de entrada de controles, para el jugador. por el teclado.
lo tengo como funcion para organizarme el programa y no mezclarlo con el proceso jugador(siempre activo)
el proceso jugador, llama a GAMEPAD() en el momento indicado. solo lo consulta 1 vez por frame;

Mi pregunta es por rendimiento, es decir cual me saca mas FPS de velocidad y menos carga de CPU.

Function o como processo??
que es mas rapido, para este tipo de codigo que NO hay ningun FRAME; solo procesa/opera.

Es tan sencillo como cambiar el tipo de elemento de GAMEPAD();
FUNCTION vs PROCESS

DCelso · November 06, 2016, 05:51:21 PM

function, claro.
Aunque a penas habrá diferencia.

La diferencia básica entre function y process es que uno es síncrono y el otro no. Punto.

alicesimu · November 06, 2016, 06:06:41 PM

Quote from: DCelso on November 06, 2016, 05:51:21 PM
function, claro.
Aunque a penas habrá diferencia.

La diferencia básica entre function y process es que uno es síncrono y el otro no. Punto.

no es la respuesta que busco. lo siento.
Conozco los pros y contras entre los dos... pero a nivel de lenguaje BennuGU.

esto me lo sabria responder SplinterGU, ya que sabe el comportamiento tecnico real que se supone el motor de BennuGU.

Estoy segura que si hago un test, con SET_FPS(0,0), y hago la diferencia entre los 2... los numeros fps seran diferentes.
El que mas numero fps, me saque sera el que menos carga de cpu tiene sobre ella.

Voto que un proceso siempre es mas rapido(menos carga de CPU), que una funcion, aun que haga la misma tarea como ejemplo que puse.

DCelso · November 06, 2016, 09:50:30 PM

;D
mi voto va para que tardan exactamente igual.

alicesimu · November 07, 2016, 11:06:36 AM

Esperemos... ;)

bueno deberia hacerme ese test, y quitarme las dudas!
a ver cuando me pongo a probar tests! :P

Drumpi · November 07, 2016, 01:07:35 PM

Venga, rebusquemos en mis archivos cerebrales.
FUNCTION y PROCESS se diferencian funcionalmente en dos cosas: en que function congela al padre y que permite devolver datos de diversos tipos.
En DIV las Functions eran muy rápidas porque no tenían variables locales y se ejecutaban en un frame, no admitían FRAME.
Fenix dio la posibilidad de añadir frame a las funciones. Ahí nació lo de congelar al padre.
Si mi memoria no me falla, Slainté implementó function de dos formas diferentes: si no se detectaba "frame" ni acceso a variables locales, las funciones eran eso, funciones que se ejecutan y mueren al instante, sin variables locales ni nada. Pero si detectaba frame se convertían en procesos, con la diferencia de que congelaban al padre.

A partir de ahí le perdí la pista, porque creo que incluso se llegó a hablar de procesos con return, subrutinas (creo que eran procesos que no usaban ciertas características) y alguna cosilla más, pero había poca o nula documentación del tema y nunca llegué a leer el código fuente.

A día de hoy te diría que no hay diferencias entre FUNCTION y PROCESS, a menos que tengas suerte y averigües qué es lo que convertía a las funciones en eso, las funciones más rápidas.
Eso sí, las funciones son geniales cuando quieres lanzar una ventana y esperar a que se cierre antes de seguir con el código, pero son sustituibles por un signal(id,s_sleep) + signal(father,s_wakeup) mientras haya un frame de por medio.

panreyes · November 07, 2016, 01:36:43 PM

Desconocía que existieran esas optimizaciones :|
Las estoy leyendo en el archivo "core\pxtb\src\c_code.c"

No hace falta que la función tenga frame para poder acceder a las locales, son dos cosas diferentes.

Tengo que hacer pruebas... Ya aviso :)
-------------

Ya he hecho las pruebas, y me salen unos datos impresionantes que no acabo de comprender :|

------------

Vale, ya lo he entendido. No hay diferencias notables entre utilizar una función con locales o sin locales, o con frame o sin frame.
El ejemplo que había puesto que pensaba que sí que suponía una gran diferencia estaba mal hecho, ya que hacía frames ejecutando menos código.

alicesimu · November 07, 2016, 01:42:40 PM

Oleeee! Eso quería leer
Gracias chicos!!

Es que me lo explicaron por el otro barrio g... Que pasa lo mismo, que el echo de tener que "frenar" a todos los procesos... Le supone una carga al motor, tenga o no frame.

Por eso me supuso una duda en bennugd.

Se supone que la función es más rápida, pero no lo es en realidad, así que usar únicamente procesos aun que no tenga frame.

panreyes · November 07, 2016, 01:48:06 PM

Lo siento alicesimu, el código estaba mal hecho xD
No hay apenas diferencias realmente.

Drumpi · November 07, 2016, 01:51:34 PM

Pixel ¿puedes corregir el texto de los resultados? no me queda claro en dónde has usado process :D

Y no, no digo que haya que usar "frame" para usar locales. Digo que si se utiliza "frame" o variables locales, la función se transforma en realidad en un proceso :D (o cualquier otra cosa que se podía usar en procesos pero no en funciones).

Si los resultados son ciertos, voy a tener que revisar algunas cosas de mi editor de scroll tileado... aunque el uso de funciones con frame está limitado a las ventanas, en cuyo momento no se necesita potencia porque el resto de procesos quedan en "stand by" :P

SplinterGU · November 07, 2016, 07:28:35 PM

iba a pasar de responder porque estoy apurado, pero lei SplinterGU y voy a responder...

el rendimiento es relativo, entre un proceso y una funcion que llamas en cada frame, en teoria deberia tardar mas, ya que se crea un proceso que se usa como funcion y se destruye tras el llamado, o sea, a lo que consumiria habitualmente siendo un proceso hay que agregarle creacion/destruccion, pero bien es cierto que es muy poco... y si fuera un proceso tambien hay logica para incluirlo en ciertas listas, como ser colisiones, ordenamiento de Z, y otras cosas... asi que quizas lo que se gana por un lado se pierde por otro... y quizas se compensa...
si queres ganar rendimiento deberias usar labels con CALL/RETURN o GOTO... o usar #defines...

pero normalmente la CPU esta muy holgada en cuanto a procesamiento de la logica, y el problema de rendimiento se concentra en el render...

por eso es que PiXeL dice que no nota diferencia de rendimiento, porque el cuello de botella termina siendo el render (incluso en la version opengl)

Drumpi · November 07, 2016, 08:31:00 PM

Mi motor de scroll tileado, y cierto juego que no quieren que se nombre más en este foro, en WIZ, disienten de eso, maese Splinter.

...claro que también es verdad que usan más de 200 procesos simultáneos, y eso sobrepasa con creces el tiempo de render :D :D :D :P
[/joke]
Lo que me gustaría saber es qué está haciendo para que el tiempo de procesamiento entre procesos y funciones sea tan importante. Ya digo que he tenido que lanzar un proceso por tile para que me empiece a dar problemas en la Wiz, así que a menos que esté desarrollando para GP32... :P

SplinterGU · November 07, 2016, 11:51:03 PM

Quote from: Drumpi on November 07, 2016, 08:31:00 PM
Mi motor de scroll tileado, y cierto juego que no quieren que se nombre más en este foro, en WIZ, disienten de eso, maese Splinter.

...claro que también es verdad que usan más de 200 procesos simultáneos, y eso sobrepasa con creces el tiempo de render :D :D :D :P
[/joke]
Lo que me gustaría saber es qué está haciendo para que el tiempo de procesamiento entre procesos y funciones sea tan importante. Ya digo que he tenido que lanzar un proceso por tile para que me empiece a dar problemas en la Wiz, así que a menos que esté desarrollando para GP32... :P

estas hablando de WIZ, yo hablo de una PC...

como sea, edita los fuentes de bennugd, comenta las funciones de rendereado a video, proba el mismo programa y me contas... vas a ver la diferencia de velocidad...

alicesimu · November 08, 2016, 11:32:49 AM

Es evidente que operar con operaciones gráficas con mayor numero de procesos, y operaciones complejas... Tiene gran impacto de CPU desde luego, no hay que abusar en especial en dispositivos móviles. Un Pc aguanta mucho mas desde louego.

Usar collision( tiene mas impacto de rendimiento que el colisión_box por ejemplo

No abusar de los TYPEs para escanear un tipo de procesos cuando hay muchos en memoria.

Congelar y dormir procesos ayuda el rendimiento.

No abusar de datos Local, consumen memoria RAM por cada proceso en memoria.

Hay mas cosas...

SplinterGU · November 08, 2016, 03:23:58 PM

Quote from: alicesimu on November 08, 2016, 11:32:49 AM
Es evidente que operar con operaciones gráficas con mayor numero de procesos, y operaciones complejas... Tiene gran impacto de CPU desde luego, no hay que abusar en especial en dispositivos móviles. Un Pc aguanta mucho mas desde louego.

Usar collision( tiene mas impacto de rendimiento que el colisión_box por ejemplo

No abusar de los TYPEs para escanear un tipo de procesos cuando hay muchos en memoria.

Congelar y dormir procesos ayuda el rendimiento.

No abusar de datos Local, consumen memoria RAM por cada proceso en memoria.

Hay mas cosas...

en bennugd/PixTudio, las LOCAL o PUBLIC (definidas en un proceso) son locales al proceso, pero visibles a todos los procesos, para que sean a todos tienen que ser declaradas fuera de un proceso.