CPU vs. GPU

[fjavi]

@Bm4n:

@__wwwendigo__ Entonces tenemos la misma opinión, no se que estamos discutiendo. Lo único que no he dicho es que sea algo sencillo, sino todos lo harían, pero el tema es ese que es realmente necesario que los juegos optimicen los recursos actuales. Mis opiniones creo que quedan muy claras, pero vamos si quieres que aclare más solo pregunta

@__fjavi__ yo la primera vez que vi lo del microstutter era con el tema de multiples gráficas, que parece que tenían problema en la división del trabajo y también se había visto que aunque mostraban por ej. 60FPS realmente en pantalla se mostraban muchas menos. Pero se ve que en ciertos juegos aun con configuraciones simples tienen reiteradamente lags a la hora de mostrar frames. Y luego están los bajones de FPS de toda la vida.

Es muy posible que con graficas de doble GPU o varias gráficas tengas problemas si no usas un buen CPU, eso no te lo niego, pero en general siempre habrá menos carga para los gráficos a menor resolución.

Si el MS se da mas con SLi o CF pero también se da algún caso con monogpu,suele ser donde el CPU es mas importante por ejemplo yo he visto con una 9800GTx pero muy oceada en 3dmark06,era por que lo pasa a baja resulucion y es un test muy dependiente de CPU,tambien es verdad que las monogpu piden menos equipo que un SLi o CF o una dual,pero también influye la potencia de la monogpu.

Yo se que un SB no tiene casi nada que envidiar ni a un SB-E ni a un Ivy y menos en monogpu, pero si se junta un procesador que no se puede subir y una resolución tan baja, podria tener algún problema con algún juego, sobretodo los que sean muy dependientes de CPU.

[Bm4n]

@__Wargreymon__ no estoy hablando de nada que no exista, simplemente que con el tiempo se explotará mejor lo que ya hay, la mejor formula quien sabe. Pero estoy seguro que a corto plazo (5 años) seguiremos añadiendo núcleos porque la mejora de potencia bruta por ciclo va a seguir avanzando como siempre. Incluso parece a veces más rentable tener varios núcleos más simples o con menos ALU/FPU que uno con muchas, sobre todo para tareas simples, a quien el importa que te tarde 1" menos en descomprimir un ZIP si el procesador te cuesta un 50% más (por exagerar el tema).

@__fjavi__ a mi me llamo la atención aquel enlace que puse de un tio que con el skyrim?, al asociar el juego a un solo núcleo le bajo muchisimo el m.s. con una 7950 y un 2500.

[Wargreymon]

@Bm4n:

@__Wargreymon__ no estoy hablando de nada que no exista, simplemente que con el tiempo se explotará mejor lo que ya hay, la mejor formula quien sabe. Pero estoy seguro que a corto plazo (5 años) seguiremos añadiendo núcleos porque la mejora de potencia bruta por ciclo va a seguir avanzando como siempre. Incluso parece a veces más rentable tener varios núcleos más simples o con menos ALU/FPU que uno con muchas, sobre todo para tareas simples, a quien el importa que te tarde 1" menos en descomprimir un ZIP si el procesador te cuesta un 50% más (por exagerar el tema).

Eso está claro, llegará el día en que Intel nos saque 6/8 núcleos en el segmento performance, pero no estoy de acuerdo en que sea más rentable tener núcleos más simples pero en mayor cantidad sobre núcleos más potentes y en menor cantidad, la mejor apuesta sigue siendo el mayor rendimiento por ciclo posible, y después de eso ya el número de núcleos (Salvo que hablemos de diferencias muy pequeñas en cuanto a ipc entre una CPU de 2 núcleos y otra de 4 claro).

Lo que hace el CryEngine 3 en el Crysis 3 con la CPU por ejemplo es muy interesante por que parece ser capaz de emplear todos los hilos que tenga una CPU (Creo que el tope son 12 hilos) para evitar cosas como las que ocurren en el Tomb Raider o en el crysis original que también tenía (Y tiene) ese problema de dependencia de CPU siendo capaz de usar pocos núcleos, así que acaba saturandolos y limitan el rendimiento.

[Bm4n]

Parece que será AMD quien acabe sacando más núcleos, a Intel aun no le hace falta :troll:

Un buen ejemplo son los ARM que no me estañaría que acabasen saltando al mundo de los portátiles, los X86 actuales son bastante complicados e innecesarios para muchas tareas ligeras, lo ideal es un buen equilibrio entre IPC y paralelismo. Con un soft bien preparado sería como pensar hoy en comprar un mono núcleo sin HT, por muy potente que sea, no sería una buena idea.

[Wargreymon]

@Bm4n:

Parece que será AMD quien acabe sacando más núcleos, a Intel aun no le hace falta :troll:

Un buen ejemplo son los ARM que no me estañaría que acabasen saltando al mundo de los portátiles, los X86 actuales son bastante complicados e innecesarios para muchas tareas ligeras, lo ideal es un buen equilibrio entre IPC y paralelismo. Con un soft bien preparado sería como pensar hoy en comprar un mono núcleo sin HT, por muy potente que sea, no sería una buena idea.

¿ARM más fácil que x86?, si existe desde los años 70, arquitectura más conocida y familiar que esta dificil…

De poco sirve que las CPUs de AMD tengan más núcleos si incluso con todos en uso, como mucho, igualan a un i7 de la competencia, y con pocos hilos directamente la competencia los humilla.

