Linus Torvalds tiene algunas cosas fuertes que decir sobre Intel y la crisis de los procesadores

VW tubo suerte, resulta que al final no eran los únicos que hacían trampa. Y después quedó la duda de los que no hacían trampa, pues si es cierto o es que no se les pilló. Por ejemplo desde medios se intentó meter a BMW en el asunto, que curiosamente es la que se consideraba que ganaría más con la perdida de imagen de Audi, y cuantos bulos sobre que BMW también incumplió circularon.

hasta luego

Los beneficios de VW se tuvieron que ver seriamente afectados, durante muchos meses los precios de sus vehículos han ido a la baja, y si, han conseguido vender, pero a qué precio.

Por otro lado, VW no mantiene un porcentaje tan elevado de presencia en un mercado tan poco repartido como en el de procesadores, y menos si hablamos del entorno de los servidores donde más se notará.

Este caso es peor porque WV por lo menos tiene competencia.

Es distinto, en el caso de los coches son los usuarios finales los que eligen la marca, en el 100% de los casos. Y la mayoría de las ventas de VW son de particulares, no dependen de las ventas a empresas.

La mayoría de la gente ni se enteran de estas noticias, ni de la de VW, ni de esta mucho menos. Como mucho lo oirán de pasada, y no se enterarán de la misa la mitad. En cambio las empresas si que se preocupan por estas cosas, sobretodo cuando está en riesgo la seguridad de sus datos, y en consecuencia su negocio.

Y con las CPUs es muy distinto a los coches, porque las ventas directas al usuario final son solo una pequeña parte del total de las ventas (Solo equipos montados por piezas, lo cual es una parte ridícula de las ventas de Intel). Casi todas las ventas son a empresas, como ensambladores de PCs y portátiles y para servidores.

Los PCs se venden sobretodo para trabajo de oficinas, y ahí la seguridad es lo primero. Y los particulares compran más que nada portátiles, y ahí el mercado está cambiando hacia ARM.

Después está el mercado de servidores, que es el que más beneficios da, y es ahí precisamente donde más afecta esta vulnerabilidad. En servidores compartidos tipo Azure, AWS o Google Cloud, esta vulnerabilidad permite que desde una MV se pueda acceder a todos los datos del servidor, lo cual es gravísimo. Y obviamente estas empresas no van a montar mas CPUs de Intel de momento. Ya sin esta vulnerabilidad este mercado estaba también virando hacia ARM, y sin duda con esta noticia se acelerará el cambio.

Va a ser un año MUY duro para x86, y sobretodo para Intel, porque a AMD no le afecta tanto esta vulnerabilidad, y además también tiene el negocio de gráficas y consolas, lo cual no tiene Intel.

si cae no será por ésto

esto... si no fuera porque los últimos Cortex-A de ARM están afectados por spectre 2 y tal...

No se trata de eso, de eso no hablaba Linus.

Sino de la cutre, en varios sentidos maléfica respuesta que dio Intel, junto a acciones como el hecho de vender los Coffee Lake sabiendo de antemano el problema.

Es decir, en Intel se pasan de ególatras.

Eso lo desean solo los fanáticos de AMD. Que dañará su imagen? seguro que si. Pero de ahí a que sea el fin de Intel lo dudo muchísimo. Yo acabo de comprarme un procesador nuevo y lo he hecho a pesar de todo esto, por qué? pues simplemente porque AMD no me ofrece ni por asomo la misma durabilidad de que me da Intel. He tenido un AMD, y tuve que "tirarlo" a los 3 años, me pillé un Intel en 2008 y aún sigue dando guerra, simplemente lo cambio por necesidades de edición de video 4K, pero en FullHD sigue como el primer día. Eso lo siento, no me lo ofrece AMD y dudo mucho que ARM pueda dármelo también.

¿Sabes que eso que acabas de comentar es una tontería no? probablemente tenías un problema de refrigeración o la avería viene de otro sitio. Fíjate, yo tengo todavía funcionando un AMD Athlon 900 del año 1999, un AMD XP 2600 del 2003, un Phenom del 2008 y un Phenom 2 del 2010, y así todo el mundo. Otro tema es que comprases una placa base cutre y le echases la culpa al micro

Es lo primero que pensé, no se entiende nada.

Para que no haya confusión, el texto original:

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

- Intel never intends to fix anything

OR

- these workarounds should have a way to disable them.

