RUMOR: Problemas CPU CELL, mas lento de lo esperado

tu link no me conduce a ninguna noticia...

Dejo esta de la misma pagina....

NOTICIA CELL Y LINUX

Me encantan las nocicias del Cell, me parece un procesador 'misterioso'...

Si alguien lee la noticia que me explique las consecuencias....'como si fuese un niño de 5 años'...

f5inet escribió:http://barrapunto.com/journal.pl?op...=19560&id=17329

es la tipica historia de: 'dice mi primo que le ha dicho un amigo que su tio...' pero el trasfondo tecnico es inquietante.

segun cuenta el link, CELL-PPE no incorpora ejecucion fuera de orden, dejando el proceso de optimizacion al compilador... y si el compilador es 'malo' o no esta lo suficientemente optimizado, el codigo resultante es bastante lento, amen que aun no saben como usar los SPU para que funcionen como es debido...

por supuesto, todo puede solucionarse con un compilador mas optimizado, pero no deja de ser preocupante de confirmarse el rumor...

Ésto no es nuevo, ya se ha hablado en nosecuantos hilos en EOL. Una de las diferencias que se ha hablado es la diferencia de programar en 360 y PS3, debido a las arquitecturas y a las herramientas disponibles, siendo "a priori" mucho más fácil para la 360.

De todos modos, las herramientas que de SONY a sus desarrolladores serán lo suficientemente buenas, para que eso no pase. Aunque sigo viendo que hay una distancia muy importante entre 360 y PS3 en éste aspecto, que iguala mucho a las máquinas.

Tanto cell, como el micro de x360 son procesadores in order, eso no es ninguna novedad....Y si, son mas lentos ejecutando codigo preparado para un out of order. Pero vamos, ni es nuevo, ni es algo por lo que preocuparse, para eso están los compiladores y las buenas artes de los programadores.

filetefrito escribió:Tanto cell, como el micro de x360 son procesadores in order, eso no es ninguna novedad....Y si, son mas lentos ejecutando codigo preparado para un out of order. Pero vamos, ni es nuevo, ni es algo por lo que preocuparse, para eso están los compiladores y las buenas artes de los programadores.

AAAAAAh!!!

Ya recuerdo una conversación sobre el tema en otro hilo...

En definitiva el tema esta en las herramientas de desarrollo y la pericia del programador...vamos, como siempre.

En definitiva el tema esta en las herramientas de desarrollo y la pericia del programador...vamos, como siempre.

No exactamente, hay una pequeña diferencia, la mayoría de procesadores actuales son micros out of order, con lo que la vuelta a la utilización de micros in order requiere algunos ajustes en compiladores, y tal vez un mayor orden en el programador. Aunque creo que Vidda, si fuese tan amable podría explicarlo de forma infinitamente más correcta y precisa.

takeda escribió:Si alguien lee la noticia que me explique las consecuencias....'como si fuese un niño de 5 años'...

oido cocina!!!!

la 'ejecucion fuera de orden' se viene usando desde los PentiumII +o-

mas o menos viene de la necesidad de hacer el pipeline mas grande mientras se mantiene la misma velocidad de ejecucion...

todo procesador tiene lo que se denomina 'pipeline', que es su hilo de ejecucion... dicho en plata, lo que ejecuta el codigo.
pero claro, ese codigo debe ser decodificado a un estado en el que la CPU sepa que hacer con el, realizar los accesos a memoria, ejecuta propiamente el codigo, y sacar el resultado a memoria o al registro implicado. hemos llegado al punto en el que la CPU no es capaz de hacer el proceso de alimentarse, decodificar, acceder a ram, ejecutar la instruccion y provocar la salida en un solo ciclo de reloj. entonces se crearon pipelines (o hilos de ejecucion) de varias etapas. digamos, por ejemplo, que una CPU usa una pipeline de 5 etapas (que son pocas), en la cual hace:
- decodificacion (analiza el codigo recibido para acceder a lo necesario)
- prefetch (prepara los accesos a RAM o a registros a un estado estable)
- Fetch (realiza los accesos a RAM o registros)
- Ejecuta (ejecuta propiamente el codigo)
- Salida (realiza la escritura al registro pertinente para dar por finalizada la ejecucion)