Sinceramente, me extrañaría bastante que AMD sacara CPUs con más de 8 núcleos a corto plazo, sacar un Bulldozer con 10 o 12 núcleos no les iba a servir para nada más que hacer chips más caros y con el mismo rendimiento. Viendo los cambios que están haciendo en steamroller, que afortunadamente son cambios hacia adelante salvo fracaso de última hora, más bien se están centrando en tratar las debilidades de la arquitectura en lugar de en mantenerla y seguir metiendo núcleos a lo bestia.

[Bm4n]

ARM es una arquitectura más simple y el x86 de hoy en poco se parece al de hace 40 años. Poner o quitar núcleos no tiene ningún gasto de I+D es mas o menos gratuito; si no puedes vender uno de 4 núcleos porque tiene muy bajo rendimiento vende uno de 8 y más barato, es lo que llevan haciendo bastante tiempo. E Intel no saca procesadores de 8 núcleos porque "no quiere", no le interesa explotar el mercado aun.

[Fassou]

Hace tiempo se rumoreaba sobre la presencia de procesadores ARM en las futuras gráficas de AMD :sisi:

Si no lo hacen ellos mísmos, no descarteis que algún fabricante como TUL (PowerColor) lo haga.

Salu2!

[wwwendigo]

@Bm4n:

ARM es una arquitectura más simple y el x86 de hoy en poco se parece al de hace 40 años. Poner o quitar núcleos no tiene ningún gasto de I+D es mas o menos gratuito; si no puedes vender uno de 4 núcleos porque tiene muy bajo rendimiento vende uno de 8 y más barato, es lo que llevan haciendo bastante tiempo. E Intel no saca procesadores de 8 núcleos porque "no quiere", no le interesa explotar el mercado aun.

Lo dices como si supusiera alguna "ventaja" el salto a ARM, y te voy a decir una cosa, arquitecturas RISC de primerísima calidad han caído ante x86 no sólo por razones de coste, sino también de rendimiento. Ni tampoco ARM es el mejor ejemplo de arquitectura "RISC simple", porque no lo es. Por no tener ni tiene un tamaño de instrucción fijo y estable, como sí lo tienen otras arquitecturas RISC más prototípicas (precisamente ARM imita en ciertos aspectos las cpus CISC por temas de consumo de memoria).

El 99% de los programadores lo hacen o con lenguajes de alto nivel o como mucho en C, por lo que realmente les da igual casi la arquitectura que tenga por debajo la cpu. Y si programas algo en ensamblador, sólo son secciones limitadas de código, normalmente para realizar bucles de cálculos intensivos, que te da igual hacerlos con una que con otra arquitectura.

La calidad de los compiladores x86 no tiene equivalente en otras arquitecturas, tras tantos años y gente trabajando en esto, no hay ni una sóla razón para preferir ARM o cualquier otra cpu RISC por la mayor "bondad" (que no) de arquitecturas no x86 (fuera de la orientación hacia el consumo de ARM).

Al único que le insteresaría no usar x86 sería quizás a programadores de sistemas operativos y similares, que ya tienen que bregar con más problemas de la arquitectura. Y aún así, con peros.

Sobre 4 u 8 cores y la "conveniencia" de la última senda, los dos ejemplares que se han citado:

Piledriver 8C: 315 mm2 de die y 1,2 mil millones de transistores (32nm).
Ivy Bridge 4C: 160 mm2 de die y 1,4 mil millones de transistores (22 nm).
Sandy Bridge 4C: 210 mm2 de die y 1,16 mil millones de transistores (32 nm).

He puesto los dos últimos intel porque uno está fabricado en 22 nm, y para poner como contraste una cpu que no sólo es competitiva igualmente contra Piledriver (más que eso, realmente), sino que está fabricado en un nodo de fabricación "similar".

AMD sólo en soft multihilo masivo, que no use demasiado la coma flotante, consigue igualar los resultados de los dos intel aquí colocados, pero eso sí, a costa también de consumos y frecuencias más altas para lograrlo (así que estrictamente hablando, no consigue ni con el número de cores compensar su bajo IPC, necesita además frecuencia extra contra los intel).

Fuera del soft masivamente multihilo mencionado, que se adapta bien a este tipo de cpu, el rendimiento de Piledriver es de mediocre a malo comparativamente hablando.

Ahora, ¿ha conseguido AMD duplicando cores mejorar el rendimiento máximo de x86? NO, todo lo contrario, tiene que recurrir a disparar su TDP y frecuencias para igualar la balanza.

¿Ha conseguido AMD implementar más cores por tamaño de die que su rival intel? Tampoco, además del impresionante tamaño del Piledriver (más de 300mm2, como una gpu de gama media-alta actual, bastante lejos de lo típico en cpus de gama media), hay que tener en cuenta otros factores:

En AMD te venden sólo la cpu con Piledriver, intel vende en la misma pastilla su gpu, que por lo menos en Ivy ocupa más de 1/3 de la die final, y algo menos en Sandy (¿1/4?), si a intel le diera por ahí en ese mismo espacio que ocupa la gpu podría agregar un par de cores extra más la expansión de la L3 consecuente. Casi lo mismo o con poco o nulo crecimiento del área necesaria en Sandy.