Which of the two is it?

Lo que provoca que el procesador esté a la espera no son los condicionales.

Primero de todo, un procesador no entiende un if y un else, para ejecutar saltos condicionales los procesadores trabajan con los flags (N, C y Z son los básicos y comunes en todas las arquitecturas), y los flags se modifican tras la ejecución de (Casi) cada instrucción.

Lo que provoca que el procesador esté a la espera es la velocidad del resto de componentes (Memoria principal básicamente, y también periféricos), que es muy inferior a la del procesador.

Es por esto que el procesador se inventa los datos a ejecutar y una vez los recibe, si coinciden, es trabajo que ha adelantado.

Puede que el salto se produzca después de un condicional, o puede que sea un salto incondicional. por eso la condición en este tema es irrelevante. Porque para hacer un salto y esperar a recibir datos no hace falta ningún condicional. No se de donde sacas esa relación. Y el ejemplo de IF y ELSE es del todo desafortunado.

La relación viene de que cada instrucción tarda varios ciclos de reloj en ejecutarse, depende de la longitud de la pipeline del procesador de ahí viene el IPC (instrucciones por ciclo). Por ejemplo, la pipeline del pentium 4 presscot es de 31 etapas, así que para ejecutar una instrucción al menos se tarda 31 ciclos de reloj. Una vez que la pipeline está llena, se puede llegar a terminar una instrucción por ciclo, usando técnicas de ejecución en desorden, ejecución especulativa, hyperthreading, VLIW etc. Justo las instrucciones que más perjudican son los saltos, ya que obligan a vaciar la pipeline (creando lo que se llama una burbuja) y esperando otros 31 ciclos hasta volver a obtener resultados. Lo que se hace en cada etapa de la pipeline a nivel de registros y de unidad de control es lo que se conoce como microcódigo y es precisamente lo que actualizan algunos parches para corregir estas vulnerabilidades.

De hecho el tratamiento de saltos es tan crítico que se invierte muchísimo en predictores de salto, e incluso se combinan varios predictores en la misma CPU. En https://en.m.wikipedia.org/wiki/Branch_predictor se ve un diagrama de pipeline de 4 etapas y se comentan por encima distintas técnicas de predicción de salto.
A lo que te refieres con la lentitud del resto de componentes al acceso a memoria y a la entrada/salida, que van órdenes de magnitud más lentos. Eso se intenta resolver con una jerarquía de memoria con varios niveles de caché en los que se eligen cuidadosamente los tamaños de página, el número de vías, la asociatividad, el protocolo de invalidación de líneas, la estrategia de writeback (moesi, mesi, dragon... ) e incluso caché dedicada a datos y caché dedicada a instrucciones. Casualmente el bug de meltdown aprovecha que la ejecución especulativa carga en caché zonas de memoria protegidas antes de resolver los privilegios y midiendo tiempos de acceso con resolución de nanosegundos se puede llegar a inferir el dato de la memoria de otro proceso.

Aunque el acceso a memoria es lento, el acceso a registros es ultra rápido, por eso se puede seguir procesando a todo lo que permite la velocidad de reloj.
Justamente uno de los trucos que usaba Linus Torvalds para compilar el kernel mucho más rápido era utilizar el máximo posible todos los registros de la CPU disponibles.

En cuanto al IF ELSE, al compilar se traducen en un salto condicional + salto incondicional relativo. Si la condición es válida sigue ejecutando y si no, salta al else, así con ejecución especulativa, antes de saber el resultado de evaluar la condición, el procesador empieza a ejecutar tanto la siguiente instrucción al condicional, como la primera instrucción después de saltar (el else).

Si se ha experimentado una pérdida del 30% de rendimiento en servidores y demás, dado que las ejecuciones fuera de órden eran una función que aumentaba el rendimiento en tareas muy intensivas con cambios de instrucciones bastante grandes.

La obsolescencia programada pasa al siguiente nivel, ahora para arreglar cada agujero que salga hay que cambiar el hardware.
No creo que esto sea ningún accidente sino que intel se aprovecha de que no tiene competencia.

Y que vas a comprar? todos estan jodios

AMD

Que tiene que ver con los huesos

Pero no nos tenemos que aguantar olímpicamente las embarradas de Intel porque si, ellos cometieron un error y deben responder por eso y más cuando su tecnología es la base de muchas empresas a nivel global.