con una pipeline de 5 etapas, tu codigo entraria en decodificacion en el primer ciclo, en el segundo ciclo el codigo entraria en prefetch, pero ya estaria entrando otro codigo en decodificacion... por decirlo asi, es como si una pipeline estubiera ejecutando 5 instrucciones a la vez... pero en cola...

el problema llega cuando la hay una bifurcacion. si en la etapa de ejecucion se descubre que hay un salto en la ejecucion a otra parte del codigo, el trabajo que esta realizando las etapas de decodificacion, de prefetch y de fetch es basura, porque es codigo que no se deberia ejecutar debido al salto, en tal caso, la pipeline se va a la mierda y debe ser descartada, porque despues del salto, la pipeline debe llenarse de nuevo antes de que la CPU vuelva a procesar datos, con lo cual se dice que un salto tiene una penalizacion de 'x ciclos' que es el tiempo que tarda la pipeline en llenarse de nuevo.

esto se alivia realizando 'ejecucion fuera de orden', cuando hay un salto, el salto se detecta en la etapa de 'decodificacion', no en la de ejecucion, con lo cual la CPU 'intenta adivinar' hacia donde va a ir el salto y empieza a llenar la pipeline con donde ella cree que va a ir, entonces se dice que el salto solo tiene una penalizacion de '1 ciclo' o 'ciclo de decodificacion'. pero claro, cuando se realiza un salto condicional (o sea, salta solo si tal valor es tal...) la CPU solo puede determinar la direccion real del salto en el momento de ejecucion, en tal caso, la CPU tiene que 'apostar' por donde empezar a llenar el pipeline... si acierta, pues solo tiene de penalizacion el 'ciclo de decodificacion', si falla la prediccion, tiene que volver a llenar la pipeline...

ahora, lo normal es que los CPUs actuales tengan pipelines de hasta 30 (TREINTA!!) etapas, con lo cual un error en la ejecucion fuera de orden hace que se tenga la CPU ociosa durante 30 ciclos de CPU hasta que se llene otra vez la pipeline... por ponerte un ejemplo, un P4 que no use ejecucion fuera de orden, seria unas 20 veces mas lento de lo que actualmente es...

pues ese es el problema de la PS3 al parecer... el trabajo de mantener la CPU constantemente ocupada recae en el compilador, que debe intentar que todo el codigo que se ejecute de forma continua quede secuencialemente colocado para que no halla ningun salto que eche a perder esa maravillosa pipeline de unas 30 etapas... con lo cual el compilador, ademas de ser compilador, debe ser interprete para hacer un analisis de la ejecucion y ver cuantas 'pipelines basura' se generan e intentar reordenar el codigo para aliviarlo lo maximo posible...

pues ese es el problema de la PS3 al parecer...

De la ps3, y de xbox360, y de cualquier micro in order.En cualquier caso, los pipelines de un ppc, si mi nefasta memoria no me falla, son bastante más cortos que en un pÍV, ( similares a un A64 si no recuerdo mal, aunque creo que con algun paso menos).
En cualquier caso, una gran explicación F5net, muchas gracias.

Muchas gracias, con tu explicación entiendo tambien lo que queria decir filetefrito....

Si el programador hace el codigo mas 'secuencial' y facilita esa tarea de 'interprete' al compilador todo iria mucho mas rapido (no es lo mismo que el compilador tenga que ir colocando las instrucciones de una determinada forma dentro de un codigo 'desordenado' que dentro de uno 'ordenado')...

Si he dicho muchas burradas...reportarme a un moderador...

Creo que lo que has explicado es la predicción de saltos
(que esta relacionado pero no es lo mismo)

La ejecución Out of order es por las dependecias de datos
y cosas asi EJ:

1º a=a+b
2º c=a*2
3º ......

La 2º instrucción debe de esperar a la primera
en un in-order la 3º esperara tambien
pero si la CPU es out-of-order la 3º podria pasar a ejecutarse
(si eso no rompe el significado original del programa)
Asi evitas ciclos muertos