Sandy sin GPU con sus 4 cores ocuparía más o menos 150 mm2, con lo cual AMD con toda esa cirugía "reductora" de capacidades de cada uno de sus cores, compartiendo recursos, teniendo que meter cachés enormes para compensar errores de diseño (el mismo tipo de cachés en sí), y otros dimes y diretes, no habría conseguido realmente reducir el consumo de área por core respecto a su rival con su arquitectura "bulldozer".

Esto es, ofrece un mucho peor IPC, necesita meter 8 cores para rivalizar con un 4 cores en soft multihilo, gasta una die que duplica el gasto en cores del rival, y dado que aún así no le llega con su diseño para vencer al rival necesita compensar subiendo frecuencias y consumos.

Lo que la mayoría de la gente NO sabe sobre Bulldozer y derivados es que se supone que es un cpu "Speed Demon", una cpu cuyo diseño se simplifica y de hecho se vuelve menos eficiente apostando por cambios que le permitiría alcanzar frecuencias de reloj mucho más altas. Bulldozer tenía que salir a unos 5 GHz o así se esperaba inicialmente, para compensar y ofrecer un "plus" respecto al rival. O sea, que esta cpu tendría que poder funcionar con OC con rangos de 6 GHz con relativa facilidad y por aire.

Pero AMD se ha metido exactamente el mismo batacazo que se dió intel con el Pentium4 cuando "descubrió" (algo ya sabría, detrás del p4 yo ví mucho dpto. de marketing satisfecho con números de frecuencia) que a pesar de que el diseño puede subir de frecuencias, no lo hace sin disparar los consumos y sin volverse en impracticable para montar en PCs ordinarios (con como mucho RL como método de disipación).

Lo cual es especialmente penoso teniendo como tenía el ejemplo en el rival de qué no hacer. Pero nada, a simplificar, empaquetar muchos cores ineficientes, y meter mucha frecuencia para compensar sus errores de diseño.

Los únicos contentos serían otra vez los chicos de marketing que pueden "presumir" en sus folletos de 8 cores y de más de 4 GHz, la publicidad cojonuda para promocionar al más puro estilo Mediamarkt, "yo no soy tonto".

MORALEJA:

Si quieres una buena cpu generalista apuesta por un equilibrio, no vayas a por apuestas sin sentido de un fabricante que parece haber tomado esa mala decisión sólo porque no se veía capaz de responder con Phenom a arquitecturas tan como Core. La mala decisión de intel con el P4 también fue alimentada por su derrota en la carrera del GHz contra el Athlon usando su Pentium III.

Que cosas de la vida, resulta que es el "padre" de toda la gama actual de cpus x86 de intel (excepto Atom). Y nunca desprecies un buen IPC, porque simplemente hay tipos de soft que no se adaptan ni de broma bien a ejecución multihilo y eficiente.

Fassou:

¿Ese "rumor" no será más bien con las gráficas de nvidia? porque ahí sí está más o menos confirmado que se implementará algún sistema híbrido gpu-cpu por su parte.

[koramaii]

¡Esta publicación está eliminada!

[Bm4n]

El problema wwwendigo es que tu hablas desde el punto de vista de un programador, pero a nivel técnico si es más simple un ARM, no quiero decir con ello que esto no se pueda hacer con un x86 buen ejemplo es Clover Trail aunque ya ves que no ha supuesto nada grande en ese mundillo pese a funcionar a más velocidad que el resto. El tema es que Intel no parece hacer nada bueno cuando lo sacas de lo suyo, por ejemplo los netbooks, prefiero mil veces los Fusión que los Atom por la sencilla razón de que sus gráficas apestan y eso lastra mucho su rendimiento global. A lo que voy con esto es a que es en esos campos donde mejor se le puede hacer competencia, por eso me gustan las ideas alternativas a lo que ya hay.

Yo no digo que la arquitectura actual de AMD sea buena, fui el primero en decir aquí algo no cuadra, pero de todas formas me parece interesante. Ya se que algunos sois muy prodeloquesea, en este caso de Intel, y yo no me considero patrocinado y me gusta considerar cualquier alternativa, y hablo de competencia porque si no tuviésemos solo dos grandes habría más competencia y mejores precios.

Y no te excites que yo sepa ninguno trabajamos para el MM, pero hoy (y de cara al futuro, que hasta hace poco no pasaba) cualquier programa/juego que esté bien programado aprovechara el paralelismo y mejorará con un procesador de más núcleos, no tiene sentido defender que "solo" 4 núcleos va a ser mejor por temas de consumos o calor eso hoy por hoy no es ningún problema; otra cosa es que no se necesite. Sacrificar el FPU como hizo AMD era visto que no iba a rendir mejor, pero aun así no deja de ser sorprendente que teniendo esa carencia y un IPC el doble de lento que los actuales Intel logre rendir en ciertas tareas tan bien o mejor; por eso digo que si AMD hubiese mejorado ambas cosas estaríamos ante procesadores bastante superiores.

PD. Hablando de malas decisiones, yo en su día compre P4 sin ser la mejor opción y resultó que la tontería del HT proporcionaba un desahogo importante y nunca noté que me faltase CPU hasta que lo cambié bastantes años después. Con esto te quiero decir que a veces la obsesión con las cifras tampoco se traduce en algo tangible, que no recomendaría un AMD es cierto pero quien haya comprado un FX-8 tampoco creo que vaya a estar maldiciendo su compra.

[Fassou]

AMD tiene licencia ARM, y trabaja en procesadores ARM para servidores para compensar su inferioridad con Intel, pero se dá por segura su inclusión en las nuevas APU, lo que nos daría un maravilloso pack (CPU+GPU+ARM).

