recordáis aquello de... "esto representa el 25-30% del poder de X360"

Hombre ,como todo sistema nuevo , tendran que ir cogiendole el truco...a parte,que supongo que los programadores de jeugos no estarian acostumbrados a trabajar con 3 cores hasta ahora....

Supongo que la cosa mejorara mucho con el paso de unos meses.....Supongo que el TGS sera la prueba de fuego para M$ ,y espero que hagan alguna demostracion realmente espectacular que atraiga a la peña....( y se dejen de cutre fiestas en la MTV ..)

Total failure!!!!

Graficamente tampoco han crecido tanto, otra cosa es el tema del frame rate.....y de tener kits de desarrollo decentes....

Takeda, que me digas que tampoco han crecido tanto...... uno de los 2 necesitamos gafas..

un saludo

XNA truco? XNA solo es una plataforma de programación. No necesita "pillarle el truco" o eres bueno o eres malo programando, pero no tiene "truco" que pillar.

bueno, pues que se familiaricen con ella, o que la exploten al máximo como quieras llamarlo shadow.

un saludo

es que no tiene nada que ver el cerdo con la velocidad.

Es que el 30% venia de que solo tenian dos CPU que en conjunto alcanzaban al limite el 30% de la cpu final teórica
De una gráfica (X800) que era un tercio como mucho de la final (que Xenos se supone más rapida que la inmediata X1800 de ati, o sea, R520)

No era por cuestión software, era por temas de hardware.

ya, ya lo sé, me refería a exprimir las posibilidades del sistema tanto por hard como por soft.

un saludo

Pues necesitare gafas...pero por ejemplo no veo un gran salto grafico entre lo mostrado en el E3 del GoW y los videos actuales, eso si, si me hablas de suavidad, la cosa cambia....

Pues no se si sera cierta mi percepcion, pero creo k a nivel grafico va a ser la generacion donde veremos evolucionar menos los juegos. (dentro de la generacion, no respecto a la saliente)
No tengo ni idea, pero kreo k como stan hechas las consolas, tanto core/spe es mas para otras tareas k la graficas.
IA y fisicas se llevaran la palma (y eso es algo k los jugadores ocasionales kiza no valoren demasiado)

Killo donde encuentro los videos de GOW (no el de el E3). Solo he encontrado en xboxyde uno nuevo del TGS, pero es de tan mala calidad que no se ve un carajo.


un saludo

el video que han mostrado del TGS es de presentación, el TGS aún no ha comenzado así que de momento supongo que no hay video oficial del GoW del TGS aún..

un saludo

hombre algun truco, o como querais llamarlo habra que pillar, solo hay que ver halo, y halo 2 es la misma consola pero no es lo mismo...tecnicamente hablando.

salu2

shadow land escribió:XNA truco? XNA solo es una plataforma de programación. No necesita "pillarle el truco" o eres bueno o eres malo programando, pero no tiene "truco" que pillar.

Bueno, creo que es bastante evidente que nadie es bueno o malo... puede ser mejor o peor, pero algo determinante es las horas trabajadas.
Tengo amigos que no saben hacer la O con un canuto y a puro de programar son unos maquinas de cuidado.

Con el tiempo te haces mas productivo, aprendes a cargar menos el sistema y cosas que de primeras no haces. Eso es evidente

Bueno, saludos
Byes

Science escribió:
Bueno, creo que es bastante evidente que nadie es bueno o malo... puede ser mejor o peor, pero algo determinante es las horas trabajadas.
Tengo amigos que no saben hacer la O con un canuto y a puro de programar son unos maquinas de cuidado.

Con el tiempo te haces mas productivo, aprendes a cargar menos el sistema y cosas que de primeras no haces. Eso es evidente

Bueno, saludos
Byes

obviamente, pero hay cracks por naturaleza, y hay torpes por naturaleza, eches la horas que eches. Todoel mundo mejor, pero unos más que otros, me referia solo a eso.

Y segun tu ,Shadow ,que en programacion estas puesto....:

Como ves a dia de hoy la programacion para 360 ???? ( supongo que ya lo habras puesto en algun hilo ,pero weno era por aprovechar este..) en cuanto a facilidad ,potencia,versatilidad ,etc etc...

Salduso

satellite escribió:ahora va a resultar cierto aquella frase, pues han pasado unos cuantos meses y hay que ver que cambiazo han pegado todos, ha sido increíble.. no me quiero ni imaginar cuando empiecen a pillarle el "truco" al XNA, y al sistema completo, especialmente a la GPU.

