CPU vs. GPU
-
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.
-
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.
-
¡Esta publicación está eliminada! -
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).
-
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:
!
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
-
El debate ha tomado rumbo fijo hacia las arquitecturas de CPU y su rendimiento, pero se nos escapa el principal detalle…
A la hora de la verdad vamos a seguir todos igual: a expensas de lo que los fabricantes saquen (siempre entendiendo que será mejor que lo ya existente), de los valores que los primeros y principales test arrojen y de lo que nuestro bolsillo nos pueda permitir...Viendo lo pesos pesados que sois en la materia, creo que no llegaréis lejos confrontando las hipótesis conocidas sobre futuros desarrollos que a priori batirán lo actual o que aparentemente se quedarán cortos respecto a lo esperado, mayormente por lo anteriormente mencionado.
No pretendo cortar el debate ni mucho menos, que continúe que se están exponiendo muchas cosas interesantes, pero sólo quería recordar ese detalle, y solidarizarme con quienes como yo se limitan a leer y a reflexionar en este debate :sisi:Saludos
-
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__ 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
El problema está en que no es lo mismo paralelizar un juego que paralelizar un programa de codificación de vídeo por ejemplo. En un programa de codificación de vídeos, si tienes que comprimir por ejemplo 8 vídeos de X longitud siempre puedes comprimir cada uno de ellos usando un núcleo (O coger un vídeo largo y que cada núcleo procese una parte temporal), eso es un buen ejemplo de una aplicación fácilmente paralelizable.
El problema de los juegos es que esa división no se hace así (Salvo que juegues a 8 juegos a la vez y quieras que cada uno te use 1 o 2 hilos :ugly:), la mayoría de juegos suelen dividir los subprocesos de forma que cada núcleo procesa algo más o menos independiente; Un núcleo para la IA, otro para el sonido, otro para físicas…
El problema de eso es claro, que no requiere la misma capacidad computacional la IA que el sonido por ejemplo, así que de alguna forma el problema es que tienes un claro desequilibrio en cuanto al empleo del multihilo. Por cosas así no veo la ventaja a los Bulldozer en su estado actual, por que se suelen dar casos en juegos donde un núcleo tiene mucha carga y otro tiene una carga muy baja, y por lo tanto, contra más potente sea el núcleo que tiene la mayor carga, mucho mejor, de otra forma te va a limitar completamente el rendimiento, por eso me empeño tanto en el tema del ipc, por que el problema no es solo la programación multihilo en sí, sino conseguir un equilibrio entre todos los hilos/núcleos usados para que no haya 1 o 2 núcleos, completamente saturados al 100% de capacidad, mientras los otros 6 están uno al 5%, otro al 10% , otro al 30% y el resto al 25%. Surge un claro desequilibrio en el rendimiento multihilo que no vas a tener si codificas un vídeo en cada núcleo, por que en ese caso vas a tener una carga multihilo equilibrada donde todos los núcleos van a ir al máximo.
La conclusión de todo esto es que sí, en el ejemplo que pones se observa que con más núcleos se obtiene mayor rendimiento (Esto es una de esas cosas obvias que nadie está discutiendo, haciendo mías tus palabras) pero es muy dependiente de la aplicación, y esto siempre, una aplicación de render y una aplicación de compresión en .zip realizan cálculos completamente diferentes dentro de la CPU, y eso hay que tenerlo en cuenta por que para una CPU no es lo mismo una suma, que una división con decimales o una multiplicación vectorial, son operaciones distintas que condicionan el comportamiento interno de la CPU, y en ese sentido surgen importantes diferencias a la hora de comparar las diferentes arquitecturas (Vease el escaso rendimiento de los Bulldozer/Piledriver con instrucciones AVX).
-
¡Esta publicación está eliminada! -
El problema está en que no es lo mismo paralelizar un juego que paralelizar un programa de codificación de vídeo por ejemplo. En un programa de codificación de vídeos, si tienes que comprimir por ejemplo 8 vídeos de X longitud siempre puedes comprimir cada uno de ellos usando un núcleo (O coger un vídeo largo y que cada núcleo procese una parte temporal), eso es un buen ejemplo de una aplicación fácilmente paralelizable.
El problema de los juegos es que esa división no se hace así (Salvo que juegues a 8 juegos a la vez y quieras que cada uno te use 1 o 2 hilos :ugly:), la mayoría de juegos suelen dividir los subprocesos de forma que cada núcleo procesa algo más o menos independiente; Un núcleo para la IA, otro para el sonido, otro para físicas…
El problema de eso es claro, que no requiere la misma capacidad computacional la IA que el sonido por ejemplo, así que de alguna forma el problema es que tienes un claro desequilibrio en cuanto al empleo del multihilo. Por cosas así no veo la ventaja a los Bulldozer en su estado actual, por que se suelen dar casos en juegos donde un núcleo tiene mucha carga y otro tiene una carga muy baja, y por lo tanto, contra más potente sea el núcleo que tiene la mayor carga, mucho mejor, de otra forma te va a limitar completamente el rendimiento, por eso me empeño tanto en el tema del ipc, por que el problema no es solo la programación multihilo en sí, sino conseguir un equilibrio entre todos los hilos/núcleos usados para que no haya 1 o 2 núcleos, completamente saturados al 100% de capacidad, mientras los otros 6 están uno al 5%, otro al 10% , otro al 30% y el resto al 25%. Surge un claro desequilibrio en el rendimiento multihilo que no vas a tener si codificas un vídeo en cada núcleo, por que en ese caso vas a tener una carga multihilo equilibrada donde todos los núcleos van a ir al máximo.
La conclusión de todo esto es que sí, en el ejemplo que pones se observa que con más núcleos se obtiene mayor rendimiento (Esto es una de esas cosas obvias que nadie está discutiendo, haciendo mías tus palabras) pero es muy dependiente de la aplicación, y esto siempre, una aplicación de render y una aplicación de compresión en .zip realizan cálculos completamente diferentes dentro de la CPU, y eso hay que tenerlo en cuenta por que para una CPU no es lo mismo una suma, que una división con decimales o una multiplicación vectorial, son operaciones distintas que condicionan el comportamiento interno de la CPU, y en ese sentido surgen importantes diferencias a la hora de comparar las diferentes arquitecturas (Vease el escaso rendimiento de los Bulldozer/Piledriver con instrucciones AVX).
Aaanda que todo son problemas! :ugly: jajaja.
Codificando video no haces varios a la vez, simplemente tienes un montón de datos (cuadros, macro bloques, etc.) que se pueden repartir, sí no es complicado de dividir pero igual que pasa con la mayoría de las tareas de más consumo para la CPU. Y los benchs marcan FPS al codificar un video. Verás que los mejores resultados son de los Intel de 6 núcleos, 4+HT, 4, y en 2nd pass los FX-8 en segundo lugar.
El mayor problema de los juegos (y en general de tareas complejas con procesos entrelazados) como decía wwwendigo es la sincronización, sino tendrás problemas como el microstuttering famoso. Te doy toda la razón, si el soft no lo utiliza es una estupidez. Pero el tema es que puede usarlo y ya lo hace y aunque con limitaciones dependiendo de la tarea, es algo que se va a usar más, en juegos motores como Frostbite o CryEngine lo usan muy bien; que sí el Creation Engine de Bethesda aun no… pero eso no es el futuro, es el pasado.
Con el tema de las diferentes cargas de las distintas tareas dentro de un juego: aparte del trabajo que haga el motor gráfico en repartirlas, yo comentaba el balanceo de cargas por parte del CPU y ya no solo a nivel de micro-ops sino de macro-ops, el SO tiene que ser capaz de optimizar los recursos y de que si tienes en un juego 10 procesos y cada uno con X dependencia del CPU poder distribuirlos no solo aleatoriamente. En el futuro caso imagina un 2600 por ejemplo, te da unas posibilidades muy grandes porque tienes 4 hilos donde puedes poner procesos de gran carga y otros 4 donde poner tareas "de relleno", anda que no es mejor eso que tener solo 1 o 2 hilos donde se procesa todo uno detrás de lo otro. Habría que lograr velocidades estratosfericas para igualar el rendimiento, por eso el multihilo si es un avance, pero vamos creo que discutir esto es sumamente obvio; en todo caso podríamos discutir cuantos hilos vs IPC sería razonable, lo otro no tiene apenas discusión.
Y todo esto venia a cuento de como los juegos actuales empiezan a utilizar más CPU que antiguamente y comentábamos como hay juegos muy mal optimizados que provocan que el CPU limite las FPS de la GPU. Y decía que conforme esto avance este problema irá desapareciendo porque se aprovecharán más los diferentes núcleos porque si solo se usa un hilo se desperdicia mucha potencia de CPU; o quizás sea al revés y al tener procesadores com mas paralelismo los motores gráficos releguen más tareas al CPU.
Pero por ahora con contadas excepciones no es necesario ni un CPU con OC ni uno de 6 núcleos para PODER jugar a los juegos actuales. Si hablamos de jugar siempre a tope o de jugar con 3 monitores entonces puede que sí. Que como dice Sylver nos hemos ido de tema, y el bulldozer creo que ya lo tenemos más que visto al pobre.
-
Aaanda que todo son problemas! :ugly: jajaja.
Codificando video no haces varios a la vez, simplemente tienes un montón de datos (cuadros, macro bloques, etc.) que se pueden repartir, sí no es complicado de dividir pero igual que pasa con la mayoría de las tareas de más consumo para la CPU. Y los benchs marcan FPS al codificar un video. Verás que los mejores resultados son de los Intel de 6 núcleos, 4+HT, 4, y en 2nd pass los FX-8 en segundo lugar.
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.
-
Tengo ganas de ver "en persona" el Haswell, a ver que tal. Y por el momento pues sí, yo me quedo con mi Sandy que va de lujo. Lastima que no haya más alternativa como dices, pero en parte comprendo a AMD los tíos dijeron: "no hay pasta para I+D y necesitamos algo para hacer frente a Intel, pues sacamos procesadores de 8 núcleos y que compartan el máximo para que el TDP sea factible, además de cara a publicidad vender de primeros 8 núcleos queda bonito…" y así salió bulldozer que hasta el nombre es feo :risitas:
-
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.
-
¡Esta publicación está eliminada! -
Tengo ganas de ver "en persona" el Haswell, a ver que tal. Y por el momento pues sí, yo me quedo con mi Sandy que va de lujo. Lastima que no haya más alternativa como dices, pero en parte comprendo a AMD los tíos dijeron: "no hay pasta para I+D y necesitamos algo para hacer frente a Intel, pues sacamos procesadores de 8 núcleos y que compartan el máximo para que el TDP sea factible, además de cara a publicidad vender de primeros 8 núcleos queda bonito…" y así salió bulldozer que hasta el nombre es feo :risitas:
Yo la principal desventaja que veía a AMD es el proceso de fabricación, además supongo que no puede invertir tanto en I+D y tener un proceso de fabricación menos avanzado, si AMD tiene que fabricar a 32nm y Intel lo hace ya a 22nm icluso parece que no le falta mucho para pasar al próximo nodo,asi no se puede competir, siempre Intel va a meter mas en menos espacio y va a ganar en consumo.
Intel además de cambiar socket cada dos por tres metio un ritmo con el Tic Toc que AMD no podía seguir por mucho tiempo, mas que nada por depender de otros para la fabricación de sus chip.
Intel es una oligarquía, como aquí las hidroeléctricas o las de hidrocarburos, no dejan competir a nadie y terminan asfixiandolos.
saludos