Los de nVIDIA, están más en la línea de meter procesadores ARM, como ayuda a su línea Tegra.

Salu2!

Fuentes : AMD, Anandtech y Fudzilla

[Bm4n]

@Fassou:

AMD tiene licencia ARM, y trabaja en procesadores ARM para servidores para compensar su inferioridad con Intel, pero se dá por segura su inclusión en las nuevas APU, lo que nos daría un maravilloso pack (CPU+GPU+ARM).

Los de nVIDIA, están más en la línea de meter procesadores ARM, como ayuda a su línea Tegra.

Salu2!

Fuentes : AMD, Anandtech y Fudzilla

Un CPU híbrido de ese estilo sería muy interesante si señor, se especuló con el tema ahí atrás sí. Y la introducción de los ARM en los servidores ya es un hecho, con el tiempo veremos si es o no un éxito, recuerdo la noticia de Calxeda que fue muy interesante.

[wwwendigo]

@Fassou:

AMD tiene licencia ARM, y trabaja en procesadores ARM para servidores para compensar su inferioridad con Intel, pero se dá por segura su inclusión en las nuevas APU, lo que nos daría un maravilloso pack (CPU+GPU+ARM).

Los de nVIDIA, están más en la línea de meter procesadores ARM, como ayuda a su línea Tegra.

Salu2!

Fuentes : AMD, Anandtech y Fudzilla

Bueno, yo he visto varias noticias donde se pretendía hacer fusión entre gpu y cpu en ambos sentidos por parte de nvidia, no sólo lo que vemos con Tegra:

http://www.xbitlabs.com/news/mobile/display/20130320235000_Nvidia_Reveals_Kayla_Platform_for_Developers_of_GPU_Accelerated_ARM_Applications.html

http://www.tomshardware.com/news/nvidia-armv8-soc-gpu,18838.html

http://www.xbitlabs.com/news/cpu/display/20121108215621_Nvidia_Denver_Is_Custom_ARMv8_64_Bit_Processor_with_Secret_Sauce.html

No es fácil de encontrar la información exacta, pero nvidia parece estar creando tanto cpus con gpus integradas con capacidad gpgpu (tegra 5, con gpu kepler), sistemas integrados de SoCs actuales Tegra con una gpu Kepler como coprocesador, y a la vez desarrolla el proyecto Denver que parece que será una cpu ARM encauzada totalmente al mundo de servidores y bastante potente.

Lleva tiempo rumoreándose que los futuros productos Tesla de la casa integrarán algunos núcleos ARM para flexibilizar las capacidades de estas tarjetas ante tareas que no se llevan especialmente bien con las GPUs. O sea, que parece estar metiéndose en todos los frentes posibles con ARM.

@Bm4n:

El problema wwwendigo es que tu hablas desde el punto de vista de un programador, pero a nivel técnico si es más simple un ARM

Y mucho más lento. No sólo lo digo todo desde el punto de programador. La sobrecarga heredada por la etapa de decodificación de x86 a un código interno "RISC" es algo ya viejo en las cpus x86 (desde el K5, el Pentium pro, y la primera cpu en usar este sistema, la nexgen 586), pero cuanto más complejo se vuelven las cpus, menor coste tiene esta sobrecarga heredada, ya que lo que antes era un desperdicio en transistores importante, ahora mismo es casi irrelevante, y de hecho puede suponer cierta ventaja (mayor empaquetamiento del código y por tanto más instrucciones "RISC" internas contenidas por línea cargada de la caché de instrucciones, la tasa de instrucciones internas decodificadas puede ser mucho mayor que las instrucciones x86 que entran en la fase de decodificación).

ARM es más "simple" porque está orientado a un mercado distinto, un Cortex A15 ya empieza a no ser tan "simple", y aún menos lo parecerán los Cortex A50 de 64 bits para servidores cuando empiecen a verse por ahí.

No hay que olvidar que los Cortex A9 y anteriores se han enfrentado en el mercado real contra los Atoms orientados a tablets/smartphones, y no han salido en absoluto favorecidos en la comparación en cuanto a rendimiento, sobre todo core a core o en IPC. Lo cual puede parecer sorprendente siendo como son los Atoms bastante "lentos" como cpus x86, algo que yo interpreto como un problema del sistema de cachés y acceso a memoria lastrado por diseños de bajo consumo (para los ARM), pero bueno, lo dicho:

Antes de Cortex A15 los diseños de ARM son todo lo simple que quieras decir, pero son bastante más lentos (aunque un SoC basado Cortex A8/A9 sea una cpu muy decente para ciertas tareas ofimáticas y de consumo) que los x86 más lentos. Aunque tienen la ventaja de un consumo ridículo.

Cuando ha llegado el A15 se ha visto que supera ya sin paliativos al Atom (ya era hora, era lo que yo me esperaba incluso del A9), pero ya no es una cpu "tan simple" porque sus consumos son ya muy elevados para lo que nos tienen acostumbrados ARM. De hecho consume más que Atom para realizar una tarea dada.

Así resulta que los ARM no son tan "simples" en lo que cuenta cuando se ponen serios (un Cortex A15 es una cpu con un gasto importante de transistores y consumo), y si queremos el mismo nivel de rendimiento que un Conroe o algo adel estilo, posiblemente esto se iguale mucho más.