Yo también creo que está perfectamente expresado lo que satellite quiere decir, no hay por qué intentar corregir esa expresión que condensa realmente lo que programadores [y diseñadores] tienen que hacer.
Llámale experiencia, llámale conocimiento,... pero el "truco" hay que pillárselo a cualquier plataforma nueva por muy buen programador que se sea.
Por ejemplo puede que encuentren una extensión que les permita hacer sombras arrojadas más facilmente que como lo venían haciendo, y hasta que lo han descubierto no se sabían "el truco".

De acuerdo que la GPU va a ser la auténtica caja de sorpresas de la 360. Yo estoy deseando que ATI saque algún producto parecido para el PC y poder así ver sus interioridades.

Y es lógico que se aumente la velocidad y/o la calidad con esos buses internos de alta cadencia, GPU de 48 ALUS (las que se enviaron orignalmente eran una cacota a su lado), tres cores con dos hilos por core,...

Saludos a la peña.

gejorsnake escribió:Y segun tu ,Shadow ,que en programacion estas puesto....:

Como ves a dia de hoy la programacion para 360 ???? ( supongo que ya lo habras puesto en algun hilo ,pero weno era por aprovechar este..) en cuanto a facilidad ,potencia,versatilidad ,etc etc...

Salduso

más "facil" que la cpu que ps3, pero más dificil que lo que esta acotumbrado la mayoria. Multinucleo requiere de tener mentalmente el control de lo que va pasando en cada core, y estar siempre sincronizado. Además, el hecho de que sean procesadores "in-order" hace que tengas que crear tu codigo de una forma determinada, ya que si no corre como el culo.

Pero supongo que es cuestión de tiempo, aunque los grandes engines ya estan todos optimizados (id desde quake 3, epic con unreal 3, crytek con el nuevo, etc, etc...)

Facil no es, pero imposible como dice el come-donuts de gabe newell, tampoco.

Umm, pues yo aqui veo una mejora increible !

shadow land escribió:
más "facil" que la cpu que ps3, pero más dificil que lo que esta acotumbrado la mayoria. Multinucleo requiere de tener mentalmente el control de lo que va pasando en cada core, y estar siempre sincronizado. Además, el hecho de que sean procesadores "in-order" hace que tengas que crear tu codigo de una forma determinada, ya que si no corre como el culo.

Desde el punto de vista de la programación lo que añade la máquina es un parelelismo a nivel de hardware, ya que la programación de múltiples hilos y múltiples procesos se lleva haciendo desde hace años. El hecho es que en los videojuegos se va a empezar a usar ahora masivamente, pero no hay nada nuevo bajo el sol.

El hecho de que sean procesadores "in-order" no es algo de lo que los programadores deban preocuparse, ya que no lo perciben a desde un lenguaje de alto nivel como C++. El procesamiento "in-order" requiere que EL COMPILADOR a la hora de generar código máquina minimice las interdependencias de datos.

Por otra parte en el procesamiento de videojuegos no afecta tanto la ejecución "out of order" como en el resto de aplicaciones informáticas, y por lo general es preferible aumentar la frecuencia del micro y prescindir de esa funcionalidad.

Saludos.

tu programa normalmente como para un out-of-order, y veras q bien se ejecuta tu codigo en un in-order.

Hay que seguir ciertas normas de programación, son basicas, pero logras que tu compilador sea mucho más eficiente.

Y todo eso en cristiano que significa ?????

out-of-order son un tipo de procesadores más orientados a la programación "general", o sea, impredecible por completo, es lo que tenemos en nuestros intel, amd, un g5 en mac... lo normal. Son capaces de reordenar las insutrcciones en tiempo de ejecución para maximizar el rendimiento.

in-order es casi lo contrario, son incapaces de reordenar las instrucciones, por tanto, dependes de dos factores, la calidad de tu compilador para ordenar correctamente las instrucciones, y tu "pericia" ordenado las instrucciones en tu programa. Para que el compilador tenga exito, tu debes ayudarle.

Si tu coges por ejemplo un juego de PC, y lo portas tal cual a Xbox 360 (suponiendo que ese PC y la consola fuesen IGUALES en todo), iria bastante peor en la xbox, que en el PC simplemente por el procesador.

shadow land escribió:tu programa normalmente como para un out-of-order, y veras q bien se ejecuta tu codigo en un in-order.

Hay que seguir ciertas normas de programación, son basicas, pero logras que tu compilador sea mucho más eficiente.

No es cuestión simplemente de responder una pregunta, sino que hay que responder sabiendo de lo que se habla.

Te vuelvo a repetir que no existe una programación en C++ in-order y otra out-of-order. Eso está a nivel de Código Máquina.

Si te crees lo que dices Shadow, ponnos un enlace donde se muestre código C++ optimizado para ejecución In-Order y luego la versión optimizada para ejecución Out-Of-Order y así nos iluminas con tus bastos conocimientos.

