Brevenotas Apple estaria por lanzar el M1X para el Macbook 16"

Tbon

Bonjour?
Miembro del Equipo
Fundador
ADMIN
Segun lo que informan las fuentes de Notebookcheck, Apple tendria entre manos el lanzamiento de una version mas potente del ya comentado M1.

1606819630235.png

El nuevo procesador con nombre clave M1X, tendria 12 cores (8 de performance + 4 de ahorro de energia) y vendria en los proximos a lanzar Macbook pro 16", no obstante aun no se saben los principales temas que ha dado que hablar el actual M1: cantidad de ram maxima y GPU disponible.

Habra que esperar al 2021 y ver si el lanzamiento del nuevo Macbook trae consigo mejores specs y por sobre todo, posibilidades de upgrade.

Fuente: Notebookcheck
 

Tbon

Bonjour?
Miembro del Equipo
Fundador
ADMIN
Hola, el m1 que tiene de malo? (Desde la ignorancia), ram y GPU?

En general la acogida ha sido muy buena para quienes quieren rapidez de navegacion y movilidad, pero quienes trabajan en ambitos "creativos" o trabajos mas pesados echan de menos tener la posibilidad de contar con mas de 16GB de ram (que no son ampliables).

Por otro lado el Apple M1 se caracteriza por poseer una memoria unificada (como las consolas) y si bien la GPU saca partido de esto y es bastante capaz para ser integrada, necesita tirar de la misma memoria ram y por tanto se ve limitada para tareas de texturizado 3D y video que demandan mas memoria (sin contar tareas cientificas que tiran de la GPU y requieren tambien mas memoria de video).

El almacenamiento tambien viene integrado por lo que no es ampliable, y si bien puedes conectar dispositivos externos, la capacidad de conectividad que otorga el SoC es limitada, de pasada ademas el protocolo Thunderbolt tampoco soporta GPUs externas.
 

AlCapone

IBMer
Si sale uno con 64GB o mas, creo q mi tarjeta de crédito juntará frio y venderé servercito y mi MBP 2019 15 con 32GB RAM e i9 del mas brigido para financiarme uno...
 

bighead

Cabro Cooleao
En general la acogida ha sido muy buena para quienes quieren rapidez de navegacion y movilidad, pero quienes trabajan en ambitos "creativos" o trabajos mas pesados echan de menos tener la posibilidad de contar con mas de 16GB de ram (que no son ampliables).

Por otro lado el Apple M1 se caracteriza por poseer una memoria unificada (como las consolas) y si bien la GPU saca partido de esto y es bastante capaz para ser integrada, necesita tirar de la misma memoria ram y por tanto se ve limitada para tareas de texturizado 3D y video que demandan mas memoria (sin contar tareas cientificas que tiran de la GPU y requieren tambien mas memoria de video).

El almacenamiento tambien viene integrado por lo que no es ampliable, y si bien puedes conectar dispositivos externos, la capacidad de conectividad que otorga el SoC es limitada, de pasada ademas el protocolo Thunderbolt tampoco soporta GPUs externas.
El sistema para compartir memoria es de los tiempos del commodore PET: Acceda al video en los tiempos muertos del bus, o bien, a contrafase (literalmente el video leía la ram en el canto contrario al cpu xDD). Por eso es necesario que la memoria sea DDR. Si el cpu leyese a la velocidad completa del bus DDR esto no se podría hacer. Sin embargo, el acceso caótico que tiene el mapeo de texturas perspectiva-correcto hace que esta técnica valga hectáreas de setas, porque el gpu puede llevarse el bus para la casa mientras manipula texturas. Para jugar candy crush y ver netflix, funciona genial. Para renderizar u ocupar CPU y GPU al 100% al mismo tiempo es una estupidez mayor.
El gran ahorro de esta técnica es que es trivial implementar cerocopias (baja latencia para operaciones simples), simplifica la logica de direccionamiento a niveles casi triviales y gana rendimiento en escenarios de baja complejidad, o sea, como el 90% del tiempo de uso de un usuario promedio.