Lo cierto es que hay muchas arquitecturas que se han enfrentado a x86 en rendimiento/consumo o "complejidad", y no han salido especialmente bien paradas (el I+D de intel más su capacidad de fabricación en procesos punteros es difícil de batir), hemos vistos PowerPCs, cpus MIPS, intentarlo y fallar (p.ej. el paso de cpus powerpc a x86 en Apple).

Esto no quiere decir que no sean alternativas interesantes todas las mencionadas, de hecho soy un entusiasta de los resultados de ARM con sus productos via terceros, pero esto no quiere decir que x86 sea fácil de sustituir por criterios de "simpleza". Cuando quieres competir de tú a tú no queda más remedio que volverse complejo, y en ese nivel de rendimiento el peso de las herencias recibidas de x86 pasa a ser casi irrelevante, importando más el diseño interno de cada arquitectura y otros puntos.

[Bm4n]

Cierto, no es comparable un A8 a un A15, no es tan "RISC" ademas parece que Krait mejora sus consumos. Pero frente al Atom parece tener ventajas muy probablemente sobre todo por precio/rendimiento. X86 con las instrucciones actuales es el rey en procesadores generalistas de alto rendimiento, sin lugar a dudas, pero son muy caros sobre todo cuando nos vamos a LV, ULV, Atom. Ahora mismo Intel fabrica lo mismo para todo, monta GPUs en los sobremesa, en los Clover Trail usa el HT, en los futuros Bay Trail montará las gráficas que salgan de los Ivy… Vamos que es un despropósito, no han hecho algo nuevo desde hace mucho todo ha salido del camino que comenzaron con los Pentium M y los GMA. Lógico que los fabricantes prefieran un ARM que por lo menos se ha hecho más a medida y seguro que es más barato.

Que ventajas tiene el tener más núcleos, sin lugar a dudas, quizás hasta sea más económico montar dos núcleos más baratos en IPC que uno mas caro. Pero hasta que sea la gran mayoría del soft que lo aproveche no lo descubriremos. Y con respecto a los juegos creo que también es aplicable, aunque es muy raro que un juego demande lo "tope" en cuanto a CPU a menos que sea con una configuración extrema o por mala optimización, mientras que en el GPU los juegos siempre suelen tragar todo lo que hay; quizás en el futuro acaben repartiendo más carga al CPU.

[wwwendigo]

@Bm4n:

Cierto, no es comparable un A8 a un A15, no es tan "RISC" ademas parece que Krait mejora sus consumos. Pero frente al Atom parece tener ventajas muy probablemente sobre todo por precio/rendimiento. X86 con las instrucciones actuales es el rey en procesadores generalistas de alto rendimiento, sin lugar a dudas, pero son muy caros sobre todo cuando nos vamos a LV, ULV, Atom. Ahora mismo Intel fabrica lo mismo para todo, monta GPUs en los sobremesa, en los Clover Trail usa el HT, en los futuros Bay Trail montará las gráficas que salgan de los Ivy… Vamos que es un despropósito, no han hecho algo nuevo desde hace mucho todo ha salido del camino que comenzaron con los Pentium M y los GMA. Lógico que los fabricantes prefieran un ARM que por lo menos se ha hecho más a medida y seguro que es más barato.

Que ventajas tiene el tener más núcleos, sin lugar a dudas, quizás hasta sea más económico montar dos núcleos más baratos en IPC que uno mas caro. Pero hasta que sea la gran mayoría del soft que lo aproveche no lo descubriremos. Y con respecto a los juegos creo que también es aplicable, aunque es muy raro que un juego demande lo "tope" en cuanto a CPU a menos que sea con una configuración extrema o por mala optimización, mientras que en el GPU los juegos siempre suelen tragar todo lo que hay; quizás en el futuro acaben repartiendo más carga al CPU.

Krait no lo considero un buen ejemplo, es tan complejo como Cortex A15 aproximadamente, pero en rendimiento parece estar por debajo de éste, sacando sólo algo la cabeza a los Cortex A9. Y ser "complejo" no quiere decir dejar de ser "RISC", aunque las mejores cpus actuales no siguen los principios RISC originales al pie de la letra, y se pueden considerar que son algo así como RISC con un toque de CISC y alguna otra idea, unificando los puntos fuertes de cada filosofía de diseño.

Volviendo a Krait, sobre lo dicho así parece ser al ver los rendimientos obtenidos con el LG optimus G o el Nexus 4, que deberían teóricamente superar bien a los anteriores Quad Core basados en Cortex A9, claramente. Y esto no parece cumplirse del todo bien (por supuesto el rendimiento en coma flotante aparte, tema que ya con los Scorpion Qualcomm había perfeccionado sobradamente).

Tampoco se puede decir que consuma poco, ahí están los problemas de sobrecalentamiento que tiene el Nexus 4 y sus famosos "benchs en nevera", lo cual demuestra que los Krait no van del todo finos en consumos (mejores que Cortex A15 en principio, pero… no tan claro con los resultados prácticos).

Sobre que no han hecho nada nuevo en intel desde el Pentium M y GMA... XD.

Supongo que estarás de coña, la propia arquitectura Core (Conroe) era una mejora muy interesante a los últimos Pentium M, nehalem, Sandy Bridge, y todos los sabores intermedios han supuesto mucha más renovación en sus productos que la grandísima mayoría de rivales.