A un compilador no debe de costarle mucho reordenar
el problema es que en PC y otras arquitecturas mas'"abiertas"
no se puede reordenar a priori (por que no sabe la CPU exacata
donde se ejecuta)
En una consola donde la arquitetura es cerrada no hay ningun
problema

bueno, la 'ejecucion fuera de orden' se usa para la prediccion de saltos casi exclusivamente... para la dependencia de variables se suele usar una segunda pipeline (recuerdo que incluso el primer pentium tenia 2 pipelines, llamadas U y V, y que se usaban para eso mismo, de hecho, recuerdo que en los listados ASM del primer quake estaban optimizados para usar ambos pipelines...)

de hecho el hyperthreading de los P4 es 'una segunda pipeline con esteroides'... lo que han hecho es, mas o menos es usar la segunda pipeline como CPU logico...

Da gusto leer hilos en los que se explica las cosas tan de puta madre

Pos eso, queda claro, que es tema (como casi siempre) de programación.

Creo que lo que has explicado es la predicción de saltos

Predictor de saltos sería el branch predictor?
Porque si no me equivoco, los nucleos ppc tanto de x360, como ps3, si que tienen branch predictor, algo que los spe del cell si que no tienen ( lo que reduce su capacidad para su utilización para IA).

PD: Que no lo he dicho en ninguno de mis post anteriores, si digo alguna tontería, estaré encantado de ser corregido.

Creo que el "aun no saben como usar los SPE" es algo bastante confuso.

A nivel tecnico, si que existe infraestructura para poder emplearlos, y encima con bastante facilidad.

En cuanto a nivel practico, es probable que haya programadores que no sepan como aprovecharlos, o como hacerlo correctamente.

Usarlos y aprovecharlos son terminos distintos.

El que sea In-order u Out-of-Order, es algo que influye bastante. El compilador de PS3 debe ser mas "inteligente" a la hora de ordenar las instrucciones, pero ya hay tecnología en compiladores como el GCC que hacen esto de forma bastante eficiente..

Entonces In-Order es una desventaja? donde esta el truco, de donde se saca la ventaja respecto a los out-of-order?

la ventaja que tienen los in-order es que la CPU necesita usar menos transistores en burocracia, con lo cual el tamaño del dye es mas pequeño... teoricamente sale mas barato fabricarlos...

y si, los PowerPC y CELL tienen una pipeline MUCHO mas corta al ser CPUs RISC puros, en lugar de RISC con un traductor CISC como son los X86...

y bueno, parece que he liado un poco la cosa... tanto la 'branch prediction' (prediccion del salto) como el 'instruction reordering' (reordenacion de instrucciones) son tecnicas para mantener llena la pipeline y que no se produzca una pipeline basura. a ese conjunto de tecnicas se les denomina 'out-of-order execution' (o ejecucion fuera de orden, es decir, ejecutar instrucciones que no corresponderian)

he expuesto el caso de la prediccion de salto porque es el mas sangrante con respecto a la pipeline basura. la reordenacion de instrucciones me parece mas complicado de explicar y de entender, puesto que la penalizacion de la ejecucion tan solo es 'retener' la pipeline durante la etapa de 'fetch'. es decir, si tu quieres hacer a=b+c y luego d=a+1 no puedes calcular 'd' hasta terminar de haber calculado 'a'. en tal caso lo que sucede es que ese problema se descubre en la etapa de 'prefetch', viendo que 'a' esta bloqueada por una instruccion anterior y se paraliza la pipeline en 'fetch' hasta que la instruccion a=b+c salga por salida y se libere el bloqueo sobre 'a', en ese momento la pipeline sigue avanzando, con lo cual solo se pierden unos pocos ciclos (los correspondientes a la etapa de fetch y de ejecucion de la instruccion d=a+1, que en nuestro ejemplo de pipeline de 5 etapas, serian 2 ciclos)

El PPU del CELL tiene un pipeline de 21 etapas, frente a las 17 del athlon64 y lss 15 si no recuerdo mal del PPC970. Se estima que la CPU de la XBOX360 tambien tenga un pipeline de 21 etapas, por varias imformaciones tecnicasa sobre el.