Aún así queda la arista: Que pasa con este CPU cuando sacas Cinebench y pones a compilar una app gigante o evaluar un código cabrón? Tienes que transportar cientas de veces más instrucciones que con un CPU x86 para cubrir la misma cantidad de código. La velocidad de la memoria en sistemas RISC es crítica, y técnicas como compartir memoria, frenan fuertemente el potencial. Aún así, si las memorias no salen con algúnb artilugio interesante y más veloz, la arquitectura seguirá desperdiciandose.
 

Tbon

Bonjour?
Miembro del Equipo
Fundador
ADMIN
El sistema para compartir memoria es de los tiempos del commodore PET: Acceda al video en los tiempos muertos del bus, o bien, a contrafase (literalmente el video leía la ram en el canto contrario al cpu xDD). Por eso es necesario que la memoria sea DDR. Si el cpu leyese a la velocidad completa del bus DDR esto no se podría hacer. Sin embargo, el acceso caótico que tiene el mapeo de texturas perspectiva-correcto hace que esta técnica valga hectáreas de setas, porque el gpu puede llevarse el bus para la casa mientras manipula texturas. Para jugar candy crush y ver netflix, funciona genial. Para renderizar u ocupar CPU y GPU al 100% al mismo tiempo es una estupidez mayor.
El gran ahorro de esta técnica es que es trivial implementar cerocopias (baja latencia para operaciones simples), simplifica la logica de direccionamiento a niveles casi triviales y gana rendimiento en escenarios de baja complejidad, o sea, como el 90% del tiempo de uso de un usuario promedio.

Aún así queda la arista: Que pasa con este CPU cuando sacas Cinebench y pones a compilar una app gigante o evaluar un código cabrón? Tienes que transportar cientas de veces más instrucciones que con un CPU x86 para cubrir la misma cantidad de código. La velocidad de la memoria en sistemas RISC es crítica, y técnicas como compartir memoria, frenan fuertemente el potencial. Aún así, si las memorias no salen con algúnb artilugio interesante y más veloz, la arquitectura seguirá desperdiciandose.

Probablemente lo que comentas es una de las razones por las cuales se ha visto que en tareas en paralelo el M1 switchea las operaciones a background de forma automatica cuando cambias de aplicacion vs un x86 que no tiene ese comportamiento.

En este video se explica que cuando se utiliza multitasking saltando de un editor de video mientras se renderea a photoshop, el rendering queda en background aumentando los tiempos, mientras que en el x86 (que es un octacore + una vga dedicada) eso no sucede.



Quizas sea por un tema de optimizacion (y recursos disponibles), pero creo que puede ser que efectivamente el M1 no sea capaz de mantener un rendimiento en multitask de manera continuada sin una merma considerable de rendimiento por lo que, al igual que en los telefonos, enfoca sus recursos en lo que estes haciendo en el momento dejando lo demas con menor prioridad (o suspendido).

saludos
 
Última modificación:

AlCapone

IBMer
Quizas sea por un tema de optimizacion (y recursos disponibles), pero creo que puede ser que efectivamente el M1 no sea capaz de mantener un rendimiento en multitask de manera continuada sin una merma considerable de rendimiento por lo que, al igual que en los telefonos, enfoca sus recursos en lo que estes haciendo en el momento dejando lo demas con menor prioridad (o suspendido).