Sobre gráficos, nada tienen que ver las gráficas integradas por intel hoy en día con las GMA, de hecho si hay un punto donde trabajen es esto, aunque estoy de acuerdo en que meten sus gráficas hasta en la sopa en productos que no las necesitan o son un desperdicio de área útil del chip para su comprador.

Pero evidentemente, es una buena idea que intel integre sus propios gráficos a sus chips de tipo Atom, en vez de licenciar a terceros. Porque eso querrá decir que cree que su gpu puede hacer cosas interesantes sin disparar consumos en dicha plataforma, lo cual es bueno para todos sus productos. Otro tema, Bay Trail ya es una arquitectura distinta a la original de Atom basada en un Pentium muy modificado, así que puede dar sorpresas.

Así que no me parece que intel se esté tan quieta, precisamente. Otro asunto es que se dedique a dosificarnos las mejoras o pase de darnos lo que podría ofrecernos ya, cpus con 6-8 cores a precio de quad core. Será por tamaño de die y consumos.

Al último punto que destaco de tu comentario, ya podemos ver que esto no se tiene porqué cumplir:

Hay tienes a Bulldozer contra cualquier Bridge con 4 cores, 2 vs 1 y con soft masivamente multihilo, ni siquiera miro otras pruebas, con un coste de tamaño de die, consumo y rendimiento ofrecido por ciclo que está totalmente desbalanceado.

Se lleva tiempo ofreciendo soluciones multicore masivas, pero sólo para mercados de aplicaciones que realmente se benefician de esto. Y el soft multiproceso en PC existe desde los 90, con máquinas tan interesantes como 486 dual core y similares. Se lleva MUCHO tiempo trabajando en esto, más si miramos el mundo de las workstationts RISC (actualmente extinguidas como tales), el soft multihilo o multiproceso no es ninguna novedad, se lleva trabajando en esto desde los 70 por lo menos.

Así que no veo porqué cuesta tanto entender que no vamos a ver un salto masivo de aplicaciones a "aprovechar" los multicore, porque además hay problemas a atacar al programar que no se pueden paralelizar o no merecen la pena, entre varios cores, por problemas de sincronización y otros.

Balance. Una cpu con buen IPC como base. Si te fijas eso es la dirección que sigue ARM, incluso en sus productos de más bajo consumo. El cortex A7 es una cpu muchísimo más competente que el anterior A5 orientado al mismo perfil de cliente. Ya ni te digo si miramos más atrás. Por algo habrá esa obsesión por ofrecer un buen IPC en todo tipo de productos, ¿no?.

Creo que las posturas están más que expresadas, si tal seguimos discutiendo pero de otro punto de este tema, jejeje.

Saludos.

[Bm4n]

@Wargreymon:

Es que, como te comenta wwwendigo, las unidades de ejecución de un núcleo no tienen una ALU, sino varias (4 ALUs por core en Haswell, 3 ALUs por core en Sandy/Ivy/Nehalem/Core y 2 ALUs por core en los Bulldozer).

Sobre papel, en Haswell podrías enviar desde los schedulers en un ciclo 4 uops a las ALUs, es decir, estarías empleando 4 ALUs a la vez (Y ocupando los puertos 0,1,5 y 6), más las operaciones de memoria de los puertos restantes que serían otras 4 uops, es decir, 8 uops en total, una por cada puerto de los que dispone Haswelll (En Bulldozer serían 4 uops en total, 2 de computación y 2 de memoria). Por lo tanto, eso que comentas es precisamente lo que ya se hace.

Se me había pasado… no me explique bien, lo que quería decir era que es importante distribuir entre las unidades de ejecución.

En bulldozer se juntan dos unidades de ejecución, cada una con 2x ALU/AGU, el total es superior al de un Sandy que tiene 3x ALUs y 2x AGU. El caso es que lo que realmente es un núcleo pero funciona como dos a nivel de ejecución, el problema si no hay un soft optimizado no funciona bien y en la practica es bastante inútil, aunque en teoría el potencial es bueno* en el mejor de los casos. Si se mejorase cosas como el ancho del decoder, o igual redistribuyendo los caches puede que funcionase mejor sin tener que programar específicamente.

PD. @__wwwendigo__ estoy exagerando :ugly: evidentemente han evolucionado muchísimo, pero ninguna idea revolucionaria (aparte del HT, a mi parecer) simplemente han seguido una progresión fantástica. Las gráficas dieron un salto importante desde las 900 que no eran ni gráficas pero aun siguen siendo una cagarruta. Y si por supuesto que no creo que veamos CPUs con 40 o 80 núcleos, pero 8, 16 porque no?, la sincro solo la tienes asegurada si procesas una cosa detrás de la otra lógicamente; pero aparte del sector profesional es ahora cuando se hacen aplicaciones pensadas para funcionar en varios núcleos, no es que vayamos a saltar a ninguna parte solamente que los que no lo han hecho lo acabarán haciendo.

[Wargreymon]

@Bm4n:

Se me había pasado… no me explique bien, lo que quería decir era que es importante distribuir entre las unidades de ejecución.

En bulldozer se juntan dos unidades de ejecución, cada una con 2x ALU/AGU, el total es superior al de un Sandy que tiene 3x ALUs y 2x AGU. El caso es que lo que realmente es un núcleo pero funciona como dos a nivel de ejecución, el problema si no hay un soft optimizado no funciona bien y en la practica es bastante inútil, aunque en teoría el potencial es bueno* en el mejor de los casos. Si se mejorase cosas como el ancho del decoder, o igual redistribuyendo los caches puede que funcionase mejor sin tener que programar específicamente.