¿Y entonces qué ventajas ofrecen las cpu in-order frente a las out-of? ¿Quiza mas rendimiento de las primeras si se usan adecuadamente frente a las segundas?

Juaner escribió:¿Y entonces qué ventajas ofrecen las cpu in-order frente a las out-of? ¿Quiza mas rendimiento de las primeras si se usan adecuadamente frente a las segundas?

Las CPU in order se diseñan con el objetivo de alcanzar un alto rendimiento por cada vatio empleado, mientras que las out of orden pretenden conseguir un buen rendimiento por cada ciclo. Al simplificarse la circuitería interna se reduce el tamaño del layout y caben más micros en cada oblea de silicio, lo que abarata los costes, y simplifica el diseño.

Los PowerPC de la 360 y la PS3 se han simplificado para poder aumentar la frecuencia. Son una versión recortada de los PowerPC 970 a los que se les ha quitado otras muchas cosas como el buffer de predicción de saltos que se ha quedado tan reducido como en las primeras familias de PowerPC.

Todas las "chorraditas" orientadas a aumentar el rendimiento por cada ciclo transcurrido persiguen maximizar el aprovechamiento de las unidades funcionales internas de la CPU (sobre todo las ALUs). Pero son circuitos "muy" grandes y disipan mucho calor. Para alimentar con más trabajo a las ALUs de los micros in-order se metió el tema de "dos hilos de ejecución por cada core".

Es posible que la Revolution sí que use un out-of-order PPC 970, ya veremos.

Saludines.

Comprendido. Gracias por la explicación

humm no se que decir

nxname escribió:
humm no se que decir

Pues entonces di lo que todo el mundo. Qué bonito es el Kameo y que hortera es el peinado del prota del FCK (ese gran incomprendido de la next gen)

Juaner, no hay ventajas si se programa/compila correctamente para ambos, el detalle es que un nucleo "out-of-order" puede ser 2 veces más grande que el mismo en "in-order".

vidda escribió:
No es cuestión simplemente de responder una pregunta, sino que hay que responder sabiendo de lo que se habla.

Te vuelvo a repetir que no existe una programación en C++ in-order y otra out-of-order. Eso está a nivel de Código Máquina.

Si te crees lo que dices Shadow, ponnos un enlace donde se muestre código C++ optimizado para ejecución In-Order y luego la versión optimizada para ejecución Out-Of-Order y así nos iluminas con tus bastos conocimientos.

preguntale a deano C, o carmack a ver que te comentan.

No es que tengas que programar de una forma especial, simplemente no hay que abusar de ciertos abitos que obtenemos al trabajar en una plataforma "out-of-order" especialmente con el tema de bucles masivos y llamadas y saltos.

No es una programación especial, podríamos decir que simplemente es una programación más "organizada y directa".

Entiendo, por la explicación de vidda y tu aclaración posterior, que al ser mas pequeños y entrar más en cada oblea, simplemente son más aptos para consolas (de cara al que vende la consola) porque salen más baratos de fabricar y porque te permiten tener un diseño final del hard más reducido ¿no?

Juaner escribió:Entiendo, por la explicación de vidda y tu aclaración posterior, que al ser mas pequeños y entrar más en cada oblea, simplemente son más aptos para consolas (de cara al que vende la consola) porque salen más baratos de fabricar y porque te permiten tener un diseño final del hard más reducido ¿no?

si, a la vez, al tener menos "zonas" internas, es más facil elevarles la velocidad sin problemas reales.

shadow land escribió:Juaner, no hay ventajas si se programa/compila correctamente para ambos, el detalle es que un nucleo "out-of-order" puede ser 2 veces más grande que el mismo en "in-order".



preguntale a deano C, o carmack a ver que te comentan.

No es que tengas que programar de una forma especial, simplemente no hay que abusar de ciertos abitos que obtenemos al trabajar en una plataforma "out-of-order" especialmente con el tema de bucles masivos y llamadas y saltos.

No es una programación especial, podríamos decir que simplemente es una programación más "organizada y directa".

¿Es que Carmack te lo ha comentado a tí?, ¿O es que no te has enterado de lo que han dicho?

Como me estaba temiendo confundes la "predicción de saltos" con la "ejecución fuera de orden".

Es el BUFFER DE PREDICCIÓN DE SALTOS el que interviene en cuanto a rendimiento en lo relacionado a los bucles PROFUNDAMENTE ANIDADOS, las llamadas y los saltos CONDICIONALES. Es un sistema electrónico que determina por métodos estadísiticos si un salto condicional se tiene que realizar o no, con el simple análisis del pasado inmediato y el uso de técnicas heurísticas.