Eso sería un bye bye servers/pro users pesado... Y tiene sentido con el resto de la estrategia... :(

PS: que entretenido volver a la especulación de plataformas... es como la teleserie “que pasara luego de los 7nm de litografía” jajaja
 

Tbon

Bonjour?
Miembro del Equipo
Fundador
ADMIN
Eso sería un bye bye servers/pro users pesado... Y tiene sentido con el resto de la estrategia... :(
Exacto, te echarian por tierra cualquier escenario sobre plataformas virtualizadas o microservicios, aunque yo creo que mas que por una capacidad del procesador en si (recordemos que ARM es utilizado por AWS), tiene que ver con un manejo de recursos y foco en la "experiencia del usuario", que es el gran tema de empresas que viven del mercado retail.

PS: que entretenido volver a la especulación de plataformas... es como la teleserie “que pasara luego de los 7nm de litografía” jajaja

Y pensar que Intel todavia no llega a esa parte de la historia :zippy
 

Ratonator

Gold Member
yo creo que para mi pega, un Macbook Air con M1 andaria a toda zanja.
Le pregunté a un amigo que ya lo tiene en España, y para Office y cosas ejecutivas, el bicho anda de lujo, corre perfectamente todas las aplicaciones de productividad.

Para cosas más avanzadas, claramente ya no, pero el tener un equipo ligero y con una autonomía y rapidez que barre a la competencia, no hay por donde.
 

Ratonator

Gold Member
Hola, el m1 que tiene de malo? (Desde la ignorancia), ram y GPU?
Pros: Para usos ligeros y medios, su arquitectura unificada de ram + ssd en un soc, anda de lujo (mejores latencias, mejor manejo de la page file, mejor rendimiento en juegos que el video integrado de intel, mejor consumo electrico, etc, etc)

Contras: Su misma arquitectura unificada, le impide la posibilidad de ampliarse, desgaste notorio del ssd, ante la escasez de ram, cuando trabajas intensivo, tampoco hay soporte de gpu externas.

Para usos normales de un usuario, y uso medios (edición de video simple), el equipo anda bien, super incluso en ciertos escenarios.

Para cosas pesadas ya no.

Igual hay un pro que tiene el bicho, que no tiene la surface arm u otras eventuales opciones en arm, fuera del so, que al parecer Rosetta no estaria traduciendo instrucciones x86 como tradicionalmente uno podria pensar, sino que el chip m1 al parecer tendria alguna unidad especializada, que le ayudaria en el proceso de traducción de instrucciones, lo que le permitiria conseguir la "brujeria" de un 75% de rendimiento, vs el emulador de windows que al parecer tiene un rendimiento muy por debajo al de rosetta.

Lo cierto es que en la practica, todos los analistas han comentado lo sorprendente que andan las aplicaciones x86 habituales en Mac OS Big Sur para ARM.
 
Ya tengo una semana con el air m1. Venía del pro 2015. Es espectacular el Mac, dura caleta la batería , no se calienta, wifi 6 es extremadamente rápido, se nota mucho. En general muy bueno.

De hecho si ven los benchmarks barre con pro corei7 o i9 del 2019.


Lo único malo que al cambiar la arquitectura no he podido virtualizar niuna wea XD. Solo con parallels Windows. Pero entiendo que ya Vmware y vbox ya están trabajando en eso.

Y aunque no juego, los pocos juegos que probé se nota la buena gpu que tiene el bicho.

Estuve a punto de ir por el pro pero ví que las diferencias no son muchas, más batería, barra, ventilador y 1 core más de gpu que no sé si valen la pena.

Enviado desde mi Mi 9T mediante Tapatalk
 
Creo que una de las ventajas del pro son sus micrófonos que son de tipo profesionales, ahora me pregunto a qué se refiere con eso. Ondas servirán para hacer podcast?


Enviado desde mi iPhone utilizando Tapatalk Pro
 

bighead

Cabro Cooleao
Exacto, te echarian por tierra cualquier escenario sobre plataformas virtualizadas o microservicios, aunque yo creo que mas que por una capacidad del procesador en si (recordemos que ARM es utilizado por AWS), tiene que ver con un manejo de recursos y foco en la "experiencia del usuario", que es el gran tema de empresas que viven del mercado retail.



Y pensar que Intel todavia no llega a esa parte de la historia :zippy

Irónicamente, a ARM le iría bien ahí, si es en que tan despejado está el camino a la memoria donde está el meollo del asunto. Con un gpu decente y memoria propia, aumentaría rendimiento sin freno alguno. Ahora, respecto del video, era obvio que iban a aplicar la trampa de "androidizar" el OS para hacer el multitareas falso (o sea, 1 app y muchos daemon). Sería una pésima jugada de apple jugar exclusivamente así de ahora en adelante, porque sería el fin de los mercados cautivos de edición de medios y CAD, que son los que mas pagan por licencias y artículos apple, la vecina rubia solo se compra el ipad o el iphone y es bien poco las apps o licencias que compra.
Esto sin dudas es presión para intel y AMD, pero no tienen que caer en la satifacción de los benchmarks marketeros como Cinebench, tienen que centrarse en como los clientes sienten el pc desde la mano hasta el asiento, y en ese respecto, en mi humilde opinión, tienen que botar a la basura AVX y cualquier proyecto SIMD que tengan, porque ya existe en los pc, unidades que funcionan de estas maneras (ya sea vliw o risc) y darle espacio a la decodificación y a la evaluación lógica (que en este momento solo tiene buen rendimiento por el pipelining y no por el tiempo de evaluación directo de una sola instrucción) que es lo que mas pega en como sientes el PC. Quizás hacer algun experimento estúpido como hacer una versión sin secuenciador (y sin microcódigo) para el mercado "embedded" podría ayudar a juzgar, que es lo que realmente necesita un PC x86 para rendir bien. Francoise Piednoel muestra en unos videos qls, como intel desperdicia espacio en el pobre IC en estructuras que sirven al simd, siendo que es muy poco el tiempo que se pasa ejecutando cosas SIMD, solo para salid bien parado en cinebench y vender (que en realidad nadie compra el note por el cinebench).

Saludines
 

Tbon

Bonjour?
Miembro del Equipo
Fundador
ADMIN
Irónicamente, a ARM le iría bien ahí, si es en que tan despejado está el camino a la memoria donde está el meollo del asunto. Con un gpu decente y memoria propia, aumentaría rendimiento sin freno alguno. Ahora, respecto del video, era obvio que iban a aplicar la trampa de "androidizar" el OS para hacer el multitareas falso (o sea, 1 app y muchos daemon). Sería una pésima jugada de apple jugar exclusivamente así de ahora en adelante, porque sería el fin de los mercados cautivos de edición de medios y CAD, que son los que mas pagan por licencias y artículos apple, la vecina rubia solo se compra el ipad o el iphone y es bien poco las apps o licencias que compra.
Esto sin dudas es presión para intel y AMD, pero no tienen que caer en la satifacción de los benchmarks marketeros como Cinebench, tienen que centrarse en como los clientes sienten el pc desde la mano hasta el asiento, y en ese respecto, en mi humilde opinión, tienen que botar a la basura AVX y cualquier proyecto SIMD que tengan, porque ya existe en los pc, unidades que funcionan de estas maneras (ya sea vliw o risc) y darle espacio a la decodificación y a la evaluación lógica (que en este momento solo tiene buen rendimiento por el pipelining y no por el tiempo de evaluación directo de una sola instrucción) que es lo que mas pega en como sientes el PC. Quizás hacer algun experimento estúpido como hacer una versión sin secuenciador (y sin microcódigo) para el mercado "embedded" podría ayudar a juzgar, que es lo que realmente necesita un PC x86 para rendir bien. Francoise Piednoel muestra en unos videos qls, como intel desperdicia espacio en el pobre IC en estructuras que sirven al simd, siendo que es muy poco el tiempo que se pasa ejecutando cosas SIMD, solo para salid bien parado en cinebench y vender (que en realidad nadie compra el note por el cinebench).

Saludines

El tema de las SIMD vs VLIW al final siempre tiene que ver con que tan preparado esta el compilador para llenar el pipe, y por otro lado que tan caro sale hacer el cambio de paradigma para quienes desarrollan el software, porque mas allá de la dificultad de desarrollar un compilador que este a la altura de una arquitectura de este estilo (esa conversa tiene harta historia), bien puedes hacer el mismo esfuerzo (o menor) para mejorar tu compilador para las SIMD de toda la vida y la probabilidad de exito es mucho mas alta que la incertidumbre de que tu compilador no sea lo suficientemente bueno para una arquitectura totalmente nueva.

Por eso al final Apple tiene el sarten por el mango, porque al final ellos si pueden darse el lujo de probar (lo llevan haciendo años por lo demas) al tener control vertical de todo el "stack" y aun asi, el M1 sigue la ruta del SIMD con Neon.

De todas formas con la info que se ha ido sabiendo del M1 queda claro que lo que Apple esta haciendo no es magia, dado que el M1 es un chip gigante con casi 16mil millones de transistores, para hacer una comparacion directa un Ryzen core Renoir posee un aproximado de 10mil millones de transistores, en terminos practicos el M1 posee un 50% mas de recursos (probablemente dedicados a memoria), pero dado que esta fabricado a 5nm seguramente los costos los piensan aterrizar una vez que el proceso se encuentre maduro.

Probablemente la demora de los chips con mas cores se deba tambien a lo ultimo, estan esperando a que el proceso madure para fabricar en masa a un costo razonable.

Saludos
 

bighead

Cabro Cooleao
El tema de las SIMD vs VLIW al final siempre tiene que ver con que tan preparado esta el compilador para llenar el pipe, y por otro lado que tan caro sale hacer el cambio de paradigma para quienes desarrollan el software, porque mas allá de la dificultad de desarrollar un compilador que este a la altura de una arquitectura de este estilo (esa conversa tiene harta historia), bien puedes hacer el mismo esfuerzo (o menor) para mejorar tu compilador para las SIMD de toda la vida y la probabilidad de exito es mucho mas alta que la incertidumbre de que tu compilador no sea lo suficientemente bueno para una arquitectura totalmente nueva.

Por eso al final Apple tiene el sarten por el mango, porque al final ellos si pueden darse el lujo de probar (lo llevan haciendo años por lo demas) al tener control vertical de todo el "stack" y aun asi, el M1 sigue la ruta del SIMD con Neon.

De todas formas con la info que se ha ido sabiendo del M1 queda claro que lo que Apple esta haciendo no es magia, dado que el M1 es un chip gigante con casi 16mil millones de transistores, para hacer una comparacion directa un Ryzen core Renoir posee un aproximado de 10mil millones de transistores, en terminos practicos el M1 posee un 50% mas de recursos (probablemente dedicados a memoria), pero dado que esta fabricado a 5nm seguramente los costos los piensan aterrizar una vez que el proceso se encuentre maduro.

Probablemente la demora de los chips con mas cores se deba tambien a lo ultimo, estan esperando a que el proceso madure para fabricar en masa a un costo razonable.

Saludos
Ocurre que también no es solo "meter mas transistores" y ya. Intel en este momento (y AMD los tendrá luego) tiene problemas serios para cuadrar el timing de las etapas de SIMD, debido a que los caminos combinatoriales son demasiado anchos (y además son demasiados). Esto solo se arregla, o con menos transistores (irónico no?) o con más pipeline interno (hola Netburst). Los problemas son tan serios, que durante una evaluación de alguna instrucción AVX, el core baja su frecuencia hasta cerca de los 2Ghz en el peor de los casos.
No es raro, que en los notes y en los celus, haya más transistores que en un cpu tan monstruoso como un Ryzen. Eso ocurre por el tipo de codificación interna usada para el pipelining y el sistema de control. Una manera de "enfriar" la máquina a la fuerza, es hacer codificaciones menos densas (este problema es tan serio, que también en la implementación de aceleradores de IA se discute). En el Ryzen y en sus homólogos, se privilegió todo lo demás, espacio incluido, para mejorar el yield y bajar el coste por oblea, aceptando que una codificación más densa puede traducirse en más calor, calor que un PC en gabinete o un servidor, pueden manejar tranquilamente. También esto explica el reflote de los olvidados Chiplets.

Hay una parte que se me olvidó, pero es un culo hacer PCB para las Rams y mientras mas apretado estés de requerimientos y frecuencia, es más y más caro. El problema de hacer un PC "más grande" con esta tecnología, es que para lo que costará, tienes que estar a la altura y ofrecer memorias más rápidas o más anchas, proporcionables en módulos estándar. Si estas requieren ser muy rápidas para que el rendimiento se note, serán costosas para todos los actores y hacer un sistema más grande no será atractivo para nadie con esta tecnología (al menos para el segmento prosumer). Esta es una de las razones, por qué tantos metieron la cabeza al WC con las antiguas Rambus RDRAM. Los diseñadores de pcb, y de IC las amaban: Ocupaban poquitos pines, prometían muchísima velocidad, entraban como a una especie de Bus con control de acceso al medio y el IP que hacía la pega, Rambus te lo vendía listo, así que no había que rabiar tanto. Lamentablemente, las cláusulas leoninas de Rambus para su comercialización terminaron pavimentándole el camino a DDR, que corriendo con desventaja en todos los frentes igual ganó.

Ahora, por otra parte, si quisieran hacer uno con mas cores... simplemente botan los dispositivos integrados y ya y los pones en algún bus externo.
Por último, La cobertura de los ISA SIMD, por parte de los compiladores, para Intel es bastante mediocre. La documentación por parte de Intel está al debe hace muchos años (he leído ese manual ql) y son pocas las bibliotecas y aplicaciones que los ocupan íntegramente. Recursos de este estilo son más sencillos de obtener desde las GPU en este momento, con mucho mejor paralelismo y eficiencia energética, y sin perjudicar la capacidad del CPU de responder a interrupciones o mermar la eficiencia del mismo. Por lo tanto, botar el soporte de 3 aplicaciones en peligro de ser reemplazadas por una versión GPU en los próximos 5 años para salvar lo que ocupas el 99% del tiempo me parece lo más razonable.

Así como Intel lo ha resaltado en el último tiempo en su marketing, los CPU para servidores, escritorio, laptops y para embedded son comercializados en líneas diferentes de productos. ARM llegó al extremo de hacer que sus ISA fueran incompatibles. No hay que ir tan lejos, pero, aprovechando el vuelo, conservar el nivel de compatibilidad de un Pentium II (por decir algo) como base común, que es donde el 90% de los programas está viviendo y darle a cada segmento una "extensión" del ISA que se ajuste a sus necesidades (Sería chistoso enterarse uno de esos cajoncitos para Labview evaluando código con AVX512 con esos Atom de 1.6Ghz todos cagones :xd), le daría juego a todos los actores en muchos frentes, haciendo más fácil el trabajo. De partida Intel solo tendría que salir a pelear por AVX 256/512 solo para las 5 viejas qlas que quieren pelear y gritar por Cinebench y quizás para algunas cargas muy especificas para servidores de labores muy especificas, no tendría necesidad de virtualizar y usar SIMD tan sofisticado en los CPU embedded y en escritorio y notes con suerte necesitaría el nivel de compatibilidad de ISA de los Core2 que le permitiría, o meter más cores, o hacer cambios arquitecturales sustanciales que sin dudas se traducirían en más rendimiento o mejor yield. Tambien hay algunas locas posibilidades de mezclar tipos de cores y hacer traspaso de las tareas entre ellos según las necesidades, como una versión más bacán ymenos ingenua del Big.LITTLE.

En ese sentido, así como a modo de conclusión, ARM va a tener todas las de ganar, solo si es que sus promotores se atreven a salir del paradigma de diseño "Celulares/Android/iOS" y le dan un buen soporte de tecnologías de memoria más rápidas, que han acompañado a Intel y PowerPC durante años (Múltiples canales, zonas de memoria aisladas, memorias medio exóticas) o bien hacen alguna locura como ponerle HBM al CPU, o algo así, para que la fiesta no pare nunca, que es donde ARM pega fuerte y por supuesto, no temerle a niveles aceptables de calor, si estos permiten de cierto modo, facilitar el trabajo.

El tema es genial, da para páginas y páginas

Salu2
 
Última modificación:

bighead

Cabro Cooleao
Ya tengo una semana con el air m1. Venía del pro 2015. Es espectacular el Mac, dura caleta la batería , no se calienta, wifi 6 es extremadamente rápido, se nota mucho. En general muy bueno.

De hecho si ven los benchmarks barre con pro corei7 o i9 del 2019.


Lo único malo que al cambiar la arquitectura no he podido virtualizar niuna wea XD. Solo con parallels Windows. Pero entiendo que ya Vmware y vbox ya están trabajando en eso.

Y aunque no juego, los pocos juegos que probé se nota la buena gpu que tiene el bicho.

Estuve a punto de ir por el pro pero ví que las diferencias no son muchas, más batería, barra, ventilador y 1 core más de gpu que no sé si valen la pena.

Enviado desde mi Mi 9T mediante Tapatalk
Estos post son los que me gustaría leer también. Como se sienten estos Apple nuevos en las manos, que es lo que importa.
 

Tbon

Bonjour?
Miembro del Equipo
Fundador
ADMIN
Ocurre que también no es solo "meter mas transistores" y ya. Intel en este momento (y AMD los tendrá luego) tiene problemas serios para cuadrar el timing de las etapas de SIMD, debido a que los caminos combinatoriales son demasiado anchos (y además son demasiados). Esto solo se arregla, o con menos transistores (irónico no?) o con más pipeline interno (hola Netburst). Los problemas son tan serios, que durante una evaluación de alguna instrucción AVX, el core baja su frecuencia hasta cerca de los 2Ghz en el peor de los casos.
No es raro, que en los notes y en los celus, haya más transistores que en un cpu tan monstruoso como un Ryzen. Eso ocurre por el tipo de codificación interna usada para el pipelining y el sistema de control. Una manera de "enfriar" la máquina a la fuerza, es hacer codificaciones menos densas (este problema es tan serio, que también en la implementación de aceleradores de IA se discute). En el Ryzen y en sus homólogos, se privilegió todo lo demás, espacio incluido, para mejorar el yield y bajar el coste por oblea, aceptando que una codificación más densa puede traducirse en más calor, calor que un PC en gabinete o un servidor, pueden manejar tranquilamente. También esto explica el reflote de los olvidados Chiplets.

No me referia en todo caso al tamaño de las estructuras SIMD, sino mas bien en el tamaño total del chip que en el caso del M1 sugiere un amplio uso de registros (memoria) interna dadas las caracteristicas de un ISA como el de ARM, en ese sentido es probable que este procesador de Apple sea uno de los mas grandes (si no el mas grande monolitico) en la historia de los cpus basados en ARM (en cuanto a mm2 y cantidad de transistores), lo que no deja de ser importante teniendo en cuenta todo lo que Intel y AMD en general se preocupan por mantener sus chips en tamaños acotados (por costos y yields).

No me imagino el "premium" que deben estar pagando en Apple por fabricar un chip asi de grande en un nodo tan inmaduro (5nm), aunque claro, bolsillo tienen para aguantar.

Ahora, por otra parte, si quisieran hacer uno con mas cores... simplemente botan los dispositivos integrados y ya y los pones en algún bus externo.
Por último, La cobertura de los ISA SIMD, por parte de los compiladores, para Intel es bastante mediocre. La documentación por parte de Intel está al debe hace muchos años (he leído ese manual ql) y son pocas las bibliotecas y aplicaciones que los ocupan íntegramente. Recursos de este estilo son más sencillos de obtener desde las GPU en este momento, con mucho mejor paralelismo y eficiencia energética, y sin perjudicar la capacidad del CPU de responder a interrupciones o mermar la eficiencia del mismo. Por lo tanto, botar el soporte de 3 aplicaciones en peligro de ser reemplazadas por una versión GPU en los próximos 5 años para salvar lo que ocupas el 99% del tiempo me parece lo más razonable.

Totalmente, actualmente con las GPUs campeando las SIMD a nivel de cpu se estan volviendo cada vez mas irrelevantes, aunque creo que en algunos casos especificos aun se utilizan debido a la limitacion de acceso a memoria coherente por parte de las gpus, pero eso durará hasta que se de un protocolo de acceso unificado a memoria y coherencia que sea competente (AMD tiene ya una primera version con infinity Fabric)

Así como Intel lo ha resaltado en el último tiempo en su marketing, los CPU para servidores, escritorio, laptops y para embedded son comercializados en líneas diferentes de productos. ARM llegó al extremo de hacer que sus ISA fueran incompatibles. No hay que ir tan lejos, pero, aprovechando el vuelo, conservar el nivel de compatibilidad de un Pentium II (por decir algo) como base común, que es donde el 90% de los programas está viviendo y darle a cada segmento una "extensión" del ISA que se ajuste a sus necesidades (Sería chistoso enterarse uno de esos cajoncitos para Labview evaluando código con AVX512 con esos Atom de 1.6Ghz todos cagones :xd), le daría juego a todos los actores en muchos frentes, haciendo más fácil el trabajo. De partida Intel solo tendría que salir a pelear por AVX 256/512 solo para las 5 viejas qlas que quieren pelear y gritar por Cinebench y quizás para algunas cargas muy especificas para servidores de labores muy especificas, no tendría necesidad de virtualizar y usar SIMD tan sofisticado en los CPU embedded y en escritorio y notes con suerte necesitaría el nivel de compatibilidad de ISA de los Core2 que le permitiría, o meter más cores, o hacer cambios arquitecturales sustanciales que sin dudas se traducirían en más rendimiento o mejor yield. Tambien hay algunas locas posibilidades de mezclar tipos de cores y hacer traspaso de las tareas entre ellos según las necesidades, como una versión más bacán ymenos ingenua del Big.LITTLE.

Yo creo que gran parte de la implementacion de instrucciones tan sofisticadas como AVX se debe a darle un uso a las tecnologias que desarrollaron para Larrabee y que al final no usaron (me da la impresion que el mismo Atom es tambien hijo de ese desarrollo).

No obstante yo creo que las SIMD no dejaran de usarse en situaciones menos complejas (en particular por su facilidad de uso para calculos de precision simple) razon por la cual seguramente el M1 emplea estructuras simd mas "simples" de 128bits (ni de lejos las de 512 de Intel)

En ese sentido, así como a modo de conclusión, ARM va a tener todas las de ganar, solo si es que sus promotores se atreven a salir del paradigma de diseño "Celulares/Android/iOS" y le dan un buen soporte de tecnologías de memoria más rápidas, que han acompañado a Intel y PowerPC durante años (Múltiples canales, zonas de memoria aisladas, memorias medio exóticas) o bien hacen alguna locura como ponerle HBM al CPU, o algo así, para que la fiesta no pare nunca, que es donde ARM pega fuerte y por supuesto, no temerle a niveles aceptables de calor, si estos permiten de cierto modo, facilitar el trabajo.

El M1 efectivamente usa memoria HBM, por lo que ya estan en ese horizonte, lo complejo de esto es que se abre una ventana para problemas mas bien eticos como la imposibilidad del upgrade y la alta asimetria entre empresa y clientes finales en la obsolecencia de productos tan integrados (sin contar los temas ambientales).
 
Última modificación:
Subir