PD. @__wwwendigo__ estoy exagerando :ugly: evidentemente han evolucionado muchísimo, pero ninguna idea revolucionaria (aparte del HT, a mi parecer) simplemente han seguido una progresión fantástica. Las gráficas dieron un salto importante desde las 900 que no eran ni gráficas pero aun siguen siendo una cagarruta. Y si por supuesto que no creo que veamos CPUs con 40 o 80 núcleos, pero 8, 16 porque no?, la sincro solo la tienes asegurada si procesas una cosa detrás de la otra lógicamente; pero aparte del sector profesional es ahora cuando se hacen aplicaciones pensadas para funcionar en varios núcleos, no es que vayamos a saltar a ninguna parte solamente que los que no lo han hecho lo acabarán haciendo.

Ese ejemplo que me pones representa el uso de instrucciones XOP, de las cuales los Sandy/Ivy carecen… Aun así no deja de ser curioso ver al Pehnom II x6 tan alto, practicamente a la par del FX8350 con sus 8 núcleos y eso funcionando este último a mayores frecuencias claro.

La arquitectura Bulldozer tiene más pegas que su diseño de bloques, con cachés L1 pequeñas y lentas, y cachés L2 y L3 bastante lentas también, por no hablar del controlador de memoria que no a avanzado apenas desde los K8.

No se trata de defender el ipc de los 4 núcleos "por que sí", la defensa viene sencillamente de las decisiones de los programadores en cuanto a multihilo y la complejidad de programar así, que se hará, eso seguro, pero pueden pasar muchos años hasta ver aplicaciones empleando 6/8 hilos de forma general, y diciendo muchos quiero decir muchisimos, que actualmente los quad-cores están bastante infrautilizados, y los dual-core a veces también por que son un millar las aplicaciones que aun a día de hoy solo tiran de 1 hilo, la gran mayoría (Dejando de lado los juegos que parece que son incluso los que más partido sacan). Y a tu review me remito:

Que sí, que empleando 8 hilos no ocurriría esto, pero eso diselo a los programadores, hasta entonces la carrera de núcleos para uso doméstico no tiene mucho sentido.

[Wargreymon]

¡Esta publicación está eliminada!

[wwwendigo]

@Bm4n:

Se me había pasado… no me explique bien, lo que quería decir era que es importante distribuir entre las unidades de ejecución.

En bulldozer se juntan dos unidades de ejecución, cada una con 2x ALU/AGU, el total es superior al de un Sandy que tiene 3x ALUs y 2x AGU. El caso es que lo que realmente es un núcleo pero funciona como dos a nivel de ejecución, el problema si no hay un soft optimizado no funciona bien y en la practica es bastante inútil, aunque en teoría el potencial es bueno* en el mejor de los casos. Si se mejorase cosas como el ancho del decoder, o igual redistribuyendo los caches puede que funcionase mejor sin tener que programar específicamente.

PD. @__wwwendigo__ estoy exagerando :ugly: evidentemente han evolucionado muchísimo, pero ninguna idea revolucionaria (aparte del HT, a mi parecer) simplemente han seguido una progresión fantástica. Las gráficas dieron un salto importante desde las 900 que no eran ni gráficas pero aun siguen siendo una cagarruta. Y si por supuesto que no creo que veamos CPUs con 40 o 80 núcleos, pero 8, 16 porque no?, la sincro solo la tienes asegurada si procesas una cosa detrás de la otra lógicamente; pero aparte del sector profesional es ahora cuando se hacen aplicaciones pensadas para funcionar en varios núcleos, no es que vayamos a saltar a ninguna parte solamente que los que no lo han hecho lo acabarán haciendo.

Bueno, wargreymon ya te ha contestado a la primera parte, no tiene que ver el rendimiento con hash a base de instrucciones específicas, el hecho es que cuando programas no puedes sumar cores y su rendimiento acumulado por muy multihilo que sea tu programa, casi nunca (y las pocas veces que se acerca a ser cierto, también suele haber una pérdida de rendimiento mínima).

Sandy no tiene 3 ALUs y 2 AGUs sólamente, te olvidas que tiene una unidad inexistente en Bulldozer, que es la de "store data". En total tiene 6 puertos de ejecución desde la etapa del scheduler a la de ejecución, lo núcleos Bulldozer tienen sólo 4 puertos. Aún así, ya te digo que esa suma no se aplica en soft multihilo, y mucho menos si se tiene en cuenta que cada core debe ser capaz de ejecutar un streaming de instrucciones sin cuellos de botella.

El primer y gran cuello de botella en Bulldozer y piledriver está en la etapa de decodificación, que está totalmente limitada a decodificar no más de 4 instrucciones por ciclo para dos cores, esto es, que cuando usas "eficientemente" ambos cores de ninguna de las maneras puedes sostener un ratio de ejecución de más de 2 instrucciones x86 por ciclo y core.

Mientras que Sandy puede llegar a 5 de éstas (fusión), 4 sin problema mirando la etapa de decodificación.