Una de las ventajas de la ejecucion Out-order tambien es tapar los fallos de cache, 525 ciclos en la Xbox 360 si falla la cache de L2, en general estos problemas se solucionan tambien usando los 2 thread hardware de los nucleos power.

Lo unico que me estraño es que cuando liberaron el compilador de los SPU de la PS3 dijeron que no hacia falta un compilador para el PPU por que se podia usar uno de PowerPC (utilizan las mismas instrucciones) pero este no te generaria codigo optimizado (ordenado) para el PPU, si los desarrolladores de juegos estan igual pues lo tienen un tanto jodido de momento.

Me voy aclarando...

A parte de ese ahorro a la hora de fabricarlos ¿tienen alguna otra ventaja?.

takeda escribió:Me voy aclarando...

A parte de ese ahorro a la hora de fabricarlos ¿tienen alguna otra ventaja?.

Ahorro tambien quiere decir poder meter más, los ultimos athlon dual-core son más grandes que la CPU de la Xbox-360.

mas que ventajas, tienen muchos inconvenientes para el programador... el problema de hacer todo el codigo lo mas 'plano' posible (esto es, con el minimo de comparaciones y saltos posibles) hace que se use mucho una tecnica conocida como 'loop unrolling' o 'desenrollado de los bucles'

es decir, si tu tienes este codigo:
for a=1 to 5
print "hola"
next a

haces 5 saltos, o lo que es lo mismo, 5 pipelines basura, en tal caso, el compilador suele hacer esa tecnica y generar un codigo tal que asi:
print "hola"
print "hola"
print "hola"
print "hola"
print "hola"

que es mas rapido porque no hay ninguna pipeline basura...

el problema es cuando 'a' es un numero muy grande... el loop unrolling hace que el codigo resultante sea MAS LARGO, con lo cual se producen mas fallos en la cache L1 y L2, lo cual se traduce en mas accesos a RAM y codigo mucho mas lento que si hubieran pipelines basura... (como han explicado mas arriba, un fallo de cache L2 puede significar una espera de mas de 500 ciclos, comparando con 5 pipelines basura a 21 ciclos cada uno, apenas serian 100 ciclos perdidos en lugar de esos mas de 500)

