• Portada
    • Recientes
    • Usuarios
    • Registrarse
    • Conectarse
    1. Foro
    2. wwwendigo
    3. Mensajes
    W
    • Perfil
    • Siguiendo 0
    • Seguidores 0
    • Temas 0
    • Mensajes 262
    • Mejor valorados 0
    • Controversial 0
    • Grupos 0

    Publicados por wwwendigo

    • RE: Intel Core i7 4770K (Haswell)

      @Wargreymon:

      Falta ver la mejora en juegos con GPU dedicada y la prueba de la caché L2 es extraña, por que debería doblar a la generación anterior. Quizás la versión final rinda más de lo que se observa ahí…

      En cuanto a GPU falta por ver la GT3, pero si la GT2 rinde así, la GT3 me da que se va a fundir a las APUs de AMD en el mercado de los portatiles.

      A eso hay que añadirle su rendimiento del controlador de memoria, en dicha prueba, muy por debajo de lo esperado (pero que Sandy/Ivy), está claro que en esa muestra de ingeniería y con la placa de pruebas que hayan usado hay muchas cosas por pulir aún.

      El ancho de banda a la memoria, más el ancho de banda a la L2 (precisamente la L2 de los intel es relativamente "pequeña" para mejorar su velocidad de latencia, además de tener un ancho de banda muy grande) son dos puntos que marcan muchísimo el rendimiento de cualquier plataforma.

      Así que dado que estos dos puntos no están funcionando como deberían, lo lógico es tomar estos resultados como, por lo menos, dudosos de representar a la cpu final, algo por debajo o muy por debajo, depende de lo que influyan estas dos características (L2 y controlador de memoria) en cada aplicación.

      @Falkemberg:

      …pero soy el unico al que le parece un fiasco tan poca mejora en un cambio de plataforma de 500€?

      Yo no sé porqué dices 500€, a mí cambiar a Sandy me salió por poco más de 300€, sin contar por supuesto con la reventa de piezas del "núcleo" de mi pc anterior.

      CPU unos 180€, quizás 200€, placa base una medianamente buena por 100€ la consigues, y la memoria… si vienes de Sandy/Yvy ya la tienes (de todas formas yo compré los tres elementos en su momento, por menos de 350€, y metiendo "lujos" como placa con soporte SLI).

      La mejora vista en pruebas de Toms son más o menos equivalentes al salto de Sandy a Ivy, aún a pesar de que algo va mal con ese equipo como muestran las pruebas de ancho de banda a memoria y a la L2. Así que funcionando perfectamente seguramente consiga aumentar esta diferencia.

      La verdad es que no sé qué queréis algunos, está claro que si cambias de plataforma en cada generación no vas a ver nunca "grandes saltos", porque no das tiempo a que éstos lo sean de verdad.

      Yo salté de un Core Quad a Sandy, y sí lo noté y bien, aún así no creo ser de los que más extienden sus plataformas, pero tampoco me uno a pegar "saltos" con poco beneficio todos los años.

      Es posible que Haswell pueda ofrecerme algo, pero si no esperaré a la siguiente generación y punto, será porque no cumple sobradamente un Sandy con las aplicaciones de hoy en día.

      Relax, y primero ver el rendimiento real, y después si tal criticar. Y si no gusta se espera a la siguiente generación, no todo van a ser pasos de gigante.

      publicado en Procesadores
      W
      wwwendigo
    • RE: Interesantisima lectura sobre el nuevo metodo de benchmarking de las GPUs

      @kpablo:

      Es un articulo de Anandtech.

      AnandTech | AMD Comments on GPU Stuttering, Offers Driver Roadmap & Perspective on Benchmarking

      Es un articulo que vale la pena leer… lo curioso es que AMD no sabia muchas de las cosas, o las daba por sabidas y que no eran ciertas... por fin han admitido abiertamente y prometen (ya estan cumpliendo) los arreglos pronto.

      Y que tambien demuestra que la division software de Nvidia se encuentra un paso por delante del de AMD.

      Hombre, el artículo es un "previo" (26/03/13) a otro que salió al día siguiente (27/03/13) que creo que además está claro que es un favor de Anandtech a AMD, permitiéndole hacer su "defensa" antes de que le cayera el chubasco de lo que pasó al día siguiente:

      http://www.anandtech.com/show/6862/fcat-the-evolution-of-frame-interval-benchmarking-part-1

      Yo personalmente considero casi ofensivo que a un site como anandtech le hayan dejado ser el que ahora lleve la batuta de esto, y no lo digo ya por el artículo mencionado, que cuando lo leí ya me resultó chocante por no decir otra cosa el que AMD usara un site como Anandtech, con CERO interés en mostrar este problema ya conocido por este mundillo de sites desde hace años, el problema de la distribución de frames o frametimes.

      Pero con el artículo linkado del día 27/03/13 ya me quedó más claro, sobre todo porque este artículo no es único (gracias a dios, al verlo como el primero en la red estaba alucinando), existen otros fechados de ayer que no sólo hablan de FCAT, sino que empiezan a usarlo:

      http://www.tomshardware.com/reviews/graphics-card-benchmarking-frame-rate,3466.html

      http://techreport.com/review/24553/inside-the-second-with-nvidia-frame-capture-tools

      http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-Dissected-Full-Details-Capture-based-Graphics-Performance-Testin

      Y puede que haya alguno más. Lo de la parte polémica lo digo por lo increíblemente injusto que es que se haya elegido a Anandtech para dar estas explicaciones, o que haya sido el primer site con datos sobre FCAT y su metodología, cuando no han hecho absolutamente nada en estudiar esta metodología.

      Sites como Techreport.com o Pcper.com han hecho mucho, mucho más intentando entender esto y promoviendo el testeo buscando la experiencia de juego más estable. El primero es el "veterano" en estos temas que a base de fraps ha cambiado a muchos otros sites en sus metodologías (básicamente cualquier site conocido ha empezado a usar en alguna medida análisis de frametimes, excepto Anandtech, cómo no, y otros sites demasiado linkados al uso de fps medios en sus baterías de pruebas muy extensas, como Techpowerup!). PCPer es el que además ha promocionado desde hace tiempo el desarrollo de una metodología que se puede decir que es la misma que FCAT, lo que no queda claro es hasta qué punto ha colaborado en ésta.

      Por eso, que se escoga un site que le importaba una mierda todo este tema, cuando veíamos que sites como Guru3D, Toms, empezaban a tímidamente incluir en parte implementaciones de este metodología, me parece increiblemente injusto.

      El tema es que FRAPS "puede" que no sea la herramienta perfecta, pero ya lleva señalando los problemas de AMD desde hace, como poco, los Catalyst 12.10 (hubo un aumento de Microstuttering en éstos). Y de hecho se puede considerar que drivers como los Catalyst 13, y sobre todo los 13.2 con sus beta están muy orientados a ir arreglando los problemas en juegos particulares.

      O sea, que no es cierto eso que dicen en Anantech Ryan Smith, en un ataque de arrogancia impresionante, de que AMD no supiera nada (sabía, no desde hace muchos meses, pero sabía del tema de sobra, de hecho prometió las primeras soluciones al MS a comienzos de diciembre, hablando con Scott Wasson de TechReport).

      Con eso sólo demuestra que anantech ha decidido ignorar o anular en gran medida los méritos de sites ajenos, pues aunque linkan a Techreport e incluso a PCPer, por ejemplo no mencionan el codesarrollo aparente de PCPer respecto a FCAT (o que por lo menos estaban creando una solución muy similar). O deciden ignorar las profusas comunicaciones entre techreport y AMD sobre el problema y las soluciones que tenían planificadas en AMD.

      También mencionar que, a pesar de ser los "primeros" en hablar de FCAT (por horas), no se han molestado en empezar a hacer su uso como sí lo han hecho en los demás sites que han hablado del tema, así que "shame on you", anandtech.

      Es que no me mola nada que se lleve los méritos un site que no ha hecho NADA en el estudio de este problema, cuando estoy seguro que estaban "advertidos" de los nuevos vientos que soplaban por los demás sites del sector.

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: CPU vs. GPU

      @Wargreymon:

      Bueno, eso depende de lo que hagas. Yo lo de comprimir un video con cada núcleo lo ví con un programa (No recuerdo cual) que usaba para recomprimir los videos a un formato compatible con el iPhone que tenía, y por defecto el programa hacía eso, si te detectaba una CPU de 2 hilos y una cola de 4 videos pues comprimía 2, uno en cada hilo, y después los otros dos, si te detectaba 4 cores pues los 4 a la vez… Así sucesivamente. Otro asunto es la pasar un video de un formato a otro por ejemplo y cosas así.

      Por lo demás que comentas estoy bastante de acuerdo contigo, si todos los juegos pudieran emplear los 8 núcleos de Bulldozer otro gallo cantaría (Lo mismo yo tendría uno, no tengo inconveninete, de hecho, tengo un piledriver de 4 cores en el HTPC). Y el mercado actual está bastante segmentado en el tema que comentas de ipc vs núcleos, que como dices eso sería lo discutible, el problema es que practicamente, con un precio normal, solo puedes elegir o una CPU con muchos núcleos y poco ipc o una CPU con mucho ipc y pocos núcleos. Si quieres algo intermedio, que el único que se me ocurre es el 3930K toca pagar 500 eurazos, y claro...

      Si, como dices esos juegos emplean muy bien el multihilo, desde luego no lo niego, el crysis 3 ya lo había mencionado por ahí arriba y sí, la verdad es que sabe emplear muy bien la CPU, incluso parece capaz de poner en aprietos los 4 núcleos de un Sandy pero de momento es una excepción. Seguramente en el futuro esta sea la tendencia, pero para cuando llegue ese momento seguramente tengamos CPUs de 6/8 núcleos con ipc decente a mejor precio que a día de hoy. A día de hoy de momento me quedo con Sandy/Ivy y los futuros Haswell.

      Eso que dices al principio es casi seguro porque el programa no era multihilo, sino multiproceso, y lanzaba procesos completos dedicados a la compresión de un vídeo, uno por cada core. Si fuera multihilo sí podría usar varios cores por video a comprimir, posiblemente definiendo la presencia de unos I-frame cada X tiempo en el video comprimido, y dejando secuencias entre I-frames a cada core (independencia de datos).

      Yo sigo afirmando que una cpu con "muchos cores" pero que a plena carga de éstos no se destaca contra los rivales aún con un ratio 2:1 en cores, es un disparate.

      Si AMD hubiera conseguido su octocore entregando más IPC, quizás a la altura del primer nehalem, o como mínimo por encima de los C2Duo (que en el fondo seguían teniendo mejor IPC que los PhII, aunque fuera muy ligeramente), entonces estaríamos hablando de una cpu mucho más capaz y todo eso que dice bm4n tendría más aplicación real.

      Pero el rendimiento es demasiado bajo, es con Piledriver donde empieza a destacarse esta arquitectura de los anteriores PhII x6, por ejemplo, pero si miramos frecuencias, nuevas instrucciones, etc. Se seguirá viendo que falta "chicha" en eficiencia. Y ese problema es más grave que lo que pueda añadir como favor empaquetar muchos cores. Que de todas formas, si AMD fuera capaz de lograrlo con una die barata de fabricar… pero ni eso. Más de 300mm2 es un señor procesador en tamaño.

      Intel se lo debe estar pasando canela a base de fabricar quads que compiten perfectamente y con la mitad de área (y desperdiciando gran parte de ésta con su IGP). Es que vamos, el movimiento ha sido un error garrafal por parte de AMD. Si AMD hubiera sacado algo como lo dicho, seguramente veríamos del lado de intel disponibles en la plataforma "mainstream" 6-cores.

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: CPU vs. GPU

      @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).

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: CPU vs. GPU

      @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.

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: CPU vs. GPU

      @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.

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: CPU vs. GPU

      @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.

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: CPU vs. GPU

      @Bm4n:

      Pues si el rumor data de cuando AMD comenzaba con el bulldozer, evidentemente el pipeline no puedes compartirlo pero lo que ha hecho AMD ha sido compartir el descodificador y el cache. Por desgracia no lo hicieron nada bien, porque esos dobles núcleos no eran realmente el doble de potentes en muchos aspectos como en la FPU. Y el marketing de llamar 2 núcleos a lo que realmente es 1 no le ha favorecido, pero pensándolo desde otro punto de vista lo que han hecho es coger 2 núcleos y hacer que rindan como 1 de más potencia de calculo.

      Pero bueno yo cuando lo vi pese a la decepción, me quedé con la sensación que eso pero bien hecho y mejorado podría ser realmente interesante. A veces grandes ideas comienzan con mal pie, quien sabe.

      A mi entender ahí está el punto en mejorar el balanceo de las cargas, a nivel de programación hay soluciones que supongo se pueden mejorar, pero si a nivel de hardware lo facilitas se podría lograr que varios núcleos funcionen como uno de mayor potencia de calculo. Logicamente como bien dices, eso no lo es todo y no puedes pretender que eso sea todo el avance, hay que seguir mejorando el IPC. Pero no podemos concebir un multi procesador como cuando Intel empezó haciendo sus "multi núcleo" pegando literalmente dos procesadores en un DIE que no compartían ni el L3 como quien dice…

      PD. De Steamroller no he leido apenas, le echaré un ojo, aunque sinceramente no le tengo ninguna esperanza quizás para la escarbadora nos llevemos una sorpresa hasta entonces lo dudo.

      PD2. Y no quiero decir que una operación se pueda realizar en dos núcleos a la vez que sería imposible, pero sabemos que al ejecutar varias operaciones en un hilo nunca va ser 100% eficiente a menos que sea un calculo puro y duro, el HT lo que hace es rellenar los huecos que quedan en la ejecución. Lo que yo digo es que si la cola (fetch, predictor, decoder) pudiera distribuir más eficientemente las operaciones en vez de en un FPU/ALU en varios mejoraría el rendimiento.

      Sobre lo primero que resalto, la culpa fue tanto de AMD por sus primeras diapositivas donde sí dió a entender que sería algo de ese estilo (lenguaje ambiguo), como de ciertos sites y gente que al más puro estilo de un Charlie Demerjian se dedicaron a lanzar la "buena nueva" de su interpretación errónea de las primeras presentaciones de AMD sobre lo que sería bulldozer.

      El tema es que compartir etapas como la decodificación y la unidad de coma flotante, en realidad no tiene nada que ver con una unificación de la ejecución de un mismo hilo entre dos núcleos. Es simplemente una política de ahorro de costes compartiendo hard entre núcleos.

      Estrictamente hablando son dos núcleos, porque a nivel lógico están totalmente separados sus recusos de ejecución y por no poder, ni se mezcla el código de cada hilo/proceso de cada core en la etapa de decodificación (se alternan por ciclos los decodificadores), la coma flotante separada, para el que recuerde las unidades de FPU opcionales de hace tiempo en los PCs, le sonará bastante y entenderá que en el fondo es "separar" dicho bloque de la cpu y compartirlo como un "coprocesador" entre dos núcleos, contando el que no se va a usar mucho.

      Todo en Bulldozer va a la "simplificación" de cada core, supuestamente para aumentar mucho la cantidad total y "ganar" así más rendimiento total. Aunque lo hicieron condenadamente mal (que aún con Piledriver en programas masivamente multihilo lo pasen mal los Piledriver vs los Ivy i5 o i7, no es un buen indicativo, porque esta "igualdad" no se sostienen en otros programas multihilo o monohilo/ligeramente multihilo).

      Lo último que dices ya te digo que es básicamente imposible, porque entre decoders y schedulers, hay todo un hard dedicado tanto a la predicción de saltos como al reordenamiento de instrucciones, con toda su ventana de registros, instrucciones, etc.

      Para que un scheduler pudiera "elegir" entre dos cores distintos donde enviar las instrucciones a ejecutar del hilo/proceso, tendría que "cablearse" y añadir una cantidad de hard extra muy importante para hacer que una instrucción pueda ir de un "core" a "otro", y además lleve claramente identificado el hilo al que pertenece (y se restituya al flujo de instrucciones originario cableando también hasta el "retire", vamos una locura).

      Pero eso no da ninguna ventaja, hoy en día existen a partir de los schedulers una cantidad de unidades de ejecución y posibles puertos de instrucciones que dan para conseguir un gran paralelismo, una "ALU" no es una ALU (como símil de cpu de enteros) hoy en día, es una colección de varios ALUs y unidades varias.

      Lo más fácil y racional es usar este paralelismo ya enorme existente para ejecutar varios hilos en un mismo core, algo mucho más asequible para el hard actual, y que de hecho han implementando varios fabricantes (menos AMD). Se podría diseñar una cpu para que fuera por core extremadamente ancha, no ya para aprovechar el "ancho" de ejecución sobrante de la cpu para un nivel de paralelismo extraido de una cpu, sino que se podría sobredimensionar esta parte para que la ejecución de 2 o más hilos simultáneamente fueran con un rendimiento cercano al de funcionar en cores aislados.

      Pero vamos, todo esto da igual, lo que dices no se puede hacer, o es poco o nada práctico. Lo que ha hecho AMD es reducir la complejidad de sus cpus "estrechándolas" en recursos de ejecución, y compartiendo etapas enteras más bloques como la FPU, en un intento de ir a una solución de "más cores es igual a más rendimiento". Lo que pasa es que hasta ahora le ha salido bastante rana la implementación.

      Le habría ido mejor si se hubiera decidido a evolucionar de una vez por todas el diseño de los K10, que aunque parezca mentira es un heredero total del diseño del K7 original, en lo que respecta al balance de unidades de ejecución y decodificadores (3 decoders, 6 unidades de enteros y 3 unidades de coma flotante, una estructura mantenida desde el primer Athlon hasta el último Phenom II).

      Intel lo hizo con el P-Pro remodelándolo tanto como hiciera falta, cambiando el balance de unidades, puertos de ejecución, decodificadores, etc, y bien que le ha ido.

      Supuestas soluciones mágicas de "fusión de cores" sólo han surgido desde la mala prensa leyendo presentaciones confusas de AMD.

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: CPU vs. GPU

      @Bm4n:

      Cuando el rio suena… desde hace años se habla que era proyecto de AMD mejorar el proceso de un solo hilo en procesadores de varios núcleos, no he dicho que ya lo haya, pero por los pasos que lleva parece que por ahí van los tiros. Más que un disparate es lo lógico.

      No se porque dices que no ha avanzado tanto cuando en realidad si lo han hecho, lo que pasa es que a veces nos falta memoria, y eso que no se explotan bien sus capacidades, seguro que el tiempo en idle de un CPU ha aumentado muchísimo.

      El aumentar la frecuencia de los núcleos va muy atado al tamaño y tipo de fabricación, se puede mejorar el IPC aunque son realmente eficientes y tampoco se puede hacer magia con el si no hay unas instrucciones para aprovechar las capacidades. La alternativa es usar el multiproceso o mejor dicho aprovecharlo, es como el paso a 64bits, tardará años pero acabará llegando.

      Intel ahora se dedica a ganar dinero, no hará grandes inversiones hasta que lo necesite, lógico. Y hasta a mi me parece bien, ahora mismo yo no me plantearía comprar un procesador con más velocidad ni con más núcleos, solo lo compraría si el IPC ha mejorado y rinde mejor porque se que del resto habrá pocas cosas que donde sacarle provecho.

      No, no es lógico. Hacer eso implicaría mecanismos de comunicación y sincronización entre cores en distintas de sus etapas que complicarían tanto el diseño hasta hacerlo ridículo, ya que una simple implementación de un "supercore" (fusión de recursos real de X cores) con soporte de SMT hace mejor este papel.

      Ya te digo que este rumor es muy antiguo, se dijo mucho que eso era lo que haría Bulldozer (la confusión la creó la propia AMD, recuerdo alguna presentación añeja y muy ambigua), y desde que salió no volvió a hablarse en absoluto ni de lejos de algo así (por parte de AMD).

      Así que seguramente no se hará, porque además de parecer un poco disparatado (ojo que no digo que imposible, sólo que yo no le veo sentido alguno), hay caminos para mejorar el IPC de verdad más directos que coger, fusionar un par de etapas en unos cores que reduces desde los K10, y después tardar varias generaciones en ¿comunicarlos? para conseguir un rendimiento… ¿poco mejor que el que tenían en origen, qué IPC podría tener algo así?

      No mucho ya, un módulo de AMD de 2 cores tiene 4 decoders, eso limita el número de instrucciones por ciclo que puede ejecutar (x86), y en absoluto es mejor que lo que se puede hacer ya en otras arquitecturas que no han recurrido a esa maniobra rocambolesca.

      AMD ha apostado (posiblemente mal) a simplificar cores para intentar integrar muchos en una sóla die (aunque esto no le ha salido del todo bien mirando tamaño de die y nº de transistores usados), es un buen argumento para el departamento de marketing, pero todos los problemas de rendimiento que incluso con Piledriver siguen teniendo se deben a esto.

      Esta ruta iniciada con Bulldozer no acaba con ningún "SMT inverso" como el que describes. Con suerte acabarán haciendo cores relativamente rápidos y en gran número, si es que arreglan por el camino las cagadas que cometieron. Pero... fusión de cores para un mismo hilo, ni de coña:

      http://www.xbitlabs.com/news/cpu/display/20121122235832_AMD_s_Steamroller_High_Performance_Core_Slips_to_2014_Excavator_May_Face_Delays.html

      El diseño de Steamroller en absoluto apunta en esa dirección, y lo poco que se sabe de Excavator tampoco, en principio.

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: CPU vs. GPU

      @Bm4n:

      El futuro pasa por los multinucleo sin lugar a dudas, AMD por ejemplo está trabajando en hacer trabajar múltiples núcleos en un solo hilo, vamos al contrario del HT de Intel. Esto es tremendamente interesante, porque como sabrás en la ejecución de un juego hay cantidad de procesos con lo que teóricamente procesarlos simultáneamente podría mejorar mucho el rendimiento, claro que entretejer todo eso "manualmente" como dices es complicado, depende de los compiladores, lenguajes, programas, etc. que se usan a la hora de programar el permitir optimizar esto.

      Imaginemos que podemos procesar independientemente el sistema de IA, iluminación, fisicas, cálculos de distancias, el HUD, etc. y ahora dedicar a este proceso porque consume más 4 núcleos de "potencia", a este solo uno, al otro dos, etc. Creo que eso es a lo que se aspira con la tendencia que está tomando el mundo de los procesadores.

      No estoy de acuerdo con que el margen de los CPUs sea muy corto, simplemente a nivel de potencia de calculo por ciclo de reloj se ha avanzado muchísimo, aquí algunos recordamos cuando el SuperPI de 1MB se pasaba en muchos minutos y ahora tarda menos de 10". A nivel de pipeline se ha experimentado con todo, los predictores avanzaron muchisimo también, los caches y su uso compartido/independiente, sets de instrucciones, etc. los anchos de banda a memoria bus central y periféricos que ahora son prácticamente directos, etc. Es realmente impresionante la capacidad que tienen, lamentablemente resulta que para tareas cotidianas resultan igual de buenos un ARM, quizás en el futuro veamos CPUs hibridos con núcleos de diferente tipo dedicados a diferentes tipos de calculo con diferentes relojes.

      Aunque el problema yo creo que es que esa potencia no les sirve de nada a los programadores porque no tienen las herramientas para explotarlo, de ahí que ahora mismo para ver la velocidad de un CPU tengas que sacar el cronometro en algoritmos como la descompresión de ZIPs o la compresión de video…

      El paralelismo en si muchas veces es necesario, un CPU que pueda interconectarse con el GPU cosa que también esta en el punto de mira de AMD sería otro gran avance y logicamente necesita de usar multiples núcleos.

      Y como veras aqui siempre recomendamos montar equipos equilibrados, un CPU barato con una gráfica carísima es un desperdicio. El buen rendimiento de un PC está en el equilibrio entre los componentes.

      No sé de dónde sacas eso, pero que sepas que AMD no tiene ni un sólo producto en el mercado que haga esto, y tampoco lo hará en las siguientes generaciones a Piledriver.

      De hecho eso se rumoreó mucho con Bulldozer debido a opiniones indocumentadas, antes de su lanzamiento. Dije que era un disparate, me apedrearon por decir eso (y otras cosas sobre su rendimiento) y tras el lanzamiento muchos tuvieron que pedir disculpas.

      Sobre el margen de las cpus, es más escaso porque las gpus son más variables en sí, el rendimiento de hace 5 años por gpu era muy distinto al actual, y el rendimiento de una cpu de hace 5 años sin embargo no es tan distinto a las actuales. Por tanto como la potencia de cpu no cambia tanto no te puedes permitir el lujo de implementar algoritmos de IA muy avanzados, físicas equivalentes a PhysX GPU pero por cpu, etc.

      Por último, aunque esto sí lo está haciendo AMD, dudo mucho que sirva para "todo", porque precisamente las gráficas están demostrando que no son buenas para muchos problemas complejos a pesar de su potencia, ya que mientras son buenas "machacando matrices" no se llevan bien con código condicional y otros usos típicos de programas también intensivos.

      Esto es, AMD lo que pretende es desplazar la falta de potencia en IPC y coma flotante de sus núcleos a una gpu integrada y bien comunicada con la cpu, de forma que sea casi una extensión de la cpu más que un añadido pegado en la die pero realmente distinto.

      Esto puede ser útil para acelerar alguna cosa como físicas de segundo orden (las típicas que hace PhysX GPU), cálculo matricial, incluso puede venir bien en algunas etapas del subsistema gráfico que ejecuta la propia cpu. Pero no va a servir ni remotamente para "todo", eso debería quedar claro.

      Hoy en día el soft GPGPU deja mucho que desear en la mayoría de programas que están fuera del mundo científico, por multitud de razones. Y no es porque las librerías ya no estén maduras.

      Lo que hace falta es mejores cores con más ipc y más frecuencia, todo esto posible pero que no se hace por la simple razón de que AMD está en aprietos e intel aprovecha para relajarse de una forma casi obscena con sus productos.

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: CPU vs. GPU

      @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.

      El tema es que mucha gente piensa que es fácil hacer uso de sistemsa multicore, y aunque sea necesario, por la parte que me toca yo comprendo los problemas y retos que se encuentran.

      Es por eso que yo a la hora de recomendar cpus siempre he apostado, para usos como juegos y demás, priorizar primer el rendimiento por núcleo, y después de esto el rendimiento conjunto contando el número de cores. Los Quads llevan tiempo entre nosotros y siguen sin aprovecharse eficientemente, y no es sólo por culpa de los "ports de consolas" (XBOX 360, tres núcleos y 6 hilos, PS3, 1+6 núcleos (para la aplicación) y 26 13 hilos simultáneos manejables), si fuera por esto llevarían mucho tiempo usándose bien aunque fuera con gráficos DX9. Es que el problema es peliagudo.

      Por eso me asombra la fe que profesa la gente con los sistemas con más cores aún, y con las nuevas consolas con cpus que tienen un rendimiento por core muy bajo (baja frecuencia, IPC normalito, con suerte) aunque tenga un buen lote para comenzar. Y por eso digo que nunca se descuide la cpu, porque no hay nada más frustante que tener una gráfica de 400€ y ver que tu cpu de 175€ aún con OC hay situaciones donde se queda un poco corta (hago ejemplo con mi caso).

      Pero vamos, que no hay discusión sobre el tema. Pero ya te digo que el problema es peliagudo y de hecho más de una vez he tenido curiosidad por él pero nunca me he metido en ese tipo de berenjenales porque realmente no me "competen" (por lo menos no hasta ahora), pero la curiosidad más de una vez me llevó a investigar sobre estos temas.

      En cierta forma las cpus están limitando tanto o más que la propia gráfica el diseño de juegos, porque a diferencia de las gráficas, el arco de rendimientos de cpus es más estrecho, y por tanto se pueden hacer menos "florituras" por la parte que les toca. Una de las razones para que la IA en juegos sea básicamente la misma usada en juegos de hace 10 o 15 años aún, o se tire a lo fácil de escenas scriptadas.

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: CPU vs. GPU

      @Sylver:

      Y si el disco duro es el prácticamente el componente del que más depende la fluidez del software en un ordenador… ¿por qué no aparece en este debate?

      Saludos

      Porque un buen programa evitará como sea quedarse con el culo al aire, y o hará cargas iniciales y únicas de mapeados, o un streaming del mapeado en segundo plano ANTES de necesitar los datos. No suele ser un problema, y cuando lo es un buen SSD lo arregla.

      En cambio el tema de la cpu es más voluble y siempre importante en todo juego, no se puede tener un athlon x2 y una GTX Titan y que los juegos vayan bien, por hacre una hipérbole.

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: CPU vs. GPU

      @Bm4n:

      Yo antiguamente entendía que el CPU limitara en juegos tipo estrategia que manejaban mucha info para las IA que no tenía que ver con cálculos gráficos. Pero a día de hoy si un juego no se contenta con un procesador como los actuales que pueden pasar de 100GFlops es completamente absurdo. Estos juegos tipo Borderlands, Tomb Raider es culpa de los desarrolladores que no han optimizado un cuerno, en muchos casos porque son hechos pensando en consolas y se le añade otro problema como les pasa a Crysis o Metro que ponen unas configuraciones tope exageradas quizas pensando futuro o sinceramente PUBLICIDAD.

      Lo que pasa con la carga del CPU de Tomb Raider es lo mismo que pasa si pones a funcionar el SuperPI, realmente es un hilo de proceso que en vez de ir a parar a un núcleo se alterna entre los 4, si en el administrador de tareas pones que se a afine a un nucleo verías una carga del 100% en uno de los núcleos obteniendo el mismo resultado. En Tomb Raider poner el LOD a tope no es aceptable, con lo cual lo bajas y juegas normalmente, a veces también es culpa nuestra estar obsesionados con los ajustes más altos.

      De todas en un caso normal, cosas raras como las que comentamos aparte, la limitación que le pondría el CPU a la gráfica (o el cuello de botella) sería algo así, una vez alcanza la potencia que necesita el juego la subida de FPS se estabiliza.

      Mira, yo de programar sé un poco (curro), así que te puedo decir que a diferencia de lo que piensa mucho usuario de foro o de juegos, en absoluto es trivial crear un programa multihilo que tenga A SU VEZ cada subsistema no en un único hilo, sino en varios, y que además haga un buen reparto de recursos y uso de cada core presente. Lo que pasa en Tomb Raider es lo que pasa en mil juegos, y es que el subsistema gráfico va al completo en un único hilo.

      Pocos juegos tienen este subsistema paralelizado entre varios hilos, en teoría se puede hacer pero no es un asunto trivial.

      El problema es que la situación que tú pones ocurre "normalmente" pero no siempre, porque de la misma forma que hay escenas que a nivel gráfico son mucho más costosas para la gpu y produce una bajada de fps, hay otras situaciones que pueden llevar a lo mismo a la cpu, aunque la escena en sí para la gráfica sea trivial o muy normal.

      Ejemplos, todos los que te he puesto incluido el Tomb Raider, Borderlands, etc. Añade otro a tu lista, Starcraft II, que usa multihilo y aún no tengo claro qué subsistema es el que se "sobrecarga" (motor gráfico, IA, etC), pero muchas veces se ve que la gráfica va a medio gas y tienes en plena partida variaciones de 30 a 45 fps en ciertos momentos.

      Que en este último caso es jugable de todas formas, pero sí se nota algo esto. Están ocurriendo mil veces este tipo de problemas en cantidad de juegos, y muchas veces no son sólo un momento puntual, son fases enteras o el juego completo (Dead Rising 2).

      NO son situaciones donde el rendimiento gráfico limite, porque los casos dichos son juegos relativamente normales (excepto Tomb Raider), el rendimiento en este caso está limitado por la cpu y el subsistema concreto del juego que limita el rendimiento de todo lo demás (dado que cada subsistema se "sincroniza" en un juego miltihilo para actualizar el "estado" del juego cada X tiempo, todos los subsistemas están limitados por el más lento o que más tarda en hacer sus tareas).

      O sea, que esas gráficas son muy bonitas pero no representan la realidad en multitud de juegos, y si un i5 con Oc es capaz de atragantarse con un juego, con su IPC y frecuencia a raudales, es que este juego, esté mal o bien programado (que ya digo que no es lo que mucha gente piensa lo de explotar el rendimiento en MT), en este juego el límite es la cpu.

      Llana y claramente. Y NO, 100 GFlops no tienen nada que ver con el rendimiento en juegos de una cpu, porque no se trata de machacar unas matrices enormes a base de AVX que es una tarea relativamente simple de paralelizar.

      Los juegos en absoluto son tareas tan simples, en cada uno de sus subsistemas, y más marca el rendimiento sus capacidades de ejecución avanzadas que el puro machaque de datos (ejecución especulativa, prefetch y funcionamiento de cachés y memoria, etc). O sea, que para nada "cosas tan raras".

      PD: Por cierto Bm4n, si tienes algo que comentar sobre gente y sus opiniones, hazlo por aquí. Ya sabes a qué me refiero.

      Saludos.

      –--

      Fjavi:

      Estás diciendo cosas "muy raras" de dios... a ver si te vas a estar liando. :troll:

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: Test De Prueba Real Nvidia Gtx Titan,single-sli-tri Sli,4 WAY SLI

      @ELP3:

      MaLDoHD for Crysis 2: Performance bug in Crysis 3 first level

      Puffff…. no me había fijado, claro que mi rendimiento por gráfica al ser algo interior igual no me daba cuenta (en la primera fase tampoco es que me parara mucho a ver el aguacero).

      Bastante extraño ese problema.

      Wargreymon, no seas falso y contesta a ELP3 qué te ha parecido la pequeñaja, que bien sabes que no te ha dejado ni descontento ni le has puesto sólo 4 MODs, jajaja (que mira que eres bestia con los MODs). ;D

      Ya sabes que excepto que se apure mucho la VRAM de la gráfica (al límite al límite), el tema no parecía irte "tan mal". Más si comparamos cifras con tarjetas más capaces (y con más VRAM que llenar de todas formas).

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: CPU vs. GPU

      @Fassou:

      No os preocupeis, afortunadamente ya queda poco para conocer la nueva versión de Havok, en el GDC 2013.

      Salu2!

      Err… ¿qué tiene que ver con el tema? Si todo comenzó con Tomb Raider, y el problema de ese juego es el motor gráfico, nada que ver con físicas.

      De todas formas, Havok hasta ahora no ha hehco nada que no se viera con PhysX por cpu. Mucha gente ignora hasta qué punto se usa esta variante de physX, y para sorprender a algunos voy a dar un título:

      Hitman: Absolution.

      Sí, el juego Gaming Evolved con el que se hizo pack con las gráficas de AMD. Curiosidades de la vida.

      Pero vamos, que la gente se olvide de lo de las físicas, lo que más carga en un juego es el tema del motor gráfico en la parte de la cpu que le toca, y despué a similar distancia tanto IA como física (cada una no suele pasar del 15% del rendimiento usado por un juego).

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • RE: Test De Prueba Real Nvidia Gtx Titan,single-sli-tri Sli,4 WAY SLI

      @ELP3:

      Por cierto,esos nuevos drivers de nvdia,no solo arreglan el Tomb Raider…si no que también el crysis 3..y de que manera...

      Se acabaron el problema de las cuerdas y demás..Yo,como soy masoca,le estoy poniendo todo de todo a ver que pasa..2560X1600P.Very High,8XMSAA,16XFA,Blur al máximo..pero la 4 TITANES se empeñan en mantener inalterable los 60 fps...curioso,es el primer crsysis que voy a poder jugar al máximo y 60 fps constantes sin tener que esperar años o mods..jeje

      Un saludo.

      ¿Pero qué problema es ése de las cuerdas? Que yo lo he jugado y no me doy cuenta de a qué te refieres, la curiosidad me corroe.:ffu:

      publicado en Tarjetas Gráficas
      W
      wwwendigo
    • 1 / 1