De hecho precisamente un micro Out Of Order sufre una penalización en términos de rendimiento mucho mayor que un In Order si se predice erróneamente una bifurcación condicional. Eso es debido a que se puede inutilizar una cantidad mucho más alta de instrucciones que se estaban procesando al vuelo.

Respecto a lo de una programación más "organizada y directa", es una cosa que se pretende siempre chavalote, independientemente de si la ejecución es in-order u out-of-order.

Salutaten.

soy de los que programa "organizada y directamente" siempre que puedo y tengo tiempo.

Carmack comento algo al respecto, y no tiene nada que ver con la predicción de saltos. Y DeanoC y otros tb lo han comentado, son abitos simples, pero que alguien no aciostumbrado a una plataforma in-order no suele poseerlos.

Cuando esta gente lo dice por foros varios, entre ellos B3D, será por algo "chavalote", yo por ahora me tengo que liminar a hacer programitas a medida para "amigos".

shadow land escribió:soy de los que programa "organizada y directamente" siempre que puedo y tengo tiempo.

Carmack comento algo al respecto, y no tiene nada que ver con la predicción de saltos. Y DeanoC y otros tb lo han comentado, son abitos simples, pero que alguien no aciostumbrado a una plataforma in-order no suele poseerlos.

Cuando esta gente lo dice por foros varios, entre ellos B3D, será por algo "chavalote", yo por ahora me tengo que liminar a hacer programitas a medida para "amigos".

¿Que Carmack comentó algo sobre que la programación in-order? Yo creo que no te has enterado de lo que ha dicho. Yo he leido prácticamente todo lo que se ha publicado sobre Carmack y no recuerdo nada de eso. Carmack ha comentado muchas cosas sobre las nuevas consolas, que si los cores, que si la nueva arquitectura, pero no va por ahí metiendo la gamba en esos temas tan de bajo nivel.

Mira Shadow, creo que no sabes de lo que hablas y no pretendo herir tus sentimientos, ni que nos enzarcemos en una discusión que no lleva a ningún sitio.

Aunque pienses que es nueva, la programación in-order se ha llevado haciendo muuuchos años con micros como: Los Intel 8086, 80286, 80386, i486, los motorola 68000, los AMD 29000, Zilog Z80, DR 6502,... y una larguísima lista. En los '90 se extendieron los out-of-order de una forma transparente para el programador de aplicaciones. Conseguían un aumento del rendimiento sobre el software heredado, por lo que no era necesario reprogramar nada.

Ahora se vuelve a ella por un mero intento de aumentar el rendimiento por cada vatio consumido.

No dudo que la gente diga cosas por los foros, otra cosa es malinterpretar lo que se dice o confundir conceptos.

No sé qué tiene que ver que hagas programitas a medida para amigos. Yo los hago para empresas, y programo en muchos sistemas distintos a nivel de sistema y de aplicación.

Saludos de nuevo.

vidda escribió:¿Que Carmack comentó algo sobre que la programación in-order? Yo creo que no te has enterado de lo que ha dicho. Yo he leido prácticamente todo lo que se ha publicado sobre Carmack y no recuerdo nada de eso. Carmack ha comentado muchas cosas sobre las nuevas consolas, que si los cores, que si la nueva arquitectura, pero no va por ahí metiendo la gamba en esos temas tan de bajo nivel.

Mira Shadow, creo que no sabes de lo que hablas y no pretendo herir tus sentimientos, ni que nos enzarcemos en una discusión que no lleva a ningún sitio.

Aunque pienses que es nueva, la programación in-order se ha llevado haciendo muuuchos años con micros como: Los Intel 8086, 80286, 80386, i486, los motorola 68000, los AMD 29000, Zilog Z80, DR 6502,... y una larguísima lista. En los '90 se extendieron los out-of-order de una forma transparente para el programador de aplicaciones. Conseguían un aumento del rendimiento sobre el software heredado, por lo que no era necesario reprogramar nada.

Ahora se vuelve a ella por un mero intento de aumentar el rendimiento por cada vatio consumido.

No dudo que la gente diga cosas por los foros, otra cosa es malinterpretar lo que se dice o confundir conceptos.

No sé qué tiene que ver que hagas programitas a medida para amigos. Yo los hago para empresas, y programo en muchos sistemas distintos a nivel de sistema y de aplicación.

Saludos de nuevo.

DeanoC y un programador de Ubi lo han comentado, deben de ser de los habitos más estupidos a la hora de programar, pero hay que tenerlos según parece para poder llegar al limite de la maquina. No me preguntes cuales son, pero cuando entre otros, lo dice uno de los principales programadores de Heavenly Sword (ninja theory, antes conocida como justa add monsters) y otros será por algo, digo yo. Y no malinterprete nada, es más, en estas cosas, normalmente intento directamente no interpretar para no cagarla.

