Portada
mis comunidades
otras secciones
#10:
El artículo es muy bueno, la mejor parte es dónde explica las diferencias entre la arquitectura RISC de los ARM y la CISC de Intel/AMD.
Explica bien por qué las instrucciones ARM, que tienen un tamaño fijo, son más faciles de paralelizar en múltiples decoders de instrucciones, mientras que las CISC, que tienen longitud variable, no tanto. Y es tan sencillo como entender que para las instrucciones RSIC se sabe donde empiezan y donde acaban (todas miden 32bit) mientras que las CISC x86 miden de 1 a 15 bytes.
Por tanto, al ser las CSIC de longitud variable, hasta que no se decodifica una instrucción no se sabe donde empieza la siguiente.
Esto puede parecer que no es muy importante, pero sí lo es, porque los RISC pueden "comerse" instrucciones en paralelo sin límite, de 8 en 8 como el M1, de 16 en 16... solo hay que añadir más decoders. En cambio los CISC tienen una complejidad exponencial al intentar procesar más instrucciones en paralelo.
En resumen: El M1 puede ejecutar hasta 8 instrucciones en paralelo pero el más moderno x86 no puede más de 4 instrucciones. Y eso es, el doble de rendimiento a la misma frecuencia de reloj.
La supuesta ventaja de los x86 al tener instrucciones muy, muy complejas (que equivaldrían a varias instrucciones RISC), se cae en la práctica, pues como dice el artículo las instrucciones del código común no son tan distintas de las RISC, ya que esas instrucciones complejas hay que usarlas expresamente en muchos de los casos, para tareas muy específicas. Aún así, el procesador debe de tenerlas en cuenta y se complica la decodificación de instrucciones, aunque nunca se usen.
Ese sería mi resumen de la "chicha" del artículo, que como digo, es muy bueno. La primera parte, la ventaja de tener varios chips especializados juntos con memoria unificada, también es interesante pero es más obvia.
Explica bien por qué las instrucciones ARM, que tienen un tamaño fijo, son más faciles de paralelizar en múltiples decoders de instrucciones, mientras que las CISC, que tienen longitud variable, no tanto. Y es tan sencillo como entender que para las instrucciones RSIC se sabe donde empiezan y donde acaban (todas miden 32bit) mientras que las CISC x86 miden de 1 a 15 bytes.
Por tanto, al ser las CSIC de longitud variable, hasta que no se decodifica una instrucción no se sabe donde empieza la siguiente.
Esto puede parecer que no es muy importante, pero sí lo es, porque los RISC pueden "comerse" instrucciones en paralelo sin límite, de 8 en 8 como el M1, de 16 en 16... solo hay que añadir más decoders. En cambio los CISC tienen una complejidad exponencial al intentar procesar más instrucciones en paralelo.
En resumen: El M1 puede ejecutar hasta 8 instrucciones en paralelo pero el más moderno x86 no puede más de 4 instrucciones. Y eso es, el doble de rendimiento a la misma frecuencia de reloj.
La supuesta ventaja de los x86 al tener instrucciones muy, muy complejas (que equivaldrían a varias instrucciones RISC), se cae en la práctica, pues como dice el artículo las instrucciones del código común no son tan distintas de las RISC, ya que esas instrucciones complejas hay que usarlas expresamente en muchos de los casos, para tareas muy específicas. Aún así, el procesador debe de tenerlas en cuenta y se complica la decodificación de instrucciones, aunque nunca se usen.
Ese sería mi resumen de la "chicha" del artículo, que como digo, es muy bueno. La primera parte, la ventaja de tener varios chips especializados juntos con memoria unificada, también es interesante pero es más obvia.
Comentarios
El artículo es muy bueno, la mejor parte es dónde explica las diferencias entre la arquitectura RISC de los ARM y la CISC de Intel/AMD.
Explica bien por qué las instrucciones ARM, que tienen un tamaño fijo, son más faciles de paralelizar en múltiples decoders de instrucciones, mientras que las CISC, que tienen longitud variable, no tanto. Y es tan sencillo como entender que para las instrucciones RSIC se sabe donde empiezan y donde acaban (todas miden 32bit) mientras que las CISC x86 miden de 1 a 15 bytes.
Por tanto, al ser las CSIC de longitud variable, hasta que no se decodifica una instrucción no se sabe donde empieza la siguiente.
Esto puede parecer que no es muy importante, pero sí lo es, porque los RISC pueden "comerse" instrucciones en paralelo sin límite, de 8 en 8 como el M1, de 16 en 16... solo hay que añadir más decoders. En cambio los CISC tienen una complejidad exponencial al intentar procesar más instrucciones en paralelo.
En resumen: El M1 puede ejecutar hasta 8 instrucciones en paralelo pero el más moderno x86 no puede más de 4 instrucciones. Y eso es, el doble de rendimiento a la misma frecuencia de reloj.
La supuesta ventaja de los x86 al tener instrucciones muy, muy complejas (que equivaldrían a varias instrucciones RISC), se cae en la práctica, pues como dice el artículo las instrucciones del código común no son tan distintas de las RISC, ya que esas instrucciones complejas hay que usarlas expresamente en muchos de los casos, para tareas muy específicas. Aún así, el procesador debe de tenerlas en cuenta y se complica la decodificación de instrucciones, aunque nunca se usen.
Ese sería mi resumen de la "chicha" del artículo, que como digo, es muy bueno. La primera parte, la ventaja de tener varios chips especializados juntos con memoria unificada, también es interesante pero es más obvia.
#10 Completamente de acuerdo. Pero eso me ha hecho pensar... ¿sería posible que AMD o Intel añadiesen, en paralelo, un decodificador de "ARM a micro-ops", y poder ejecutar ambos juegos de instrucciones a la vez en el mismo procesador? Dado que el tamaño del decodificador, en transistores, es diminuto comparado con el resto (unidades funcionales, predictores, caché...), podría compensar, y permitir una transición fluida de x86 a ARM... Pero claro, yo no soy diseñador de CPUs, así que a lo mejor estoy diciendo una burrada. Pero si es posible, el rendimiento en ARM de un procesador x86 actual podría ser bestial...
#16 pues la verdad yo tampoco llego a tan bajo nivel, pero intuyo que acabarías teniendo dos procesadores en uno.
Eso es lo que debería de haberse hecho con el 386, meter un RISC aprovechando el cambio a 32bit y dejar el x86 dentro, hasta que se emulase por software y desapareciese.
Total, Microsoft no hizo ni puto caso de los 32bit hasta Windows 3.11 "enhanced mode".
#17 Ya, pero entiendo que el problema sería implementar los "modos de funcionamiento" de ARM (o sea, el modo protegido, excepciones, etc) lo que haría que fuese complejo, pero imagínate que mantenemos la arquitectura x86, pero cambiando las instrucciones a un formato de tamaño fijo. Ahí sí sería relativamente trivial...
#18 pero si cambias el formato de instrucción pierdes la compatibilidad binaria, que es por lo que montan todo este pollo. Un x86 de tamaño fijo sería básicamente un RISC.
Cambia mucho: por ejemplo en x86 cargar un entero de 64bit es una sola instrucción de ¿9 bytes? (opcode+constante de 64bit)
Mientras que en ARM es una instrucción de 32 bit que indica el desplazamiento relativo donde se almacena el entero de 64 bit.
Como ves cambia completamente.
#19 No, no... no digo reemplazar el decodificador x86 por uno de longitud fija, sino añadirlo en paralelo y poder conmutar de un formato a otro, de la misma forma que se conmuta entre x86 y x86-64 (bueno, más o menos... creo que entiendes lo que quiero decir). El procesador arrancaría, por compatibilidad, con el decodificador x86, que convertiría las instrucciones x86 en micro-ops internas. Pero si el sistema operativo carga un binario en formato "x86-RISC" (por llamarlo de alguna manera), ese proceso se ejecutaría mediante el nuevo decodificador, que, a partir de ese nuevo formato, generaría el mismo tipo de micro-ops internas; pero otros procesos, con instrucciones x86, seguirían usando el decodificador viejo. Y como todo lo demás (modelo de memoria, etc) es el mismo, no debería suponer un gran problema ni obligar a cambiar prácticamente nada, pero se tendría la ventaja de poder hacer un prefetch de instrucciones muchísimo mayor, igual que el M1 de Apple, gracias a que las instrucciones tienen todas el mismo tamaño.
Claro, como digo, no sería ARM "de verdad", sino más bien utilizar el formato de instrucción ARM sobre la arquitectura x86.
No se si ahora he conseguido explicar mi paja mental
#20 ya, quieres aprovechar parte de la lógica del x86 pero que pueda ejecutar también instrucciones de ARM.
Pues no sé qué resultado daría, ni sé si merece la pena.
Yo creo que hoy en día la compatibilidad binaria no es tan importante, la estrategia de Apple es buena, emula por software al 80% del rendimiento de x86, así que igual para la siguiente generación (¿M2?) el rendimiento de la emulación ya supera a su último chip x86, y listos.
Estoy seguro que en menos de un año todo el software relevante de Mac ya estará recompilado para ARM.
#21 Claro, pero es que yo no digo de hacerlo para los macs, sino para los PCs normales. Fuera de los de Apple, no hay procesadores ARM que alcancen a los de gama alta x86. Esta solución permitiría hacer una transición suave y sencilla.
#22 es posible que la arquitectura IA-64 de Intel, que fracasó, fuese algo parecido a lo que dices. Tendría que revisarla a ver si realmente era RISC, no la recuerdo y nunca la programé.
Fue un fracaso miserable, porque no estaba tan mal.
#22 checked! Si, IA-64 era más parecido a RISC. Tenía instrucción de tamaño fijo.
Una pena que fracasase.
#24 Ya, pero fracasó sobre todo porque la emulación x86 era lentiiiiiisima. Por eso x86-64 triunfó: permitía una transición a 64 bits sin pérdida de rendimiento.
Además, por lo que tengo entendido, IA-64 se apoyaba demasiado en el compilador para hacer la reordenación, de modo que no llevaba demasiada circuitería para ejecución fuera de orden, y parece ser que eso también supuso un lastre serio porque la idea no funcionaba tan bien como creían.
#25 habrán de inventarse otra cosa. Si meten ARM como tal tienen que pagarle royalties a ARM, y sería un palo enorme para Intel y AMD. Por otro lado, inventarse algo nuevo requiere disponer de todas las toolchain para esa cosa nueva, nada trivial dado el nivel de complejidad que tienen todas hoy en día.
Ya veremos como va el futuro, pero lo que está clarísimo es que M1 no es un procesador cualquiera, es un punto de inflexión para ARM que compromete seriamente el futuro de x86.
#26 A lo mejor RISC-V, que está libre de royalties...
#21 No lo dudes. DaVinci Resolve, Affinity Photo, Designer y Publisher, Nova y Transmit de Panic, Pixelmator y un respetabilísimo número de casas de software ya tienen desde el primer día que se pusieron a la venta equipos con M1 las versiones nativas de sus aplicaciones para Apple Silicon.
De hecho los desarrolladores están comentando que la adaptación a los nuevos chips de Apple está siendo muy cómoda.
Hasta los dinosaurios de Adobe (con ciertas aplicaciones de su catálogo como Illustrator con códigos y rutinas un tanto viejunas) está anunciando varias betas a corto plazo.
Obviamente, Logic, Final Cut y todas las aplicaciones de Apple van de cine.
Cómo será la cosa que hasta Mac OS Big Sur tiene aspectos de su interfaz que dan la sensación de familiaridad con versiones de anteriores SOs pero estéticamente han hecho un lavado de cara muy bien revisado. Por algo Apple ha suprimido la X de Mac OS. Ahora es Mac OS 11.
La conclusión es que si usas un equipo con Apple Silicon además de la rapidez y potencia evidentes (hay aplicaciones emuladas con Rossetta 2 que van más rápidas que unos cuantos procesadores de la gama de intel) tienes la sensación por los cambios en la interfaz sutiles y no tan sutiles que estás en una nueva plataforma informática. Lo que responde a una evidente realidad de hard/soft.
Ahora es cuando Apple en equipos de escritorio tiene las manos libres para actuar con total libertad y no va a rebufo de chips de intel que no han aumentado su rendimiento o capacidad de manera notable desde hace años. Es una de las quejas que tenían los gerifaltes de Apple.
Resulta que con la experiencia en iPhone y iPad, Apple ha ido creciendo y adquiriendo ventaja año tras año y llegado a un punto hace unos 3 ó 4 años ya comenzaron a plantearse qué hacer respecto a su plataforma de escritorio. Todo apunta a que su estrategia fue y está siendo positivamente muy sorprendente.
Intel y AMD estarán a salvo mientras Apple mantenga los M1 solo en sus ordenadores.
Además para que surgiera algún competidor que hiciera lo mismo que Apple seria necesario cuando menos el apoyo de Microsoft sacando Windows y software para ello. Que no digo que no pueda pasar pero desde luego a corto plazo no.
#6 "En los que un cambio a ARM podría suponer un gran salto."
No. El cambio no es solo a ARM, sino al concepto de Chip que acaba de hacer Apple, es decir:
Procesador, memoria, procesadores específicos (Criptografía, video, aprendizaje decodificación, etc..) todo en un solo Chip.
#8 Ahora me entero que apple ha hecho una arquitectura que lleva años y que ya tenía nombre.
#12 "Ahora me entero que apple ha hecho una arquitectura que lleva años y que ya tenía nombre."
Dime: ¿Dónde he dicho yo en #8 que Apple haya hecho una arquitectura?
gobbledegook , que palabra tan maravillosa. A ver si consigo recordarla.
#5 en castellano tb mola bastante "Jerigonza"
#11 chulísima.
Porque están de telepromoción
Que sus chip son de 5nm y los de Intel sigan en los 14nm quizás tenga algo que ver.
De hecho, hasta AMD ha "depurado" sus 7nm y le sobra para vencer a intel cuando podría estar vendiendo CPUs de 5nm perfectamente.
Cuanto más competencia, mejor.
#2 Y tanto. De hecho, con Intel absolutamente fuera de juego va a ser interesante ver el próximo movimiento de AMD. Tienen suerte de que Apple solo tenga interés en hacer micros para sus propios equipos, pero el toque de atención a la arquitectura x86 ya está dado... y las implicaciones para la informática de la próxima década son aún una incógnita.
#3 Es que es lo bueno... que haya competencia o cambios disruptivos en la tecnología para crear nuevos productos que mejoren lo anterior y de paso una posible bajada de precios.
Y si los ARM igualan en rendimiento/TDP o superan en rendimiento a los x86 es mejor para el planeta... Sobretodo en un mundo donde cada vez se usan más servidores que están 365 días de la semana encendidos... En los que un cambio a ARM podría suponer un gran salto.
#6 #3 A mi aún me falta saber cánto ahorro energético proviene de la arquitectura ARM, cuánto de bajar de 14nm de Intel a estos 5nm y cúanto del buen diseño de Apple. A igualdad de litografía en 5nm, no creo que el consumo de x86 vaya a ser muy superior una vez depurado.
Resumiendo, en lugar de optar por poner una cpu cargada de nucleos y más nucleos que llegado a un limite consumen muchisimo y no mejoran significativamente el rendimiento apple opta por integrar diferentes chips con funciones especificas que descargan la y alivian el procesador. Un poco como lo que ya se hace con la GPU pero todo integrado en una unica pieza y más a lo bestia. Desventaja para fabricantes de componentes de pc que o se ponen de acuerdo o acabaran por ponerse a la cola.
#4 No es lo único, según explica el artículo: la segunda parte viene en el conversor de instrucciones a micro-ops: en x86, como las instrucciones tienen un tamaño variable (desde 1 hasta 15 bytes) no puedes saber donde empieza la siguiente instrucción hasta que hayas decodificado, al menos parcialmente, la anterior. En ARM todas miden 4 bytes, por lo que puedes cargarlas en paralelo. En el artículo explica que AMD ha concluido que no tiene sentido meter, en x86, más de 4 unidades de decodificación de micro-ops, porque adivinar donde está la quinta instrucción es tan lento que no compensa. En cambio, Apple ha podido meter 8 unidades de decodificación, y podría meter aún más sin problema, porque es trivial saber donde está cada una de las instrucciones. Y cada nueva unidad de decodificación permite añadir más micro-ops que, potencialmente, podrán rellenar huecos de ejecución y ejecutarse en paralelo con anteriores micro-ops, lo que hace que el procesador pueda ir muchísimo más rápido que un x86.