como podeis ver, el compilador tiene mucho que ver en esta generacion de consolas... de hecho, si una compañia sacara un compilador realmente bueno, podria hacerse de oro vendiendolo a las desarrolladoras (ahora recuerdo el compilador WatcomC++ que era muy popular en la epoca del 386/486 y su famosa coletilla 'DOS/4GW Protected mode Run-Time...)

PD: se que el anterior codigo BASIC al convertirse en ASM seria muy distinto, pero solo lo he puesto para ilustrar el ejemplo, no pretendia ser 'puntillosamente correcto'

Con lo del for me he quedado a cuadros, pero es un ejemplo cojonudo.

Ahora me surge un pregunta ¿no es un paso atras?.

Bueno, tenienda en cuenta que las desventajas lógicas son "subsanables", sobre todo teniendo en cuenta que son arquitecturas cerradas muy optimizables en lo referente a los compiladores, las ventajas son claras: en el caso de x360 puedes tener 3 nucleos a más velocidad con el mismo consumo y disipación de energia, y algo similar con el cell..
PD: como siempre incluyo la coletilla, si digo burradas , que alguien me pegue un grito.
Lo que me ha dejado un poco tocado es lo de que el branch predictor se incluiría entre los elementos de un out of order.
Yo tenía entendido que el core de x360 y el ppc de ps3 si que tenian branch predictor. No se supone que su ausencia, con la incidencia que pueden suponer los saltos condicionales, penalizaría mucho con respecto a un in order en temas de ia?

oh, si, la X360 y PS3 tienen branch prediction, pero solo a efectos de llenar la cache...

por decirlo asi, si es posible que en un salto el codigo salga fuera de lo que esta almacenado en cache L2 o L1, hace una peticion de refresco de cache, asi en lugar de perder 500 ciclos en refrescar la cache, perderia 500-20 (500 ciclos de refresco de cache - (21 ciclos de pipeline - 1 de decodificacion y localizacion del salto))

los refrescos de cache L2->L1 son mucho mas rapidos (creo recordar del orden de 15 ciclos) asi que un branch prediction con exito de cache L2 a L1 no tendria ninguna penalizacion adicional salvo el coste de volver a llenar el pipeline (los 21 ciclos de rigor de llenado de pipeline)

La prediccion de saltos no tiene nada que ver con in-order o out-order.

La ventaja es siempre la misma, saber cual es el codigo que se ejecutara despues del salto y meterlo en el pipeline, es decir comenzarlo a ejecutar aun sin estar seguro de que se va a ejecutar (si es un salto no condicional si estas seguro).

Lo de que el salto pueda o no provocar un fallo de cache es algo colateral.

En el ejemplo del for da igual que lo ejecute un out-order que un in-order, siempre haces unroling para reducir el numero de saltos es una optimizacion tipica para usar más memoria pero que el codigo vaya más rapido.

takeda escribió:Me voy aclarando...

A parte de ese ahorro a la hora de fabricarlos ¿tienen alguna otra ventaja?.

El tener un chip más simple es un ahorro en coste y ademas
suele permiter velocidades de reloj más altas.
¿alguien ha visto un G5 u otro PPC a 3.2Ghz?

Tambien disminuye el consumo de potencia del micro
y hace que se caliente menos.

¿Elohe recuerdas alguna página donde pueda ver esas
estimaciones, sobre la lngitud del pipe de estos chips?

Harl escribió:¿Elohe recuerdas alguna página donde pueda ver esas
estimaciones, sobre la lngitud del pipe de estos chips?

De donde he leido lo del de la Xbox360, la verdad no recuerdo donde fue, sobre el PPU del CELL remito a este PDF: MPR Cell details, te lo bajas directamente de IBM, asi que supongo que es de fiar. Y teniendo en cuenta la velocidad de funcionamiento, es logico que el tamaño del pipe del de la Xbox360 sea similar al del PPU del CELL, es mas parece que comparte con el PPU del CELL mucho mas de lo que se pueda pensar.

gracias Elohe

f5inet escribió:y si, los PowerPC y CELL tienen una pipeline MUCHO mas corta al ser CPUs RISC puros, en lugar de RISC con un traductor CISC como son los X86...

Nunca habia oido eso de "out of order" y habeis hecho muy bien explicandolo. Bueno, me parece que me salgo un poco del tema, pero yo tenia entendido que los x86 eran CISC, no? o es que con el tiempo han cambiado a RISC y han puesto un traductor CISC para mantener compatibilidad con las generaciones anteriores?

piteta escribió:
Nunca habia oido eso de "out of order" y habeis hecho muy bien explicandolo. Bueno, me parece que me salgo un poco del tema, pero yo tenia entendido que los x86 eran CISC, no? o es que con el tiempo han cambiado a RISC y han puesto un traductor CISC para mantener compatibilidad con las generaciones anteriores?

Pues eso, lee bien, dice bien al afirmar que los x82 son CISC.

salu2

pues es lo q me esperaba. Gracias por la aclaracion

Por la informacióin y porque el titulo era para que alguno entrara despotricando.

Saludos a todos.

deathkiller escribió:La prediccion de saltos no tiene nada que ver con in-order o out-order.

Lamentablemente si que tiene que ver y mucho, eso no indica que en ambos tipos no pueda haber prediccion de saltos, pero las tecnicas pueden llagar a ser muy diferentes, benecifiando a los sistemas out-order por norma general.

deathkiller escribió:Lo de que el salto pueda o no provocar un fallo de cache es algo colateral.

Es cierto, pero al mismo tiempo es util predecir ese fallo de cache, por lo que en muchos micros se adelanta el fallo de cache para tener unas latencias en espera menores.

deathkiller escribió:En el ejemplo del for da igual que lo ejecute un out-order que un in-order, siempre haces unroling para reducir el numero de saltos es una optimizacion tipica para usar más memoria pero que el codigo vaya más rapido.

Ironicamente el ejemplo es erroneo a nivel de CPU pero no a nivel de compilador, pues los pipelines se van igual al garete ya que "print" no es una instrucion, es una llamada a funcion. Que yo sepa el unroling no se suele usar para usar mas menoria, si no para que valla mas rapido, lo de usar mas memoria es us efecto colateral. Muchas veces el mejor unrolling es el manual ya que no desaces el bucle si no que lo reinventas para que valla mas rapido, sobre todo cuando hay mucha dependencia de datos.

Este seria un ejemplo mas correcto a nivel CPU, pensado para un

int A[6]; /esto es un vector de 6 elementos
int B[6]; /esto es un vector de 6 elementos
...
for[i=0;i<6;i++] A[i]=A[i]+B[i] ;
...
con unroling

int A[6]; /esto es un vector de 6 elementos
int B[6]; /esto es un vector de 6 elementos
...
A[0]=A[0]+B[0] ;
A[1]=A[1]+B[1] ;
A[2]=A[2]+B[2] ;
A[3]=A[3]+B[3] ;
A[4]=A[4]+B[4] ;
A[5]=A[5]+B[5] ;
...

obviamente con el 'print' pretendia ilustrar un ejemplo, no ser correcto ni entrar en tecnicismos de vectores.... se que es una llamada a una funcion lo cual implica usar la pila, hacer un salto, un retorno... etcetc...

pero como ya dije, solo pretendia ilustrar un ejemplo, no que el ejemplo fuera correcto informaticamente hablando...

Elohe escribió:Ironicamente el ejemplo es erroneo a nivel de CPU pero no a nivel de compilador, pues los pipelines se van igual al garete ya que "print" no es una instrucion, es una llamada a funcion. Que yo sepa el unroling no se suele usar para usar mas menoria, si no para que valla mas rapido, lo de usar mas memoria es us efecto colateral. Muchas veces el mejor unrolling es el manual ya que no desaces el bucle si no que lo reinventas para que valla mas rapido, sobre todo cuando hay mucha dependencia de datos.

Hombre no digo que uses el unroling por que quieras usar más memoria si no que es inevitable muchas veces al acelerar el codigo que este ocupe más memoria aunque casi siempre no te importa púes aun eso el codigo no suele ocupar mucho.

deathkiller escribió:Hombre no digo que uses el unroling por que quieras usar más memoria si no que es inevitable muchas veces al acelerar el codigo que este ocupe más memoria aunque casi siempre no te importa púes aun eso el codigo no suele ocupar mucho.

Siento si he puesto algo que ha podido molestar.... eso son 6 horas seguidas de optimizacion de codigo ( por que coño habre aceptado hacerlo, casi todo el rato he estado corrigiendo unrollings mal echos ), acabas con el coco quemado y echando chispas, por experiencia dire que a veces el unrolling puede hacer el codigo mas lento... ironico pero cierto... todo culpa de los pocos registros que tiene muchas cpus.

este hilo esta bien interesante. no soy fanatico de ningna consola. Me gustan todas porque todas tienen sus pros y cons. Bueno supuestamente la PS3 tiene la capacidad de correr a 240 FPS. Y si es asi eso quiere decir que puedes ver 3 diferentes peliculas a la misma ves. Como sera? no se sabe. pero el cell no es tan lento como parece. aqui os dejo con el link. Aunque yo no me creo ni pio.

http://news.spong.com/detail/news.asp?prid=9262

jdej663390 escribió:este hilo esta bien interesante. no soy fanatico de ningna consola. Me gustan todas porque todas tienen sus pros y cons. Bueno supuestamente la PS3 tiene la capacidad de correr a 240 FPS. Y si es asi eso quiere decir que puedes ver 3 diferentes peliculas a la misma ves. Como sera? no se sabe. pero el cell no es tan lento como parece. aqui os dejo con el link. Aunque yo no me creo ni pio.

http://news.spong.com/detail/news.asp?prid=9262

Mi gforce mx 440 es 6 veces mejor que el RSX .

buen punto maxtorete!!! eso es echar por tierra las palabras 'marketinianas' de sony...

jamas me asombrare de ver cuanto daño ha hecho hobby consola a la juventud videojueguil de este pais...

y digo yo... ¿que tendra que ver el tocino con la velocidad? ¿que tendra que ver que estemos hablando de CELL para que salga a discusion el RSX?

A mi esto me encanta: xbox360 muy cerca de salir, y hale venga noticias de "los desarrolladores se van de sony, sony mala, y se vienen a xbox", "ps2 es difícil de programar; de verdad de la buena", "xbox360 es fácil de programar"... vamos, que tengo una sensación de que me están encauzando hacia la compra de una xbox y que me deje de tonterías o de esperar a ps3.
Ahora es el momento de atar gente en microsoft.

No os compreis ninguna todavía. Esperad a finales del año que viene que estará todo más abrato y clarificado y disfrutad de las actuales consolas.

kulth escribió:A mi esto me encanta: xbox360 muy cerca de salir, y hale venga noticias de "los desarrolladores se van de sony, sony mala, y se vienen a xbox", "ps2 es difícil de programar; de verdad de la buena", "xbox360 es fácil de programar"... vamos, que tengo una sensación de que me están encauzando hacia la compra de una xbox y que me deje de tonterías o de esperar a ps3.
Ahora es el momento de atar gente en microsoft.

No os compreis ninguna todavía. Esperad a finales del año que viene que estará todo más abrato y clarificado y disfrutad de las actuales consolas.

Y si me gusta la línea de lanzamiento de Ms y para mí 400€ no son problemas, no me la puedo comprar?

parece ser que por lo q postean muchos no y vas a, parecer un infiel , que pasa que os pica q la xbox360 salga antes? no se no lo entiendo que tanto esperar si fuese ps3 o la revolution estas tu que veriamos a la gente decir que esperemos a ver la todas las consolas en el mercado , que no la compreis por que es consumismo

Si lo dices por mi, deja que te diga una cosa: no pienso comprar ninguna consola más. Desde la NES estoy en el mundillo y ya me cansé. Ni xbox, ni ps2, ni revolution; así que me considero bastante imparcial.

Por que no paran de salir malas noticias para las consolas de Sony? es creible este post?

Mohymanson666 escribió:Por que no paran de salir malas noticias para las consolas de Sony? es creible este post?

aqui hay que mojarse, yo lo postee como rumor posible. en el momento en que Elohe le dio credibilidad para mi ya es cierto 100%...

cada cual que piense lo que quiera...

pero vamos, que los CPUs de X360 tambien son in-order y tendran el mismo problema que CELL, aunque un poco menos acentuado porque ya hay compiladores especializados en ello... y Revolution tambien llevara un PowerPC, asi que otro CPU in-order...

yo jamas he declarado animosidad hacia una u otra consola para motivar o desmotivar compras. yo solo he expuesto argumentos. que cada cual haga lo que quiera...

Quiero aclarar algo sobre el CELL, y es que como CPU de proposito general deja mucho que desear, incluido para los juegos aunque como dispositivo de renderizado 3D por soft o DSP sea una maravilla. Desde que el CELL fue presentado en sociedad en foros tecnicos se puso siempre en duda su idoneidad para juegos, su capacidad en coma flotante esta demasiado descompensada, ciertamente es mas una CPU diseñada mas bien para maquinas de calculo masivo que para juegos. Hay ciertamente en terrenos donde le CELL destaca por si solo como pueda ser filtrado de imagenes, postproducion de video, renderizado 3D... son aplicaciones donde se usa mucho el calculo masivo, lamentablemente en juegos existe un techo en la relacion de "Calculo trivial/Flops" el cual ha sido superado con creces por el CELL, si incorporase 2 PPU y solo 4 SPUs realmente estariamos ante un micro mucho mas compensado para juegos.

La CPU de XboX360, usa la posibilidad de que cada core maneje dos threats para compensar en parte el que sea In-Order, cada core de la Xbox360 rinde un 20% mas que la PPU del CELL si se aprovechan correctamente los dos hilos, y aun asi un simple PPC970 a 2.5Ghz se come un solo core de la XBOX360 salvo en coma flotant donde es teoricamente sobre un 20% inferiore ( VMX, siempre que demos los Max-Gflops como validos) .

Sobre la CPU de la Revolution... hasta que no se conozca la informacion oficial no sabremos si es In-Order o Out-of-Order.

Desde mi punto de vista SONY la ha vuelto a cagar al igual que con PS2, otra cosa es que pueda tener el mismo exito en el mercado que con PS2.

el tema es que kutaragi cree firmemente que el calculo bruto en coma flotante es la llave para hacer mejores juegos, lo cual no es cierto, pero viendo los resultados de PS2 como plataforma equipando el Emotion Engine y siendo una patata en cuanto a "no-calculo" se refiere...pues tiene cierta logica que lo intente otra vez

saludos cordiales.

Es cuestion de opiniones, viendo el uso que se va a hacer en la mayoria de los casos de los core de la Xbox 360 excepto por la IA que depende de la como se haga todo lo que hacen los core que no ejecutan el engine se les da fenomenal a los SPU.

Es un problema meter una IA tradicional tocha (más grande que cualquier cosa vista esta generación) en el Cell.

El calculo entero en los SPU no es lento o descompensado, simplemente puedes ejecutar por ciclo el mismo numero de operaciones enteras que de coma flotante igual que en los PPU.

Lo normal en un juego es tener el engine principal que es muy dificil de dividir en threads y que tiene muchisimos saltos condicionales por lo que lo ejecutarias en el PPU, las cosas que puedes sacar del engine principal facilmente son la IA, las fisicas y tareas graficas. A los SPU se les da bien las fisicas y tareas graficas y mal la IA en la mayoria de los casos de todas formas cuando digo que se les da bien algo me refiero a que tengan un rendimiento cercano a un PPU, no hay nada que puedan hacer más rapido que un PPU.

Yo mediria el rendimiento de los SPU entre un 40 y 80% del de un PPU de la Xbox 360 segun la tarea si el codigo se ha optimizado el codigo, luego hay otras cosas a tener en cuenta como un menor retardo en el acceso a la X DR -RAM por tener el controlador de memoria en el propio chip.

yo creo que el problema principal del CELL es su arquitectura... (siempre que hablamos de procesamiento general y/o aplicados a videojuegos). matematicamente, CELL es un monstruo de gigaflops... el problema es que por arquitectura (que me corrija ELOHE si me equivoco) el PPU no es mas que un mayordomo que se encarga mantener ocupados a los SPU, o sea, que ocupar la PPU en procesamiento generico y atascar asi a los SPU provoca una caida de rendimiento... por decirlo asi, los SPU no pueden comunicarse directamente con el mundo exterior al CELL. para eso, el PPU debe coger de la RAM el 'microprograma' (<256KBs), cargarlo en la SPU y darle entrada para que la SPU empieze a procesar. y eso debe hacerlo la PPU con cada uno de los 7 SPU. si, al final 7 procesadores de un calculo vectorial bestial yendo cada uno por su lado... y la PPU en plan mayordomo sirviendo los accesos a memoria de los SPU y haciendo alguna tareita menor, como controlando el acceso a los perifericos y ejecutando algun codigo que por su simplicidad no merezca la pena ser cargado en la SPU y ejecutado...

por supuesto, el problema es que los programadores no estan acostumbrados a escribir codigo vectorial, estan acostumbrados a escribir codigo aritmetico, con lo cual deben aprender otra forma de programar, o tener un BUEN compilador que les haga el trabajo... como demostracion: llevamos varios años en X86 con extensiones como 3DNow!, MMX y SSE... y yo he visto realmente POCO software que usen esas extensiones... los programadores prefieren usar la FPU para calculos en coma flotante y sobrecargar la pila de la FPU que aprender a usar 30 nuevas instrucciones... (mas vale malo conocido...)

yo creo que sony a pensado en una maquina que sirva para todo mas multimedia que consola de videojuegos y eso personalmente a mi no me convence.
yo quiero la ps3 para jugar no para ver peliculas, por eso uno que se va a la x360.