Tu programas en varios SO's y a nivel de SO, enhorabuena, ya somos dos.

shadow land escribió:
DeanoC y un programador de Ubi lo han comentado, deben de ser de los habitos más estupidos a la hora de programar, pero hay que tenerlos según parece para poder llegar al limite de la maquina. No me preguntes cuales son, pero cuando entre otros, lo dice uno de los principales programadores de Heavenly Sword (ninja theory, antes conocida como justa add monsters) y otros será por algo, digo yo. Y no malinterprete nada, es más, en estas cosas, normalmente intento directamente no interpretar para no cagarla.

Tu programas en varios SO's y a nivel de SO, enhorabuena, ya somos dos.

Qué cansino el tío... bueno por lo menos ahora pones "hábitos" con hache, sólo te falta el acento y quedaría genial.

Pon enlaces y lo comentamos a partir de ellos, ya que tienes tantos datos que justifican que el in-order requiere un tipo de programación diferente. No me interesan tus argumentaciones que cada vez tienen menos credibilidad para mí. Y mira que he leido guías de programación para optimizar código C/C++, pero ninguna bajaba a ese nivel.

No confundas la dificultad que entraña programar un triple core RISC frente a programar un único Pentium, con in-order frente out-of-order, que son cosas distintas.

Si no interpretas nada ya sé cuál es tu fallo: intenta hacerlo pero con lógica y raciocinio. La buena interpretación de unos datos objetivos es fundamental para cualquier persona, máxime si es programador.

Y venga tío que ya me cansa tanta rayada.

vidda escribió:
Qué cansino el tío... bueno por lo menos ahora pones "hábitos" con hache, sólo te falta el acento y quedaría genial.

cansino tu, que quieres leer lo que no pone a todas horas, no solo en este hilo, si no en otros.

Y gracias por corregirme una de las pocas faltas que cometo por los foros, salvo que escriba a toda velocidad. Usted perdone por no pasar un corrector ortográfico antes de postear. Pero su usia debería de ocuparse de otros usuarios con peor vocabulario y uso del mismo antes que por mi persona, vulgar, ignorante y prescindible como ningúna, ¿verdad señor?

vidda escribió:Pon enlaces y lo comentamos a partir de ellos, ya que tienes tantos datos que justifican que el in-order requiere un tipo de programación diferente. No me interesan tus argumentaciones que cada vez tienen menos credibilidad para mí. Y mira que he leido guías de programación para optimizar código C/C++, pero ninguna bajaba a ese nivel.

claro, querras que nade en temas de más de 30 paginas en los foros de Beyond3D para darte el gusto a ti. Nos ha jodido, tengo mejores cosas que hacer que ir a buscar un dato enterrado en una base de datos desde hace dos meses.

vidda escribió:No confundas la dificultad que entraña programar un triple core RISC frente a programar un único Pentium, con in-order frente out-of-order, que son cosas distintas.

Si no interpretas nada ya sé cuál es tu fallo: intenta hacerlo pero con lógica y raciocinio. La buena interpretación de unos datos objetivos es fundamental para cualquier persona, máxime si es programador.

Y venga tío que ya me cansa tanta rayada.

Se lo que es programar multi-core, no lo he hecho ni una vez ni dos, me faltan dedos en el cuerpo para contarlas. Y por tanto, se que se refieren a HABITOS y formas, no a optimizaciones literales.

Tu piensa todo lo que quieras, pero te recomiendo que no uses tu codigo x86 en C++ "a pelo" en una consola de nuevo generación, quizas te lleves una sorpresa como se la han llevado bastantes estudios de programación (aún sobrando tiempo de proceso en un solo nucleo e hilo).

lo unico que se hace vidda es corregir conceptos asi por lo menos el que quiera informarse podra contrastar y no creerse todo lo que posteas que de vez en cuando sueltas unas perlas que ojo

Si lo dice camtrack...

Anda mejor dejarlo q cuando ya se discute algo q se sabe a ciencia cierta para cada parte lo unico q se consigue es picarse xq ninguno va a creerse na del otro. Por cierto yo escribo mal xq me apetece, si lo considerais oportuno me lo comentais y posteare lo más correcto posible

Saludos

aude7 escribió:Por cierto yo escribo mal xq me apetece, si lo considerais oportuno me lo comentais y posteare lo más correcto posible

Yo te recomiendo que lo hagas, pero no porque pueda molestar a alguien, sino por ti mismo, si sigues escribiendo mal a posta luego te pasará que cometerás muchas más faltas de ortografía sin darte cuenta. A mi me pasó y ahora procuro no ser tan vago tecleando