A nivel práctico esto querrá decir bastantes menos instrucciones por ciclo que el máximo teórico, pero esto se aplicaría también a Bulldozer, Bulldozer por diseño no puede superar ese ratio de 2 instr./ciclo, que es bastante menos que lo visto en arquitecturas anteriores como la propia línea evolutiva del K7-K10, y se pone a la altura de un K6 o similares en sus limitaciones máximas (más rápido y con mejor IPC, evidentemente, por múltiples mejoras aparte). Para mirar en intel una cpu tan "estrecha" habría que mirar al Pentium original, o dependiendo del cómo incluso a un Pentium4 (un decoder, pero la trace caché estaba "detrás" de éste, por lo que teóricamente sí es capaz de soportar una ejecución de más instrucciones x86 que lo que teóricamente podía soportar el decodificador, gracias a la existencia de tantos bucles y localismos del código en la caché).

El problema es que Bulldozer tiene una fase de decodificación paupérrima, incluso para su hard de ejecución limitado por core. De ahí que Steamroller vaya a incorporar decodificadores exclusivos para cada core, deshaciendo por tanto uno de los puntos de "innovación" de Bulldozer. También se gasta una cantidad ingente de área en una L2 de dudoso rendimiento, muy sobrecargada además por una L1 muy ineficiente (el nivel de asociatividad de la L1 de instrucciones es malísimo, de 2-vías por módulo, lo que viene siendo al final para cada core el equivalente a una L1 direct mapped).

O sea, que se puede contar las unidades de ejecución, pero no sirve como comparación en absoluto si resulta que el cuello de botella en la cpu viene de antes.

Los cambios que ha hecho intel en sus cpus, por otra parte, son más que notables, ha sido "pionera" en cpus de consumo en el uso de cachés L0 para insturcciones, o de colas de "loops" detrás de los decodificadores, una innovación que permite tanto bajar consumos como aumentar rendimiento, y que puedes ver que han adoptado otros fabricantes como AMD (para Steamroller una cola de loops), ARM (idem con los Cortex A15) o Qualcomm (con los krait ha introducido toda una L0 detrás de los decodificadores, lo cual le da un punto de ventaja frente a diseños basados en Cortex A15, para consumo y teóricamente rendimiento).

El problema está en que desde el Conroe original, han hecho muchos cambios en sus sistemas de cachés, en el hard de ejecución, mecanismos de prefetch, controladores de memoria, etc, pero los resultados aunque buenos, no se notan "tanto" por la simple razón de que el rendimiento ya era bueno de base, y a partir de cierto momento se vuelve más y más difícil extraer paralelismo de un proceso/hilo con el que aumentar el IPC de un core.

Piensa que AMD cuando tiró a la basura su diseño K10.5 y se embarcó en la (des)aventura de Bulldozer fue como un gran grito de renuncia a mejorar el IPC de sus diseños, como si se le hubieran agotado las ideas y decidiese un movimiento desesperado (muy, muy parecido a lo que hizo intel en su momento con el P4).

[Bm4n]

@Wargreymon:

Ese ejemplo que me pones representa el uso de instrucciones XOP,

La arquitectura Bulldozer tiene más pegas que su diseño de bloques, con cachés L1 pequeñas y lentas, y cachés L2 y L3 bastante lentas también, por no hablar del controlador de memoria que no a avanzado apenas desde los K8.

actualmente los quad-cores están bastante infrautilizados, y los dual-core a veces también por que son un millar las aplicaciones que aun a día de hoy solo tiran de 1 hilo, la gran mayoría (Dejando de lado los juegos que parece que son incluso los que más partido sacan).

diselo a los programadores, hasta entonces la carrera de núcleos para uso doméstico no tiene mucho sentido.

Dije programando para y en el mejor de los casos sino suele rendir a par o menos que un 2500, no vamos a discutir cosa obvias por favor, pero como dices ese diseño "en bloques" quizás no sea el principal problema.

Hay pocas tareas que tengan un gran consumo de CPU pero las que lo hacen: compresión de archivos, modelado 3D, encriptacion, calcuos en excel, juegos, suelen aprovechar el paralelismo; comparando ahora un dual vs. quad no van a empatar (HT aparte). Deja a los programadores tranquilos, si es lo que hay no volveremos a procesadores mono hilo, el mayor problema es que no se puede programar para X hilos tiene que ser flexible porque hay variedad de CPUs (con 2, 3, 4, 6, 8 y 12 hilos). Siempre habrá tareas que aprovechen más y otras menos…

Dos tareas de rendimiento puro y duro que creo que reflejan bien lo que cada CPU puede rendir en bruto aprovechando todos los núcleos:

!

@wwwendigo:

Los cambios que ha hecho intel en sus cpus, por otra parte, son más que notables

Muy cierto.
@wwwendigo:

y a partir de cierto momento se vuelve más y más difícil extraer paralelismo de un proceso/hilo con el que aumentar el IPC de un core

De cierto momento, evidente, tiene que haber un equilibrio entre velocidad, IPC y paralelismo.
@wwwendigo:

como si se le hubieran agotado las ideas y decidiese un movimiento desesperado (muy, muy parecido a lo que hizo intel en su momento con el P4

Intel llegó a un punto muerto porque necesitaba velocidades inalcanzables para obtener rendimiento, y decidió continuar la linea del Pentium M que no había dejado de lado y era mucho más eficiente en IPC, menor consumo y un pipeline mas corto y aceptable. Aun así aprendió y no deshecho las buenas ideas que saco con NetBurst.

@__wwwendigo__ en ningún momento he dicho que me parezca mejor o buena la arquitectura de bulldozer, solo he dicho que me parece interesante o explotable el diseño en bloque. Pero se nota que a ti si que te gusta porque lo discutes con ansias