"Con la CPU AMD EPYC hemos sido capaces de mostrar más de un Terabit por segundo de datos sostenidos que fluyen de los servidores durante días. Lograr esto en un solo servidor en lugar de requerir una superordenador, como fue el caso en el pasado, es un avance significativo", dijo Niko Neufeld, líder del proyecto del CERN. En español:
www.profesionalreview.com/2020/06/25/amd-trabaja-cern-expansion-lhc/
Edit: "First new high performance series of server CPUs offered by AMD since 2012"
Uff, eso tiene que doler, que te digan "no has sacado nada decente en 8 años" aunque se estén redimiendo por la puerta grande.
Eso es la situación actual, y dentro de medio año, cuando salgan las consolas de nueva generación con 16 hilos, los requisitos mínimos se dispararán y los i3 de 10ª gen no podrán mover más que indies.
Pensaba que mayormente perjudicaba tareas de server, como bases de datos, y afectaban poco a juegos.
El unico ejemplo de juegos que se me ocurre es el de RPCS3, el emulador de PS3, pero al ser un emulador de una arquitectura rara es un caso especial.
Por mi parte, pronto tendré que renovar mi portatil (se cae a pedazos, LITERALMENTE) y me gustaría coger uno con un Ryzen 7 4xxx potente, pero casi no hay ninguno... he visto Ryzen 3xxx, pero hay un salto importante de rendimiento y consumo (y nanometros) entre generaciones y prefiero la nueva)
A los UltraSPARC les pasó que eran muy buenos con cálculos enteros y podían procesar un montón de cosas simples (en BBDD y servidores web eran unas máquinas, una pena que ORACLE comprara SUN y no les hiciera mucho caso), pero en capacidad de proceso y cálculo puro y duro se quedaban muy atrás respecto a la competencia. Lo mismo le pasó a AMD con sus bulldozer y derivados, en multiproceso podían ser competitivos, pero cuando tocaba fuerza bruta sus CPUs eran muy débiles.
Ahora la estrategia de AMD es casi la misma. Si, ahora la potencia de cada core es muchísimo mayor, a la par que Intel, pero siguen juntando muchos cores (consiguieron una tecnología que resolvía algunos de sus problemas y ahora les es muy sencillo y barato juntar cores sin perder rendimiento) y los hacen tanto o más eficientes que los de Intel a precios más baratos (ahora AMD fabrica en nodos más pequeños, también es cierto que es porque Intel se quedó atrás y ha tenido muchísimos problemas con su tecnología).
Sobre lo de la innovación, el frenazo es en todos lados. Lo que más evolución está teniendo son las cachés (para poder mantener su coherencia y ser eficaces en entornos heterogeneos o con muchos cores), la predicción de ejecución de código (cruciales para elegir la próxima instrucción, tanto a nivel de búsqueda como de ejecución, y no tener que vaciar lineas de ejecución y mantener la maquinaria a tope) y la interconexión de componentes hasta donde yo sé.
Evidentemente, también depende mucho del modelo. Quizá el que tengas tú no pierda apenas nada con las mitigaciones.
Es posible desactivar mitigaciones en Linux con una linea en el GRUB, pero eso solo desactiva mitigaciones del kernel/SO, ¿no?
Las mitigaciones del microcodigo de Intel y las de la BIOS seguirían activas, ¿no?
wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/Mitigati
wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/Mitigati
Los microcódigos son "pequeñas instrucciones que se ejecutan cuando se ejecuta una instrucción". Si no lo sabes, las arquitecturas modernas x86 (a partir del 486 en adelante, si no recuerdo mal) no son CISC sino RISC. Así, cada instrucción del juego de instrucciones de las CPUs de Intel o AMD se reduce a microinstrucciones, que son las que realmente se ejecutan. La parte interesante es que pueden actualizarse, no sólo vía flash sino durante la carga del sistema operativo. Muchas mitigaciones se han realizado en plan "cambiamos ligeramente cómo se ejecuta una instrucción"; el problema es que el hardware es hardware, puedes meter microinstrucciones por medio o cambiar algún paso en la ejecución de una instrucción, pero luego viene lo que está fijo y si hay fallo ahí, el fallo seguirá estando. Evidentemente, por eso se llaman mitigaciones (no arreglan nada, dificultan lo máximo posible el poder explotar el fallo que existe).
Una vez dicho todo esto ¿puedes cargar ficheros de microinstrucciones antiguos "para evitar las mitigaciones"? la respuesta sigue siendo sí. Otra cosa es dónde encontrarlos (hasta donde yo sé, hay repos con los últimos, pero no sé si tienen historial).
www.pcsuggest.com/update-cpu-microcode-in-linux/
downloadcenter.intel.com/product/873/Processors
Por otro lado, las mitigaciones de BIOS... ¿te refieres a microcódigo? porque a nivel de BIOS en placa y demás no entiendo que puedas mitigar nada (como mucho, desactivar por defecto el uso de hyper-threading). Igualmente, si tienes la BIOS correspondiente, puedes actualizarla (con el software para hacerlo que provea el fabricante de la placa).
Pero creo que lo que realmente les ha ayudado es el ofrecerse a realizar arquitecturas "custom" a terceros (lo que ha propiciado que fueran los elegidos para las consolas de la actual y nueva generación más gamecube y wii, lo que ha propiciado contratos jugosos de colaboración con china (en.wikipedia.org/wiki/AMD–Chinese_joint_venture), esos ingresos son los que han ayudado a meter dinero para poder avanzar y poder cumplir plazos y previsiones y dar garantías sobre sus productos. Y todo esto se fraguó antes de Lisa Su (que esta haya sabido tomar las riendas y dirigir bien el negocio tiene su mérito también y no se lo quito, cualquier paso en falso, cuando AMD llevaba muchísimos años sin obtener beneficios y demás).
También te digo que el que Intel esté débil (en cierto sentido, sigue teniendo muchísimas más ganancias que AMD) y buscando mercados y salidas ayuda también a buscar alternativas. Y ahora mismo, la empresa de confianza es AMD.
Los 14 nanómetros de samsung o GFO tienen un nodo de 17 nm
Los 7 nm de TSMC tienen un nodo real de 9,2 nm, o sea, serían equivalentes a los 10 nm de intel. (www.geeknetic.es/Editorial/1406/La-realidad-sobre-los-nanometros-en-pr)
Aún así, Intel está teniendo problemas para sacar procesadores de alto rendimiento a 10 nm (solo consiguen con foveros, en chips de 5 núcleos con cores combinados para bajo consumo), así que AMD les está comiendo la tostada y con mucho mérito la verdad (y menos mal, porque hacía falta algo de competencia)
En procesadores de portátiles, la diferencia es abismal ahora mismo, el Core i7-10750H es lo mismo que el 9750H y que el 8750H en rendimiento basicamente, llevan 3 generaciones vendiendo lo mismo con pequeñas variaciones de mhz. Los ryzen 4800H los superan por más del 50% y con menos consumo..., en rendimiento multi
-hilo y también en single-core.
Ahora hay ya varios portátiles con ellos (el ASUS g14 con los HS que rinden muy parecido y con 10W menos), el tuf A15, MSI también tiene...
Mi proximo portátil tendrá uno de eso casi seguro.
wccftech.com/amd-explosive-market-share-growth-server-notebook-segment
Empezó a lanzar sus APUs pensando precisamente en esto. Estas APUs en realidad no eran más que CPUs con gráficos integrados bastante potentes. Al menos, lo eran en relación con los integrados de su competencia. Además de, lógicamente, tener gráficos mejores para juegos, la idea era disponer de una GPU que, aun siendo de gama baja, era MUY superior a cualquier procesador en cuanto a cálculos en coma flotante.
Por poner números redondos, una CPU puede rondar los 100 GFLOPS de capacidad de cálculo en coma flotante, en el mejor de los casos (cifras de hace unos años, pero no creo que haya cambiado mucho) mientras que una GPU puede irse a los 10 000 GFLOPS (no sobran ceros), especialmente las de la época.
En aquella época AMD trabajaba con arquitecturas VLIW , las HD 4xxx y HD 5xxx, que se hacían también pensando en dar esa capacidad de cálculo descomunal en coma flotante. De hecho uno de sus argumentos de venta era precisamente la capacidad en coma flotante, en concreto en doble precisión, MUY superior a las de las Fermi (GPUs NVIDIA) de la época (ejemplo: www.reddit.com/r/Amd/comments/9dsz5p/should_amd_bring_back_vliw_for_a_). Finalmente tras ver que esta carrera por los GFLOPS no iba a ninguna parte, abandonaron el plan y las GPUs posteriores ya daban cifras menores en TFLOPS (pero mejores en juegos).
La arquitectura Bulldozer también fue concebida con todo esto en mente: por cada 2 núcleos completos para enteros, una unidad FPU compartida. Prácticamente lo opuesto al Hyper-Threading de Intel, pero terminaron siendo denominados igual, 8/16, cuando hubiera sido más acertado al contrario, 16/8. Si comparas el rendimiento en enteros de un Bulldozer con un i7 de la época, el primero era sensiblemente superior en ese apartado, y esto se podía ver reflejado en resultados de pruebas que dependieran de este tipo de cálculos, pero cuando comparabas el rendimiento en coma flotante, la comparativa le hacía sonrojar.
Por aquel entonces se empezó a meter CUDA y el GPGPU de AMD en todas partes y parecía que finalmente AMD iba a tener razón, que era cuestión de tiempo que su idea de la CPU potente en enteros y débil en coma flotante fuera a triunfar... Pero finalmente quedó en nada. Al final los Bulldozer pasaron con más pena que gloria porque era un truño para un uso general, salvo en varios aspectos muy nicho donde brillaban frente a los i7 de la competencia.
En 1993 me compré un 386 a 40 Mhz, en 1998 lo cambié por un Pentiun II a 350 Mhz y otros 5 años más tarde compré un Athlon XP 2600+
El salto en 10 años de un 386 a 40 Mhz con 4 MB de RAM a un Athlon XP a 2600 Mhz con 512 MB de RAM es muy superior al que hay de los Core2Duo / Core2 Quad de hace 10 años a los procesadores actuales de 2 ó 4 núcleos, que aunque sean los más sencillos hoy día pueden seguir siendo útiles. En 2003 un 386 de 1993 ya no te valía para nada.
La idea era: tenemos CPUs que hacen muchas tareas y tienen bloques dedicados a cálculo vectorial (instrucciones SIMD), tenemos GPUs que ya no son bloques estáticos de ejecución de operaciones con matrices sino completamente programables (básicamente CPUs con muchos bloques de instrucciones SIMD en paralelo para la rasterización), hagamos un bloque más generalista capaz de decodificar y ejecutar instrucciones x86 y (ponga aquí la ISA que usen las GPUs de AMD) de forma que podamos aprovechar y compartir todos los componentes posibles entre ambas (por ejemplo, todo el acceso a memoria es compartido, evitando copias de datos innecesarias, pero a su vez lastraba el rendimiento de la parte GPU dado que las gráficas suelen tener memorias mucho más rápidas que las CPUs y hacía a las APUs muy dependientes del ancho de banda para rendir adecuadamente, véase el caso de las consolas xbox one y playstation 4 como paradigmáticos de esto). El objetivo era: más eficiencia energética, ahorro de costes de producción y por lo tanto aumentar el margen de beneficios, aumento de eficacia y capacidad de computación. Como bien dices, el vender procesadores "simples" que podían acelerar tareas pesadas usando OpenCL era uno de los objetivos, pero no el único. De hecho, integrar CPU y GPU de manera monolítica fue una de las razones por las que se les fuera la mano en el precio de fabricación, al consumir más de la cuenta no les salían competitivas en el mercado de portátiles y entre unas cosas y otras no vendían y por lo tanto no sacaban margen de beneficios (ahora mismo han enfocado las APUs al sector móvil porque las vegas pequeñas consumen muy poco, fíjate que ya no hay tantas apus en escritorio).
Otra cosa es que no se pudiera o no fuera eficaz integrar tantas cosas como pensaran en un principio (por ejemplo, las precisiones de ejecución y/o la forma de calcular en punto flotante son distintas en las gpus y las cpus; los módulos de cálculo de números flotantes hasta donde yo sé están separados). Según Nvidia (que no tiene por qué coincidir con cómo ha implementado AMD, pero que da una idea de las diferencias entre CPU y GPU):
"NVIDIA GPUs differ from the x86 architecture in that rounding modes are encoded within each floating point instruction instead of dynamically using a floating pointcontrol… » ver todo el comentario