Cachondeo y alegría oigaaaaa...

shadow land escribió:Y gracias por corregirme

De nada hombre, para eso estamos.

shadow land escribió:una de las pocas faltas que cometo por los foros

[+risas][+risas][+risas][+risas]Estás de broma ¿No? [+risas][+risas] Tienes una autopercepción linguística demasiado elevada según parece. Una de las POCAS faltas dice el colega!!!

shadow land escribió:Usted perdone por no pasar un corrector ortográfico antes de postear.

A mí no me tienes que pedir perdón por esas cosas. Allá tú si necesitas un corrector ortográfico.

shadow land escribió:Pero su usia debería de ocuparse de otros usuarios con peor vocabulario y uso del mismo antes que por mi persona, vulgar, ignorante y prescindible como ningúna, ¿verdad señor?.

Verdad. Sobre todo si intentaran hacerse pasar por adalides del conocimiento y la sapiencia, dando argumentos sin fundamento.

shadow land escribió:claro, querras que nade en temas de más de 30 paginas en los foros de Beyond3D para darte el gusto a ti. Nos ha jodido, tengo mejores cosas que hacer que ir a buscar un dato enterrado en una base de datos desde hace dos meses.

Hombre... si no te importa quedar desautorizado no lo hagas, pero no querrás que me trague los embustes que dices sacar de no se sabe dónde exactamente.
Quien calla otorga. A mí nunca me ha dado pereza buscar referencias e información si son para demostrar una verdad concreta.

shadow land escribió:Se lo que es programar multi-core, no lo he hecho ni una vez ni dos, me faltan dedos en el cuerpo para contarlas. Y por tanto, se que se refieren a HABITOS y formas, no a optimizaciones literales.

En cuanto a programación de "multicores" o multiprocesamiento el problema se presenta por la sincronización y reparto de tareas más que otra cosa. Pero el problema de los multicores es al margen de ser In-Order, Out-Of-Order.

shadow land escribió:Tu piensa todo lo que quieras, pero te recomiendo que no uses tu codigo x86 en C++ "a pelo" en una consola de nuevo generación, quizas te lleves una sorpresa como se la han llevado bastantes estudios de programación (aún sobrando tiempo de proceso en un solo nucleo e hilo).

¿Y por qué iba a usar código x86 en una consola de nueva generación? ¿No te has enterado que usan la arquitectura PowerPC? Sólo podría ejecutarse por emulación!!! (vamos asumo que sabrás que un programa C++ no es código x86 hasta que se compila y transforma a código máquina).
La sorpresa que se pueda llevar cualquier estudio por compilar un programa PURO en C++ para un PowerPC a 3,2GHz respecto a haberlo compilado previamente en un x86 es por lo menos grata, ya que se consigue un rendimiento más que aceptable. Pero no sé qué tiene que ver esto con lo que se discutía.
Típico tuyo, cambias de tema como de camisa, ¿no serás comercial de alguna empresa? Tu perfil encajaría 100% (y no es coña).

joer.. y pensé que abrir el hilo para comentar la diferencia entre lo mostrado en el E3 y lo mostrado en el TGS.. el cómo se ha aprovechado los kits beta y finales.. y veo que hay disputas.. mal rollo

un saludo

OK tienes razón, ya me ha pasado en alguna ocasión y es un palo.

Vidda, yo no voy a decir si uno u otro tiene la razón, mayormente porque yo de eso no tengo la menor idea, lo que no quita que no te pueda decir que por mostrar una actitud más agresiva y despectiva vas a tener mayor poder de convicción o más razón en tus afirmaciones...

Saludos

Vidda,y si probases a decir lo mismo, pero sin ir de sobrado, o intentar dejar de ignorantes a los demás?
En vez de decir lo que dices está mal, no tienes ni puta idea...quetal si dices, esto esta mal, esto es lo correcto? Así la discusión será productiva, y algunos igual aprendemos algo.
Pequeña sugerencia, sin mas, igual así todo resulta más agradable para todos...

Pregunta, a 17 centimso de uero por respuesta correcta. Se puede utilizar el mismo compilador, pongamos c++, para un x86 in ordery para un x86 out of order? Cual sería la diferencia en rendimiento y porque?( a igualdad de ciclos de reloj). Ambops tienen branch predictor, donde esta la penalización?

satellite escribió:joer.. y pensé que abrir el hilo para comentar la diferencia entre lo mostrado en el E3 y lo mostrado en el TGS.. el cómo se ha aprovechado los kits beta y finales.. y veo que hay disputas.. mal rollo

un saludo

