rockworld escribió:Pregunta: cual de los 3 ryzen que hay es el que vale la pena comprar?
Sin duda el 1700. Es el más barato y para el OC que tienen, que es poco margen, al final colocas a éste en el mismo lugar que los superiores. Sin OC es algo más lento, pero me parece que es el más "amigable" con el usuario en cuanto a facilidad de subirlo sin aumentar mucho los consumos al nivel de los demás, y no romperse después mucho la cabeza para arañar unos pocos MHz más a costa de subir el voltaje.
Metalhead escribió:vergil escribió:Joseahfer escribió:@vergil y sin embargo compite muy bien contra el i7 7700K en juegos.
Por eso lo digo, y aun asi, muchos hechando pestes.....yo lo flipo.
tengo un 4670k a 4.5ghz, pero voy a cambiar a Ryzen, eso lo tengo claro.
Ni pestes ni nada, el hype que se había formado la semana anterior no lo recuerdo yo con ningún producto. Ahora que ha salido se ha visto que ha sido un avance brutal pero no de la magnitud que se venía comentando (de arruinar a Intel ni más ni menos). Y no somos nosotros en un foro los que lo dicen:
Es que lo de la hype tiene delito, el rendimiento actual se preveía, y de hecho se puede considerar que para productividad es una cpu muy buena (para quien necesite una cpu robusta para esto), ahí ni siquiera ha fallado respecto a las mejores expectativas provocadas por AMD.
Pero claro, la gente se inventa OCs altísimos que no hubo (gracias a dios no colaron demasiado dichos rumores, porque salieron otros en contra, pero alguno habrá picado en el anzuelo), que si se inventaban que el IPC sería superior a Skylake por no se qué de un test sintético (otros picaron y no pocos ahí) y después otros rumores inventándose rumores sobre que si su rendimiento en juegos sería estelar.
Lo triste es que igual que la hype elevó las expectativas ahora se está haciendo lo contrario, denostando a una cpu que cumple bastante bien en casi todos los puntos.
Es casi estelar en productividad, y decente en juegos, eso ya es cumplir con nota. Hombre, no derrota en todos los campos a intel, pero esperar eso es estar en Chupilandia. El simple hecho de que ponga a intel contra las cuerdas en algunos campos ya es algo más que bueno.
Pero nada, al final pasa lo de siempre, se pasa de un extremo al otro, la bolsa es muy dada a esa forma de funcionamiento casi maníaco.
Gromber escribió:Pero el problema es el monopolio intel en el desarrollo de los videojuegos, a parte de otros juegos que no aprovechan los 8 nucleos.]
Vamos a ver, eso no tiene ni pizca de sentido. Ni la parte de "monopolio" de intel en el desarrollo de juegos (cuando las únicas empresas que consistentemente se acercan a éstos no son los fabricantes de cpus, sino los de gpus), ni lo de no aprovechar los 8 núcleos.
Es lo típico que se dice cuando no se sabe cómo funciona el desarrollo de cualquier aplicación y sobre todo juegos, yo como programador algo puedo hablar del tema, y precisamente los juegos no son nada fáciles de dividir en hilos que estén bien EQUILIBRADOS para la carga de los distintos cores de una cpu, pues cada subsistema es heterogéneo en la carga de trabajo.
En realidad la mayoría de juegos AAA están divididos en muchos más hilos que cores disponibles, de largo. Otro asunto es que esto se traduzca en un balanceo automático de carga en cada core cercano al 100%, eso es muy difícil lograr y más con cpus con cada vez más cores.
Lo que AMD está haciendo es en gran medida tirar balones fuera con sus declaraciones, y la gente además empeora las cosas entendiéndolo mucho peor que lo que realmente implica.
Lo que AMD está diciendo, con la boca pequeña porque no quiere admitir de dónde viene en realidad ese rendimiento más bajo en juegos, es que el diseño en CCXs de sus cpus provoca un problema de rendimiento tanto por como funciona windows (que rebalancea hilos entre distintos cores, lo cual es muy malo cuando un hilo cambia de CCX) así como el hecho de que los desarrolladores usan los multicore asumiendo unas lógicas reglas sobre cómo son estas cpus:
1.- Si una cpu no tiene SMT, todos los cores son equivalentes.
2.- Si una cpu tiene SMT, se asume que la mitad inicial del nº de cores virtuales representa a cada core físico y el primer hilo que puede ejecutar, la segunda mitad se asume que son cores puramente virtuales corriendo en paralelo y dentro de los cores anteriores, ya con hilos ejecutándose.
Esto es: Un quadcore con SMT:
0 1 2 3 4 5 6 7 cores, 0 1 2 3 representa a cada core físico y ahí puedes correr tranquilamente hilos "pesados" sabiendo que tienen todos los recursos. 4 5 6 7 son cores virtuales y ahí puedes correr hilos "ligeros" para sacar rendimiento extra, se deben evitar que corran ahí hilos pesados en paraleo a los otros hilos pesados.
En este caso en el core 0 y 4, que son en realidad el mismo, no deben correr sistemas demasiado pesados a la vez.
El problema es que Ryzen acaba en parte con esta lógica porque ha añadido un tema exta a esta lógica, al existir 2 CCXs separados y en realidad con L3 separadas y que no rentan acceder a ella desde el CCX anexo, se mete un nivel extra de complejidad a esta ecuación.
Ya no se trata de sólo tener en cuenta los cores reales y virtuales, es que además hay que tener en cuenta los cores "cercanos", se rompe la homogeneidad anterior existente (también con cpus como las de AMD, que conste), y ahora hay que tener en cuenta que hilos que funcionen con datos que también usan otros hilos DEBERÍAN ejecutarse dentro del mismo CCX.
Esto es, en un Ryzen ahora hay (suponiendo un ordenamiento similar a lo que se suele estilar):
0 1 2 3 4 5 6 7 cores reales. De los cuales 0 1 2 y 3 están en el primer CCX, 4 5 6 7 están en el segundo CCX.
Después además hay 8 9 10 11 12 13 14 t 15 cores virtuales. De los cuales 8 9 10 y 11 están en el primer CCX, y 12 13 14 y 15 están en el segundo.
Varios hilos que tengan relación deberían ejecutarse o en 0 1 2 3 8 9 10 y 11, o en 5 6 7 8 12 13 14 o 15. Digamos que 3 hilos relacionados (física, por decir) se ejecutan, pensando como suele normal que la cpu es "normal" en estructura (desde el punto de vista del programador, o mejor dicho, desde el scheduler de windows más probablemente, aunque el desarrollador algo puede forzar aquí), en 3 4 y 5 pensando que son cores físicos porque con las reglas típicas así sería. Bueno, pues entonces en realidad aunque sí fueran cores físicos, tocaría uno en un CCX y otros dos en un CCX distinto, y en cada caso donde compartieran datos y la necesidad de acceder a la L3 esto sería desastroso en rendimiento dado necesitar acceder al otro CCX una y otra vez.
En el caso de los hilos en cores virtuales, lo mismo, aunque estén bien identificados como tales, no se tiene en cuenta la "afinidad" necesaria para evitar esos problemas de caché.
Eso explica todos los problemas vistos en juegos (que tampoco son tantos) y en parte porqué recupera bastante en juegos al desactivar SMT. No es ninguna conspiración de los desarrolladores con intel, sino que la forma en que funcionan los Ryzen es nueva y tiene reglas extra de "afinidad" a tener en cuenta, que lógicamente no se han tenido en cuenta ni por el scheduler de windows hasta ahora ni tampoco por los desarrolladores.
Hay que ver menos conspiraciones. Posiblemetne con parches de juegos y windows esto se arregle aunque sea parcialmente (con esto quiero decir que no necesariamente implica que el rendimiento se vaya a los niveles de los intel, pues la latencia a memoria es la que es, alta, y en donde influya mucho lo seguirá haciendo, aunque menos si los hilos no se hacen la picha un lío entre ellos y están "al lado" de los que sean "de su palo").
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
