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
), 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