Pues tienes razón. Lo siento por mi parte que comprendo que esto ralla mucho.
Respecto a lo de actitud despectiva... no creo que Shadow land tenga fama de ser una hermanita de la caridad, que bien que las tira. Pero vamos, por mí lo dejamos por zanjado que hay muchas cosas más interesantes que hacer.

vidda escribió:Cachondeo y alegría oigaaaaa...

De nada hombre, para eso estamos.

[+risas][+risas][+risas][+risas]Estás de broma ¿No? [+risas][+risas] Tienes una autopercepción linguística demasiado elevada según parece. Una de las POCAS faltas dice el colega!!!

A mí no me tienes que pedir perdón por esas cosas. Allá tú si necesitas un corrector ortográfico.
Verdad. Sobre todo si intentaran hacerse pasar por adalides del conocimiento y la sapiencia, dando argumentos sin fundamento.

ni soy un cerebro, ni me las doy de tal, pero alguien que ha quedado ya varias veces en evidencia en estos foros con otros temas, me quiera desacreditar "por que si", y sobre todo pasar por encima los comentarios de gente que COME de programar para la nueva generación, tiene cojones la historia.

vidda escribió:Hombre... si no te importa quedar desautorizado no lo hagas, pero no querrás que me trague los embustes que dices sacar de no se sabe dónde exactamente.
Quien calla otorga. A mí nunca me ha dado pereza buscar referencias e información si son para demostrar una verdad concreta.

deberias ser tu el que deberia demostrar lo contrario, o tu tb quedaras desacreditado... por que, cuales son tus fuentes? a si, supongo que las tipicas guias de programación en C, verdad? esas que nos hemos repasado casi todos los que nos dedicamos a esto a mayor o menos nivel.

vidda escribió:En cuanto a programación de "multicores" o multiprocesamiento el problema se presenta por la sincronización y reparto de tareas más que otra cosa. Pero el problema de los multicores es al margen de ser In-Order, Out-Of-Order.

el problema es que no he hablado de la relación entre lo uno, y lo otro, mientras que tu lo metes en el ajo constantemente.

vidda escribió:¿Y por qué iba a usar código x86 en una consola de nueva generación? ¿No te has enterado que usan la arquitectura PowerPC? Sólo podría ejecutarse por emulación!!! (vamos asumo que sabrás que un programa C++ no es código x86 hasta que se compila y transforma a código máquina).
La sorpresa que se pueda llevar cualquier estudio por compilar un programa PURO en C++ para un PowerPC a 3,2GHz respecto a haberlo compilado previamente en un x86 es por lo menos grata, ya que se consigue un rendimiento más que aceptable. Pero no sé qué tiene que ver esto con lo que se discutía.
Típico tuyo, cambias de tema como de camisa, ¿no serás comercial de alguna empresa? Tu perfil encajaría 100% (y no es coña).

por que como bien sabes, el codigo ESTANDAR c++ es posible portarlo a cualquier plataforma independientemente de su cpu y su arquitectura mientras exista un compilador para la misma, verdad? Y cuando digo "codigo x86" me refiero a un codigo realizado originalmente pensando en PC, no ensamblador puro o el objeto. Si no el programa sin tocar.

Pues lo dicho, no uses ese codigo "a pelo" o te llevaras una desagradable sorpresa. (como Monolith entre otros estudios) Es una de las razones por las que el amigo Steve Jobs rechazo a Sony la posibilidad de usar CELL en sus Apple (ya sabes, core G5 e in-order), y no precisamente por el echo de que el codigo anterior fuese "peor", si no que aún con compiladores, el nuevo seguia siendo peor para tarea general no especifica.

venga dejarlo ya q esto no lleva a ningun lao, yo creo q las diferencias entre out-of-order e in-order las va a cubrir el compilador no creo para nada q el programador tenga q preocuparse por nada, q ya bastante complicao va a ser tener en cuenta sincronizaciones y exclusiones mutuas de los multicores.
Igual me equivoco pero no creo q hagan a los programadores bajar a tan bajo nivel cm para preocuparse por optimizar eso. Aunq igual tiene razon shadow y con solo un par de consejos ya ta todo arreglao.

Por cierto criticar mi ortografia si qreis q no me voy a preocupar p eso y asi a lo mejor os relajais, jeje.

filetefrito escribió:Pregunta, a 17 centimso de uero por respuesta correcta. Se puede utilizar el mismo compilador, pongamos c++, para un x86 in ordery para un x86 out of order? Cual sería la diferencia en rendimiento y porque?( a igualdad de ciclos de reloj). Ambops tienen branch predictor, donde esta la penalización?

no puedes o no debes, entiendelo como quieras.

