Ver la versión completa : Squidge testeando el uso de los dos procesadores (y rlyeh con su minimal lib)
Squidge se ha puesto manos a la obra para ver hasta qué punto se ganará rendimiento con la GP2X usando ambos procesadores. Para esto ha realizado un primer test calculando número primos usando raices cuadradas. Los resultados han sido los siguientes:
Ejecutando el test en el 920: completado en 17,2 segundos.
Ejecutando el test en el 940 con el 920 "twiddling it's thumbs" (a ver si alguien sabe exactamente a qué se refiere): completado en 17,1 segundos.
Ejecutando el test en ambos procesadores, dividiendo el trabajo entre los dos: completado en 8,9 segundos.
Es decir, ejecutando el test usando ambos procesadores ha tardado aproximadamente el 50% en realizar la misma función. :brindis:
Ahora va a realizar test de ancho de banda de lectura de memoria, usando uno, otro y ambos procesadores a la vez.
Más info: http://www.gp32x.com/board/index.php?showtopic=22871
Muy buena noticia, pronto empezaremos a ver emuladores bastante buenos ;)
¿ Demuestra esto que es factible el uso simultaneo de la memoria por parte de ambos procesadores al mismo tiempo ?
Lo digo por que si hubiesen de esperarse el uno al otro a la hora de leer/escribir en la memoria, seria imposible que juntos tardasen menos tiempo en hacer los calculos que por separado, ¿ no es cierto ? :saltando:
:saltando: :saltando: :saltando: ESTAMOS ANTE UN MAQUINON DE LA HOSTIA :saltando: :saltando: :saltando:
johnnypalmera
06/12/2005, 06:50
"twiddling it's thumbs" (a ver si alguien sabe exactamente a qué se refiere)
Si mi inglés no falla, significa "cruzando los dedos".
EDIT: Vale, creo que en castellano no hay que interpretarlo como "cruzar los dedos en sentido supersticioso" sino, "con los dedos cruzados porque no está haciendo nada".
Y más noticias buenas:
Rlyeh ha conseguido usar el segundo core bajo linux usando su minimal lib. :saltando: :saltando:
johnnypalmera
06/12/2005, 06:56
normal, esque este hombre es una máquina.. que ganas tengo de probar su HPL!!!
pordios , que alguien le mande las librerias al creador del emu de psx :babea: :babea: :babea: :babea:
Saludos, y chapo por esta consola, me esta sorprendiendo mas de lo que esperaba :D
LukStarkiller
06/12/2005, 07:33
Pues si con la memoria puede repartirse,(alomejor por eso solos e podian usar 32 en un principio, porque pensaban repartir la carga o algo) si es asi pues vaya maquinon a salido, esto, oye que pa mediados de enero no falten consolas he! XD
Electric Dreams
06/12/2005, 08:11
No quiero despreciar los valores que arrojan los tests de Squidge, sino más bien aplacar un poco la euforia. Este test en concreto presenta la situación más favorable para el sistema: uso minimo de la memoria principal por parte de las dos CPU y un reparto previo de la carga.
En una situación real podríamos encontrarnos con un cuello de botella en el acceso a memoria o que un micro tenga que esperar los datos que necesita del otro (dependencia).
Los sistemas multiprocesador nunca escalan linealmente según en número de CPUs que tienen, ya que comparten buses. Los AMDs actuales no adolecen tanto de esos problemas (gracias al Hypertransport y al controlador de memoria integrado en cada CPU) y son los únicos que se acercan en algunos casos a las cifras ideales.
Yo optaría por el reparto de carga según el tipo de tarea, dando a cada CPU ocupaciones concretas y no dependientes (o al menos estrictamente dependientes). De todas formas aqui tiene mucho que ver la imaginación del programador y las mil y una formas de sacar provecho a la arquitectura.
Sigo pensando como al principio: esta maquinita todavia nos tiene reservadas muchas sorpresas positivas y puede representar el principio del cambio.
Muy buena noticia :)
Ojala los de GPH se den cuenta que el segundo procesador "existe",
y nos deleiten con un nuevo firmware en condiciones......
LukStarkiller
06/12/2005, 08:52
No se exactamente las prestaciones tecnicas del conjunto de chips pero no seria logico que los que diseñaron el chip magiceyes pusiesen 2 chips de similares prestaciones sino se pueden usar los dos simultaneamente, igualmente supongoq eu cada uno dispone de cache propia por lo cual bien sincronizados podrian por lo menos aprovechar mas el acceso a memoria si es que lo comparten.
Y más noticias buenas:
Rlyeh ha conseguido usar el segundo core bajo linux usando su minimal lib. :saltando: :saltando:
este hombre es dios!!! :brindis: :brindis:
Oye Rlyeh.... y a que horas duermes???
No quiero despreciar los valores que arrojan los tests de Squidge, sino más bien aplacar un poco la euforia. Este test en concreto presenta la situación más favorable para el sistema: uso minimo de la memoria principal por parte de las dos CPU y un reparto previo de la carga.
En una situación real podríamos encontrarnos con un cuello de botella en el acceso a memoria o que un micro tenga que esperar los datos que necesita del otro (dependencia).
Squidge ya ha realizado la prueba para ver esta posible situación y el resultado ha sido muy positivo:
Usando 10MB de datos de memoria, escribiendo 2GB y leyendo 1GB:
Tanto el 920 como el 940 tardaron 28 segundos cada uno por separado.
Usando ambos procesadores de forma simultánea, por lo que ambos trataban de acceder al bus de memoria al mismo tiempo: 31 segundos.
Luisodin
07/12/2005, 01:30
Squidge ya ha realizado la prueba para ver esta posible situación y el resultado ha sido muy positivo:
Usando 10MB de datos de memoria, escribiendo 2GB y leyendo 1GB:
Tanto el 920 como el 940 tardaron 28 segundos cada uno por separado.
Usando ambos procesadores de forma simultánea, por lo que ambos trataban de acceder al bus de memoria al mismo tiempo: 31 segundos.
Eso es malo :P no bueno
Eso es malo :P no bueno
Eso quiere decir que en el caso de que ambos procesadores precises acceder a la memoria de forma simultánea, el "cuello de botella" no es tan grande como la gente había dicho, por lo que la caída de rendimiento sería muy pequeña. Así, las ventajas que supone el uso de los dos procesadores a la vez son mucho más grandes que las posibles desventajas.
Luisodin
07/12/2005, 01:38
Eso quiere decir que en el caso de que ambos procesadores precises acceder a la memoria de forma simultánea, el "cuello de botella" no es tan grande como la gente había dicho, por lo que la caída de rendimiento sería muy pequeña. Así, las ventajas que supone el uso de los dos procesadores a la vez son mucho más grandes que las posibles desventajas.
Y no hay manera de arreglar ese cuello de botella? osea dividir la memoria en 2 "partes" para que no se pisen? Pero claro esto perjudicaria en el rendimiento
Lo que yo interpreto es que sólo se pierden 3 segundos si los dos procesadores intentan acceder a la memoria, así que podría ser viable el uso simultáneo porque aunque se pierdan 3 segundos en escribir a la memoria, si los dos procesadores hacen cálculos a la vez, los cálculos que se hagan en el segundo procesador quizá habrían tardado mucho más de esos tres segundos si se hacen en el primero después de que éste hiciera los cálculos que le corresponden.
Me hice un lío y además no tengo ni idea de si es lo que quiere decir, así que puedo estar diciendo una burrada :musico:
Saludos...
El cuello de botella seria pequeño, pero esque ademas el cuello de botella solo se daria en el caso de que los dos procesadores accediesen a la memoria al mismo tiempo, cosa que no va a ocurrir la mayoria del tiempo, lo cual es muy bueno :)
podriais hacer una explicacion mas facil de entender para estupidos como yo xDDD con ejemplos como ¿si el emulador de psx con esto habra posibilidades de que vaya al 100% aunque sea sin sonido?
saludos
3 segundos de retraso.
Y tranquilos que los procesadores no se pisan, son muy educados y se esperan cada uno a que acabe el otro.
Pero bueno la idea es que en los emus los procesadores se encargaran cada uno de una cosa y no estaran todo el rato poniendose la zancadilla.
3 segundos de retraso sobre 30 es muy poco retraso o me lo parece a mi?
hectorblanco
07/12/2005, 02:05
¿Y quien es el guapo q se va a poner a programar en ensamblador usando multiproceso?
Puede llegar a ser desesperante.
¿Y quien es el guapo q se va a poner a programar en ensamblador usando multiproceso?
Puede llegar a ser desesperante.
Creo que las pruebas de Squidge están hechas en C.
Creo que las pruebas de Squidge están hechas en C.
efectivamente:
for (i = 0; i < 100; i ++)
{
memcpy (mallocbuffer1, mallocbuffer2, 5120*1024);
memcpy (mallocbuffer2, mallocbuffer1, 5120*1024);
memset (mallocbuffer1, 0x55, 5120*1024);
memset (mallocbuffer2, 0xAA, 5120*1024);
}
hectorblanco
07/12/2005, 02:20
efectivamente:
Pero de alguna forma tiene que haber especificado el core al que tienen que realizar esas operaciones. Si se puede hacer esto de una forma no demasiado compleja soy el primero que se apunta a usarla.
Por cierto, y aunque esto iria en otro tema... ¿Se sabe cuando van a haber versiones de desarrollo que funcionen bien de las SDL_image, SDL_mixer y SDL_ttf?. Asias.
Bueno , si se curran un SDK bueno , podrian simplificar mucho la cosa hasta un modo que sea casi automatico y que para proyectos mas o menos simples pueda utilizarse como un unico procesador , no?
Puck2099
07/12/2005, 02:58
Por cierto, y aunque esto iria en otro tema... ¿Se sabe cuando van a haber versiones de desarrollo que funcionen bien de las SDL_image, SDL_mixer y SDL_ttf?. Asias.
SDL_image funciona perfectamente, SDL_mixer compila pero no suena y SDL_ttf no he probado...
Saludos
Bueno , si se curran un SDK bueno , podrian simplificar mucho la cosa hasta un modo que sea casi automatico y que para proyectos mas o menos simples pueda utilizarse como un unico procesador , no?
Según parece rlyeh ha conseguido usar el segundo procesador en su minimal library, por lo que supongo que con el tiempo surgirán librerías o SDK ya preparados para usar ambos procesadores.
Y la verdad, por la velocidad a la que va, voy a tener que cambiar mis previsiones de que se tardaría un año en empezar a explotar el segundo procesador, porque parece que será cuestión de pocos meses... :)
Creo que ni los mas optimistas esperaban tanto de esta consola (y de los coders)en menos de un mes. Ni siquiera tu anarchy. Increible.Espero que esto no decaiga como con psp , que pase como con la GP32... siempre vivita y coleando.
Me rio yo de la famosa lista que hicieron los de gp32x de lo que llegaria a hacer la consola.... :rolleyes:
efectivamente:
Originalmente Escrito por squidge
for (i = 0; i < 100; i ++)
{
memcpy (mallocbuffer1, mallocbuffer2, 5120*1024);
memcpy (mallocbuffer2, mallocbuffer1, 5120*1024);
memset (mallocbuffer1, 0x55, 5120*1024);
memset (mallocbuffer2, 0xAA, 5120*1024);
}
¿Donde está ese código? a mi lo que más me interesa saber es cómo se le indica al segundo procesador qué codigo es el que tiene que ejecutar.
Y no hay manera de arreglar ese cuello de botella? osea dividir la memoria en 2 "partes" para que no se pisen? Pero claro esto perjudicaria en el rendimiento
Pues irónicamente eso es lo que hay ahora, cada procesador tiene sus 32MB de ram para él solito.
Lo ideal sería que esta separación fuera dinámica, cosa difícil. Ahora bien, es más sencillo, *creo*, usar la mayor parte de la memoria para el 1er procesador, y un pequeño trozo para el 2do, que estará de apoyo para cálculos pesados (3d) o dedicados (música de fondo).
hectorblanco
07/12/2005, 03:29
SDL_image funciona perfectamente, SDL_mixer compila pero no suena y SDL_ttf no he probado...
Saludos
Pues a mi no hay manera de que me deje compilar enlazando con esas librerias.
Con las librerias normales para x86 nunca habia tenido ningun problema.
¿Donde está ese código? a mi lo que más me interesa saber es cómo se le indica al segundo procesador qué codigo es el que tiene que ejecutar.
Es una cita de squidge en gp32x.com, es lo único que puso asi que no se como hace que el segundo procesador lo ejecute
hermes PS2R
07/12/2005, 03:34
Pues a mi me gustaría saber, casi justo lo contrario:
- Me gustaria saber como apagar el segundo procesador y el resto de circuitería que no se use
- Me gustaría saber como regular la velocidad de ambos procesadores, pues el inconveniente que le veo a esta maquina, es la vida corta de las pilas....
Eso como poco, porque la mayoria de las cosas que se hacen, no tienen porque requerir una velocidad de proceso de 200Mhz, si no una mucho menor y ya es hora de que empecemos a velar por la autonomía de la consola tambien... (que no todo es correr como un Formula 1)
Puck2099
07/12/2005, 03:35
Pues a mi no hay manera de que me deje compilar enlazando con esas librerias.
Con las librerias normales para x86 nunca habia tenido ningun problema.
Mira este hilo (http://www.gp32spain.com/foros/showthread.php?p=297322#post297322) . Aunque esté hecho para Linux, tendría que funcionar igual en Windows, tan solo cambia el tipo de rutas y pon los directorios donde tienes los programas y librerías.
Saludos
Me rio yo de la famosa lista que hicieron los de gp32x de lo que llegaria a hacer la consola.... :rolleyes:
En aquella lista la emulación de neogeo era "probable, pero no completa", no te digo más :D :D :D
Pues a mi me gustaría saber, casi justo lo contrario:
- Me gustaria saber como apagar el segundo procesador y el resto de circuitería que no se use
- Me gustaría saber como regular la velocidad de ambos procesadores, pues el inconveniente que le veo a esta maquina, es la vida corta de las pilas....
Eso como poco, porque la mayoria de las cosas que se hacen, no tienen porque requerir una velocidad de proceso de 200Mhz, si no una mucho menor y ya es hora de que empecemos a velar por la autonomía de la consola tambien... (que no todo es correr como un Formula 1)
Tambien tienes razon , nos puede la ansia.
hermes PS2R
07/12/2005, 04:15
Tambien tienes razon , nos puede la ansia.
Ah! y otra cosa... estoy pensando que parte del problema de los scanlines, la tiene la falta de Vsync porque por ejemplo, en mi juego Pintor no se aprecian esos scanlines salvo en algunas ocasiones (que pienso debe coincidir con la actualizacion de la pantalla cuando le pilla el retrazado)
Ah! y otra cosa... estoy pensando que parte del problema de los scanlines, la tiene la falta de Vsync porque por ejemplo, en mi juego Pintor no se aprecian esos scanlines salvo en algunas ocasiones (que pienso debe coincidir con la actualizacion de la pantalla cuando le pilla el retrazado)
Comentan por ahí que es un problema con el timing.
Creo que el kernel 1.01 desactiva en parte el segundo procesador. Ahora estoy haciendo pruebas con el 1.0 reproduciendo mp3. Cuando las pilas se agoten las cargaré a tope y realizaré exactamente la misma prueba con la misma consola y las mismas pilas, pero con el kernel 1.01 para ver la diferencia de consumo.
Por el momento lleva 2 horas y 10 minutos reproduciendo mp3 sin parar con unas pilas de 2300mAh. Mañana espero poner los resultados finales con ambos kernel.
Comentan por ahí que es un problema con el timing.
Creo que el kernel 1.01 desactiva en parte el segundo procesador. Ahora estoy haciendo pruebas con el 1.0 reproduciendo mp3. Cuando las pilas se agoten las cargaré a tope y realizaré exactamente la misma prueba con la misma consola y las mismas pilas, pero con el kernel 1.01 para ver la diferencia de consumo.
Por el momento lleva 2 horas y 10 minutos reproduciendo mp3 sin parar con unas pilas de 2300mAh. Mañana espero poner los resultados finales con ambos kernel.
Pues ya que te pones podrias hacer la misma prueba con el firmware nuevo
hectorblanco
07/12/2005, 04:44
Mira este hilo (http://www.gp32spain.com/foros/showthread.php?p=297322#post297322) . Aunque esté hecho para Linux, tendría que funcionar igual en Windows, tan solo cambia el tipo de rutas y pon los directorios donde tienes los programas y librerías.
Saludos
hmmm, esk el problema me lo da cuando al momento del enlace con las librerias. Me da errores compatibilidad con el FP en software, ya que estan compiladas para FP software, y tambien me da errores con referencias no definidas en las librerias. Y ya he probado con todas las que hay por ahí disponibles.
Por cierto, estoy usando windows xp, con el devkit_rc2, y librerias, pues varias que he ido pillando que son para dev con la gp2x.
y tambien he probado varios metodos de como configurar el sistema, los entornos y todas esas historias.
Puck2099
07/12/2005, 04:53
hmmm, esk el problema me lo da cuando al momento del enlace con las librerias. Me da errores compatibilidad con el FP en software, ya que estan compiladas para FP software, y tambien me da errores con referencias no definidas en las librerias. Y ya he probado con todas las que hay por ahí disponibles.
Por cierto, estoy usando windows xp, con el devkit_rc2, y librerias, pues varias que he ido pillando que son para dev con la gp2x.
y tambien he probado varios metodos de como configurar el sistema, los entornos y todas esas historias.
¿Has probado el método de Guyfawkes?
Yo lo hice bajo XP y funcionaba sin problemas :)
http://www.rafb.net/paste/results/DDWIfg36.html
¿Donde está ese código? a mi lo que más me interesa saber es cómo se le indica al segundo procesador qué codigo es el que tiene que ejecutar.
¿ESTO (http://www.gp32x.com/board/index.php?showtopic=22714&st=45) es lo que buscas?
hectorblanco
07/12/2005, 05:19
¿Has probado el método de Guyfawkes?
Yo lo hice bajo XP y funcionaba sin problemas :)
¿Cual es concretamente?, porque ya he probado como 3 o 4, pero puede que no los acabara de hacer del todo bien.
Oh, one more thing: both CPU cores run from the same base clock, e.g. 400MHz. However the cores have independent dividers from this base clock, and so they can run at different frequencies! It is perfectly possible to run the 920T at 200MHz while the 940T runs at 100MHz, the Memory Controller takes care of the timing differences.
Esto es bastante interesante, asi se gastan menos pilas si el segundo micro no se va a usar al 100%.
Esto es bastante interesante, asi se gastan menos pilas si el segundo micro no se va a usar al 100%.
Yo estoy viendo que hace unas semanas la gente decía que era imposible usar los dos procesadores. Después se dijo que se podría, pero que sería super complicado. Ahora resulta que las pruebas realizadas lanzan resultados cojonudos, que no parece tan complejo y que rlyeh está haciendo pruebas con su minimal library para poder usar ambos cores...
Pues nada, que mis previsiones de 1 año para empezar a sacarle jugo al tema se van a pasar por varios meses [wei4] [wei4] [wei4]
mortimor
07/12/2005, 05:54
Warning, Hype!!!! Warning, Hype!!!
joderrrr ahora si que veo que esta maquina va a ser el nuevo celebro de la bestia!
biba la GP2X ! !
(aunque la mia muy viva muy viva no esta :( )
Puck2099
07/12/2005, 06:06
¿Cual es concretamente?, porque ya he probado como 3 o 4, pero puede que no los acabara de hacer del todo bien.
Bájate este manual (http://www.gp32spain.com/foros/downloads.php?do=file&id=79) . Creo que era en la página 33 o por ahí donde explicaban cómo montar el entorno :)
Saludos
hectorblanco
07/12/2005, 06:08
Bájate este manual (http://www.gp32spain.com/foros/downloads.php?do=file&id=79) . Creo que era en la página 33 o por ahí donde explicaban cómo montar el entorno :)
Saludos
Gracias Puck.
lo probare mañana por la mañana, que estoy bastante sobao, y me acabo de pegar una buena viciada al metal slug [wei4]
http://www.rafb.net/paste/results/DDWIfg36.html
¿ESTO (http://www.gp32x.com/board/index.php?showtopic=22714&st=45) es lo que buscas?
Gracias a los dos por los enlaces. Ya me ha resuelto la duda que tenía. Aunque el link de Franxis sólo es un ejemplo de llamadas a las funciones de la minimal lib, no viene el código de esas funciones (que es lo que me interesa) :)
En el hilo de gp32x que ha puesto oankali, en el post número 66 (pág. 5) squidge adjunta un link con el código en cuestión.
Para quien le interese, el código tiene unas funciones para acceder a la memoria con direcciones físicas, y poder dejar código y datos al 940. El código del segundo micro se ha de compilar enlazandolo a la dirección 0x0 y con algunas opciones "extrañas" de compilación (supongo que para dejar sólo en código ensamblador, sin cabeceras ELF, o algo así).
Después el código compilado se convierte a un array de C y lo mete en el código del programa principal (el del 920). Ese código se carga en la dirección física base del segmento de memoria del 940, y se reinicia el micro para que comience a ejecutar por ahí.
Viendo el ejemplo del código de rlyeh, supongo que las ML harán algo parecido, pero que proveen de una serie de operaciones básicas (SUMA, RESTA...) y se le puede especificar al segundo micro que las ejecute sobre determinados parámetros.
Personalmente creo que esta última opción es mucho más elegante y fácil de usar, aunque la versión de squidge sin duda dará mayor rendimiento versatilidad.
También se podría emplear un término intermedio, cogiendo las ML de rlyeh e incluyéndoles operaciones propias. :)
CONCLUSIÓN: Dentro de muy poco empezaremos a ver librerías y programas que hagan uso productivo del segundo micro [wei4]
CONCLUSIÓN: Dentro de muy poco empezaremos a ver librerías y programas que hagan uso productivo del segundo micro [wei4]Lo dicho :D :D :D
hectorblanco
07/12/2005, 06:32
Bájate este manual (http://www.gp32spain.com/foros/downloads.php?do=file&id=79) . Creo que era en la página 33 o por ahí donde explicaban cómo montar el entorno :)
Saludos
Pues estoy igual.
Lo he seguido al pie de la letra, instalando todo lo que pide, y en los demos me va bien, pero me falla en cuanto enlazo con la SDL_mixer y la SDL_ttf.
Puck2099
07/12/2005, 06:33
Pues estoy igual.
Lo he seguido al pie de la letra, instalando todo lo que pide, y en los demos me va bien, pero me falla en cuanto enlazo con la SDL_mixer y la SDL_ttf.
Ya, pero una vez tengas todo eso instalado, prueba con las demos que puse en el hilo de programar para Linux :)
Please, dime si funcionan :)
Luisodin
07/12/2005, 06:34
joderrrr ahora si que veo que esta maquina va a ser el nuevo celebro de la bestia!
biba la GP2X ! !
(aunque la mia muy viva muy viva no esta :( )
No mancilles ese nombre, que es unico.
Que te metooooooo :canon2: :canon2: :canon2: :canon2: :ametra: :ametra: :ametra: :shock:
hectorblanco
07/12/2005, 06:49
Ya, pero una vez tengas todo eso instalado, prueba con las demos que puse en el hilo de programar para Linux :)
Please, dime si funcionan :)
Ya lo unico que me sale son errores (sobre al SDL_ttf) de este tipo, que creo van relacionados con el freetype y algo con el floating point (FP):
c:\devkitgp2x\bin\..\lib\gcc\arm-linux\4.0.2\..\..\..\..\arm-linux\bin\ld.exe: ERROR: C:/devkitGP2X/lib\libfreetype.a(ftinit.o) uses hardware FP, whereas demo.gpe uses software FP
Todo lo otro, a base de combinar los libs a linkar ya no dicen nada raro.
Puck2099
07/12/2005, 06:55
Ya lo unico que me sale son errores (sobre al SDL_ttf) de este tipo, que creo van relacionados con el freetype y algo con el floating point (FP):
c:\devkitgp2x\bin\..\lib\gcc\arm-linux\4.0.2\..\..\..\..\arm-linux\bin\ld.exe: ERROR: C:/devkitGP2X/lib\libfreetype.a(ftinit.o) uses hardware FP, whereas demo.gpe uses software FP
Todo lo otro, a base de combinar los libs a linkar ya no dicen nada raro.
Eso es porque tienes compiladas esas librerías con FP por hardware. ¿Son las que venían en el pack o te las has bajado de otro lado?
hectorblanco
07/12/2005, 06:58
Eso es porque tienes compiladas esas librerías con FP por hardware. ¿Son las que venían en el pack o te las has bajado de otro lado?
las ttf no me venian. me las pasó efegea, que las compiló él.
¿Sabes de algun sitio de donde pillarlas, o si las tienes tu me las podrias pasar'
merci.
Puck2099
07/12/2005, 07:04
las ttf no me venian. me las pasó efegea, que las compiló él.
¿Sabes de algun sitio de donde pillarlas, o si las tienes tu me las podrias pasar'
merci.
Yo no las tengo, lo siento, pero seguramente las puedas compilar tú mismo usando los gcc para la GP2X :)
Saludos
hermes PS2R
07/12/2005, 08:14
Buenas,
pues yo he averiguado como bajar la frecuencia de ambos procesadores y se el procedimiento para desactivar el 940, tambien :)
En fin, a ver si puedo trabajar en ello mañana (tengo un día muy liado) y publico en el foro de programación el metodo ;)
Puck2099
07/12/2005, 15:08
Buenas,
pues yo he averiguado como bajar la frecuencia de ambos procesadores y se el procedimiento para desactivar el 940, tambien :)
En fin, a ver si puedo trabajar en ello mañana (tengo un día muy liado) y publico en el foro de programación el metodo ;)
La verdad es que te lo agradecería mucho para bajar el consumo de pilas en mis juegos :)
Saludos
Buenas,
pues yo he averiguado como bajar la frecuencia de ambos procesadores y se el procedimiento para desactivar el 940, tambien :)
En fin, a ver si puedo trabajar en ello mañana (tengo un día muy liado) y publico en el foro de programación el metodo ;)
Estaría muy bien una utilidad que permitiese desactivar el segundo micro a voluntad, sin tener que actualizar el firmware. :)
Estaría muy bien una utilidad que permitiese desactivar el segundo micro a voluntad, sin tener que actualizar el firmware. :)
Aquí (http://www.gp32x.com/board/index.php?showtopic=22714&view=findpost&p=307890) Squidge pone como activar el segundo procesador. Supongo que para desactivarlo será algo muy similar.
Entre Robster y Squidge han desecho al pobre mr mirko :rolleyes:
Entre Robster y Squidge han desecho al pobre mr mirko :rolleyes:
Por lo poco que me he leido del post, se lo tiene merecido xDDDDD [wei4]
Y ahora vendrá rlyeh a decirle que también en linux se puede usar con su minilibrería xDD
Saludos...
mortimor
07/12/2005, 22:14
Entre Robster y Squidge han desecho al pobre mr mirko :rolleyes:
Pues, aunque Mr Mirko utiliza una palabra inadecuada como "useless" no veo que este tan equivocado en algunas cosas. El siempre ha hablado del uso de las dos CPUs en linux y de que el multiproceso no puede ser transparente en ningun momento, no ha dicho que no se pudiera usar el 940t. Y lo que venia a decir es que, del modo que sugieren algunos, no es para nada trivial usar el 940 y requiere una aplicacion diseñada de forma muy especifica.
Es un avanze que se vaya conociendo todo esto, pero no quiere decir que se vaya a aprovechar a corto plazo de forma adecuada. El tiempo dira.
Aquí veo 2 conversaciones, los que "saben", que quieren saber como aprovechar el segundo micro a la hora de programar y los que quieren saber como funciona lo del multiproceso y el acceso a memoria.
A los primeros les diré que lo mejor para esto es que no tengan que programar para ello, sino que el propio compilador lo haga de forma transparente, o mejor aún, que nos lo dé, de la forma más efectiva posible, una nueva actualización de firmware. Me temo que ese firm no será oficial, por lo que estoy viendo. El hecho de dejar el segundo procesador en idle o trabajando poco para ahorrar recursos en tareas secuenciales puede ser un ahorro bestial de pilas. Usar el segundo procesador sólo para tareas concretas en emuladores poco potentes también. Y una multitarea bien preparada para programas que exijan mucha máquina puede dar un potencial muy grande, aunque eso dependerá de los coders.
En cuanto a lo segundo. Decir que no siempre se puede usar la multitarea. Hay tareas, como calcular las raíces de un número, que son secuenciales, hasta que sale el resultado del primer decimal no puedes empezar a calcular el segundo. En estos casos (ej. escuchar mp3) no es necesario el segundo micro. En otros casos si que puede ser interesante, hay tareas muy complejas como puede ser el hecho de usar varias capas de imagen en los juegos, sonido, etc... Ahí si que se va a notar el uso de los 2 procesadores, siendo el límite teórico la duplicación de rendimiento. En cuanto al acceso a memoria, hay que tener en cuenta que la memoria lee/escribe 1 sólo dato cada vez, por lo que segmentarla puede ayudar a que no se sobreescriban datos, pero no aumenta la velocidad, para eso harían falta 2 memorias independientes. Esto no tiene tanto sentido como parece, ya que hay que tener en cuenta que los 2 procesadores están trabajando para obtener 1 sólo resultado final, y muchas veces necesitarán datos con los que ha trabajado el otro procesador. Además, el segundo procesador no sabe en qué dirección de memoria están los datos, se lo tiene que decir el primero. Hay 1 tipo de memoria que puede leer/escribr en varios registros al mismo tiempo, pero es muy cara y se suele usar en tarjetas gráficas normalmente. Lo que nos viene a decir que la única manera de que no se sature la memoria por intento de acceso de ambos procesadores al mismo tiempo, es que la memoria sea lo suficientemente rápida.
PD: A mi los 3 segundos de retraso no me parecen tan pocos, la memoria RAM actual es muy rápida, no creo que sea un ahorro de costes razonable el hecho de meterla más lenta. Le podían haber metido una algo más rápida con un aumento insignificante de costes. Que los procesadores son de 200Mhz, no de 2000Mhz como los PCs actuales, la tasa de transferencia de estos es pequeña.
Pues, aunque Mr Mirko utiliza una palabra inadecuada como "useless" no veo que este tan equivocado en algunas cosas. El siempre ha hablado del uso de las dos CPUs en linux y de que el multiproceso no puede ser transparente en ningun momento, no ha dicho que no se pudiera usar el 940t. Y lo que venia a decir es que, del modo que sugieren algunos, no es para nada trivial usar el 940 y requiere una aplicacion diseñada de forma muy especifica.
Es un avanze que se vaya conociendo todo esto, pero no quiere decir que se vaya a aprovechar a corto plazo de forma adecuada. El tiempo dira.
Mr Mirko ha atacado a la consola desde el principio y aunque ahora parezca decir lo contrario, sabía perfectamente el significado de la palabra "useless", ya que su inglés es bastante bueno y solo debes ver sus post anteriores. Dijo que se tendrían serios problemas con la gestión de memoria (lectura/escritura) con ambos procesadores de forma simultánea y Squidge demostró que no. Por su parte Robster también le desmontó varias de sus afirmaciones, por lo que realmente le han "desecho".
Podrá tener parte de razón, pero en general ha quedado bastante mal después de que Squidge y Robster derrumbases gran parte de sus afirmaciones. Y rlyeh tiene pruebas de sus librerías funcionando con los dos cores bajo linux...
PD: A mi los 3 segundos de retraso no me parecen tan pocos, la memoria RAM actual es muy rápida, no creo que sea un ahorro de costes razonable el hecho de meterla más lenta. Le podían haber metido una algo más rápida con un aumento insignificante de costes. Que los procesadores son de 200Mhz, no de 2000Mhz como los PCs actuales, la tasa de transferencia de estos es pequeña.
Los procesadores son realmente de 266Mhz y ya se ha probado que se pueden poner a esta velocidad sin riesgo para la máquina (pero con el consiguiente riesgo para las pilas) [wei4]
mortimor
07/12/2005, 23:00
Hombre, se ve que ha matizado sus palabras porque le estaban dando sopas con ondas, pero las apreciaciones que ha hecho globalmente sobre la dificultad de la programacion de las dos CPUs creo que son ciertas.
Con suerte el SDK ese que estan preparando salga pronto y estas tareas sean mas sencillas de realizar.
A MonXP le tengo que dar la razon en casi todo y sobre todo en lo de ahorrar con la memoria. Y solo decir que 3 segundos son casi un 10%.
Tambien tengo que puntualizar que es posible que si tenga sentido la segmentacion de la ram en linux segun han preparado en GPH el mplayer. Dado que usan el 940t para decodidificar es posible que utilicen la PU para acceder al segundo segmento sin necesitar direcciones fisicas proporcionadas por el 920t, con la memoria segmentada se evitan excepciones en el kernel (si no me equivoco). Esto es una especulacion eeehhhh.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.