La diferencia más brutal se encontrara a la hora de tratar condicionales, saltos y cosas del estilo. Y la diferencia de rendimiente especialmente in-order, de un programa mal compilado, y uno bien compilado, puede ser bastante animal.

Hola de nuevo.
Gracias a la "magia" de los mensajes privados el tema este tan rallante lo hemos zanjado gratamente Shadow land y yo. Espero que esto sea el principio de una "hermosa amistad", jeje
No quería sacar más mensajes hasta que se hubiera resuelto.

Para los pocos que aún les pudiera interesar el tema ahí va mi respuesta para lo de filetefrito. Considerad que es una respuesta alternativa.

filetefrito escribió:Pregunta, a 17 centimso de uero por respuesta correcta. Se puede utilizar el mismo compilador, pongamos c++, para un x86 in ordery para un x86 out of order? Cual sería la diferencia en rendimiento y porque?( a igualdad de ciclos de reloj). Ambops tienen branch predictor, donde esta la penalización?

En cualquiera de los dos casos puedes hacerlo y de hecho se hace habitualmente.


El concepto de ejecución fuera de orden nace con la filosofía RISC (superescalaridad y segmentación) para evitar las etapas "stall" que dejan sin procesamiento a todo un pipe interno del micro, mientras que la ejecución en orden es típica de la tecnología CISC clásica con un procesamiento sencillo secuencial. Esto no exime para que un micro CISC pueda ser superescalar (como el primer Pentium), ni que un micro RISC pueda ser de ejecución in-order (como los PPC de la XBOX 360 y la PS3, y los RISC de los '80 y alguno de principios de los '90).

Puedes usar el mismo compilador desde dos perspectivas distintas:

Los compiladores antiguos se diseñaron sin tener en cuenta ejecución fuera de orden. Cuando se sacaron los modernos micros fuera de orden (el Pentium Pro en Intel) debían ejecutar código compilado antiguo, de tal forma que idearon lo que se llama el "renombramiento de registros", y la "ejecución especulativa" en las que ahora no me entretendré. El objetivo era eliminar las interdepencias típicas del código antiguo in-order. Para eso se permite tener muchas instrucciones ejecutándose al vuelo usando registros internos ficticios u ocultos desde la perspectiva del programador, lo que le da tiempo para que esas interdependencias se resuelvan, al permitir que las instrucciones independientes se "cuelen" en el pipe de ejecución. Por esto se aumenta la velocidad al tener más unidades funcionales en procesamiento simultáneamente.
A este respecto de interdependencias de código recuerdo un artículo curioso de los diseñadores del antíguo compilador optimizador Watcom C++, que decían que al evitar las interdependencias para ejecutar código en los pipes U y V del Pentium habían conseguido igualmente mayor velocidad de ejecución en el i486, y estaban molestos con Intel por no habérselo dicho antes.

Los compiladores modernos se han diseñado para que reordenen las instrucciones de tal forma que tienden a alejar en el código las instrucciones que dependen unas de otras. El quitarle carga a un micro para que en tiempo de ejecución tenga que resolver las interdependencias redunda en un mayor rendimiento, y un menor sobrecalentamiento. Si se aplica a un micro antiguo CISC no se obtiene demasiadas ventajas porque ya de por sí no es superescalar (no tiene varias unidades de ejcución en paralelo), sino que es secuencial. Si es un micro RISC in order, permitirá que se llenen convenientemente sus unidades de ejecución por tanto procesará más rápido al simplificar la etapa de "despacho" interna encargada de realizar el reparto de carga "al vuelo".
Según la tecnología de compiladores ha ido avanzando, son menos frecuentes tantas interdependencias que resolver en tiempo de ejecución, y la circuitería out-of-order ha ido perdiendo relevancia.

Como comenté antes, lo que ahora interesa es aumentar el rendimiento por cada vatio consumido, aunque caiga respecto a otro micro si se igualasen las frecuecias.
Un ejemplo ilustrativo aunque no muy bueno, fue el cambio de los Pentium III a los Pentium IV. El P-IV tenía un rendimiento por ciclo pésimo comparado con los P-III, sin embargo su circuitería se diseñó para poder llegar a frecuencias muy elevadas. Así pudimos ver cómo el P-IV llegó a los 3GHz sin problemas. Otras casas como AMD tuvieron que recurrir de nuevo al famoso "Pentium rate", ya que su frecuencia real era notablemente menor. Los últimos avances de Intel, IBM, etc. van por ese camino: conseguir un rendimiento aceptable a potencias disipadas "bajas", aunque para eso tengan que recurrir a desprenderse de esas joyas del diseño como son las circuiterías out-of-order.

PD: Soy consciente de que el texto es un poco "cargante", I'm sorry