Después de Apple, le toca a Microsoft, que estaría diseñando procesadores basados en ARM para los servidores de su servicio cloud Azure y sus productos de la gama Surface.
#1:
Al final cada uno se va crear su propio juego de instrucciones y se va a ir a la mierda la compatibilidad de aplicaciones.
O ejecutaremos todo sobre una máquina virtual java
#6:
Mientras todo sea ARM no debería de pasar nada. Ahora bien, me huelo a que lo que harán sera algo tipo ARM extendido y los programas que quieran exprimir al máximo los recursos ofrecidos por el sistema operativo tendrán que usar la parte propietaria, la extendida, y así es como pasara lo de #1.
Al final cada uno se va crear su propio juego de instrucciones y se va a ir a la mierda la compatibilidad de aplicaciones.
O ejecutaremos todo sobre una máquina virtual java
Mientras todo sea ARM no debería de pasar nada. Ahora bien, me huelo a que lo que harán sera algo tipo ARM extendido y los programas que quieran exprimir al máximo los recursos ofrecidos por el sistema operativo tendrán que usar la parte propietaria, la extendida, y así es como pasara lo de #1.
#1#14 Nadie va a querer hacer eso.
El tiempo ha dejado bastante claro que lo que atrae usuarios es el software y no el hardware.
Limitar el software que puede correr tu hardware con extensiones absurdas es pegar un tiro en el pie.
#21 ¿Pero por qué no le iba a interesar a Microsoft que el único software que funcione en el 90% de los ordenadores personales que se venden sea el suyo? No es que no hayan hecho cosas parecidas ya.
#6 La parte buena de tener una base y poder modificarla a tu antojo, es que si tienes una carga de trabajo muy específica y que consume muchos recursos, te creas una instrucción hardware que la acelere y tienes un chip propio basado en ARM que para tus cosas es la leche de rápido pero compatible con las herramientas y software ya existentes. Ahí, podrías seguir usando cualquier software arm de tu arquitectura sin problemas (sólo que no aprovecharía esa nueva instrucción).
Si además, eres de los que te gusta retorcer las cosas para exprimir el rendimiento al máximo, empezarás a hacer cambios en cosas ya hechas, cambiando cómo funcionan ciertas instrucciones, cómo se accede a la memoria, etc. y ahí si tendrías un problema, tendrías que compilar específicamente para tu nueva arquitectura.
Depende de qué opción elija MS, si añadir una extensión o instrucciones nuevas y específicas para ciertas cosas o cambiar la arquitectura (estilo lo que hace apple).
#16 Porque Nvidia tarjeta grafiva es una pieza hardware.
Aro tendrás que descargar el Acrobat para win10-arm, win10-amd64, win10-asus, ...
Las versiones de Acrobat ya no funcionaean exactamente igual y tendran configuraciones distintas. Los de Acrobat se le acabarán inchando los cojones y dirán no doy soporte para packardbell porque no me vale la pena...
Los desarrolladores pequeños tendrán que elegir para que procesador trabajan y cuál no...
#11 Graviton2 (La cpu usada en instancias con una g al final) es un diseño de Amazon basado en Neoverse. Los diseños los hace Annapurna Labs, comprada por Amazon hace unos años.
Amazon no ha añadido ninguna instrucción adicional, la cpu usa el juego ARMv8.2 sin las “Vector extensions”, que son opcionales. No veo por qué Microsoft iba a hacer algo distinto como dice #1, probablemente diseñen una CPU basada en una versión específica de la ISA. La única excepción que se me ocurre es sistemas tipo hololens, pero aquí hablamos de portátiles.
Y si, quizá al final sea lo más cómodo ejecutar todo en Java, al menos en servidores. Microsoft ya ha presentado un port de OpenJDK para Windows/aarch64 y en el proceso, ese mismo equipo han hecho (en colaboración con Azul) el port de macOS/aarch64
#1 Ya arm como tal en el kernel de linux y el soporte para aplicaciones en general es un pequeño lío de cojones de por sí (por cosas como estas: https://blogs.oracle.com/jtc/is-it-armhf-or-armel o en el pasado, esta: https://arstechnica.com/information-technology/2012/10/next-linux-kernel-release-supports-more-arms-with-less-code/). Y cuantas más modificaciones hagan al juego de instrucciones base por parte de terceros y más haya que mantener, más irán quedando por el camino con el tiempo. Están fabricando (modificaciones de) arquitecturas de usar y tirar (no son extensiones que soportas o no soportas, son cambios que muchas veces incompatibilizan y que llevarán a que aunque el 95% del código pueda ser el mismo, sin soporte, algunas variantes de algún fabricante específico tengan que ser abandonadas) dado que se terminan centrando siempre en sus SOCs más modernos y (salvo que tengan un éxito comercial destacable y se use en aparatos de larga vida comercial) desechando los más antiguos rápidamente (como los móviles).
Y esto supone una mejora con respecto a los actuales x86_64 porque...? Siempre había pensado que ARM era más veloz en pequeños dispositivos por tener menos instrucciones, y que esto precisamente era el motivo por el cual nuestros ordenadores y servidores usaban Intel. Ha cambiado algo?
#7 abro las cajas de los truenos, mejor manejo de vcpu por tener mayor números de núcleos por sistema a precio «similar», no conozco cuanto pueden salir los graviton o los altra, los thunderX no me parecen baratos, pero depende al final de economía de escalas.
#7 Básicamente, en términos de consumo energético y costes de escala. Además que, al final, estás diseñando un SOC (un integrado de procesador principal+memoria+gpu/chips de cálculo/loquepuñetasnecesites) que es más rápido para las tareas para las que ha sido diseñado que tener una arquitectura de propósito general.
De hecho, Amazon en su AWS tiene ya máquinas disponibles para despliegue basadas en micros ARM que permiten un menor coste por hora al tener menor consumo (lo que ya no sé es si los diseños de esas máquinas son propios de Amazon o no).
#11 en principio en un servidor los SoC ARM son más toscos que los x86, para cualquier otra cosa compra instancias de GPU, inferencia o lo que sea y se tira de PCI-E.
Lo de Amazon y Ampera son núcleos neoverse y Marvell con el thunder3x también va a usar los neoverse.
#18https://amperecomputing.com/wp-content/uploads/2020/11/Altra_PB_v0.65_20201102.pdf en el diagrama del SoC se ve que no hay conseciones a otros servicios a mayores. 80 núcleos, como unirlos, memoria, PCI-e y poco más, el de Marvell es muy similar, el Graviton se supone que también es similar, Amazon tiene también su procesador sistólico, el Neuron, así que se supone que no tiene nada de especial en los Graviton, son servicios separados que no comparten SoC.
#28 que mientras los SoC de consumo de ARM llevan muchos núcleos específicos y los x86 llevan instrucciones para varios usos en servidor los ARM se ciñen al núcleo duro de computación multiplicado en número mientras que los x86 conservan o añaden instrucciones específicas de consumo.
A eso me refiero, procesadores ceñidos a un tipo de computación, descargando en GPU, TPU(en el caso de Amazon también procesador propio) o aceleradora FPGA, lo cual es lógico, más cuando el servicio en venta es virtualizar hardware.
#34 Pues a mi me parece que, en todo caso, meter hardware específico para mejorar la eficiencia es lo fino y hacerlo todo a lo bruto como x86 es lo tosco, llámame raro.
#37 la CPU es más tosca, se vuelve menos polivalente. El sistema no tiene que ser más tosco a cubrir con más núcleos, expansión, virtualización y adaptación del cliente.
Obviando precios de los que no tengo ni idea, principalmente solo conozco características del Cavium con los thunderX ya que son quien más o menos publica precios, más lógico parece usar el sistema así para vender servicios.
#7 Tanto ARM como x86 son RISC y sobre esa capa RISC de microinstrucciones simples, hay una capa de instrucciones más complejas. Por herencia y demás, las instrucciones del x86 son bastante más complejas de traducir en microinstrucciones, las ARM están mejor diseñadas para que dicha traducción sea más eficiente, la capa de abstracción es más pequeña y más eficiente.
Quitando eso (que será un porcentaje tampoco tan grande como nos quieren vender de diferencia de rendimiento y consumo), ya la potencia, el consumo y demás dependen de la propia arquitectura del chip, tecnología de fabricación y demás.
La mejora que busca MS es la típica de: tomamos una arquitectura de la que tengamos licencia y podamos modificar, observamos qué tipo de cosas vamos a hacer con el chip, diseñamos nuevas instrucciones que puedan acelerar esas tareas, fabricamos el chip y adaptamos el software para usar esas nuevas instrucciones. Supongo que con ARM es fácil de hacer porque es más simple y seguramente ARM sea más permisiva sobre las modificaciones y la fabricación de chips que si lo intentaran con un x86. Por otro lado, MS querrá chips que consuman poco, y las alternativas (las arquitecturas power y la risc-v) quizá no le convengan o están verdes.
¿Ya han vuelto a poner a funcionar las fotocopiadoras? Ah, bueno, que seguro que es casualidad que anuncien esto -que de momento es sólo vapor- un mes después del lanzamiento del M1 de Apple. Uno, que es mal pensado
#39 IBM con el power10 a ddr5 y pci‑e 5, saltándose el pci‑e 4.
Por suerte para los que desarrollaron para el pci‑e 4 es bastante similar, pero aún así si el pci‑e 5 puede ser traumatico.
Comentarios
Al final cada uno se va crear su propio juego de instrucciones y se va a ir a la mierda la compatibilidad de aplicaciones.
O ejecutaremos todo sobre una máquina virtual java
#1 Esa frase final da escalofríos.
Mientras todo sea ARM no debería de pasar nada. Ahora bien, me huelo a que lo que harán sera algo tipo ARM extendido y los programas que quieran exprimir al máximo los recursos ofrecidos por el sistema operativo tendrán que usar la parte propietaria, la extendida, y así es como pasara lo de #1.
#6 Conociendo a Microsoft, eso es exactamente lo que va a ocurrir.
#1 #14 Nadie va a querer hacer eso.
El tiempo ha dejado bastante claro que lo que atrae usuarios es el software y no el hardware.
Limitar el software que puede correr tu hardware con extensiones absurdas es pegar un tiro en el pie.
#21 ¿Pero por qué no le iba a interesar a Microsoft que el único software que funcione en el 90% de los ordenadores personales que se venden sea el suyo? No es que no hayan hecho cosas parecidas ya.
#24 Estás leyendo la noticia? Servidores y tablets.
#35 Esta no-noticia es pura especulación y sólo habla de que "estaría diseñando", "por lo visto", y a eso podemos jugar todos.
#6 ¿Por qué iba a hacer eso Microsoft? Nunca serían tan malvados de perjudicar así a sus usuarios solo para ganar más dinero.
#6 La parte buena de tener una base y poder modificarla a tu antojo, es que si tienes una carga de trabajo muy específica y que consume muchos recursos, te creas una instrucción hardware que la acelere y tienes un chip propio basado en ARM que para tus cosas es la leche de rápido pero compatible con las herramientas y software ya existentes. Ahí, podrías seguir usando cualquier software arm de tu arquitectura sin problemas (sólo que no aprovecharía esa nueva instrucción).
Si además, eres de los que te gusta retorcer las cosas para exprimir el rendimiento al máximo, empezarás a hacer cambios en cosas ya hechas, cambiando cómo funcionan ciertas instrucciones, cómo se accede a la memoria, etc. y ahí si tendrías un problema, tendrías que compilar específicamente para tu nueva arquitectura.
Depende de qué opción elija MS, si añadir una extensión o instrucciones nuevas y específicas para ciertas cosas o cambiar la arquitectura (estilo lo que hace apple).
#1 No sé a qué compatibilidad de aplicaciones te refieres pero, a mi me suena a que de eso ya no había antes.
#10 En que no te bajas la versión del programa para Intel, AMD, Microsoft, HP, Dell...
#12 Los drivers para Nvidia no sirven para AMD, y no creo que HP, Dell o Lenovo lleven procesadores diferentes.
#16 Porque Nvidia tarjeta grafiva es una pieza hardware.
Aro tendrás que descargar el Acrobat para win10-arm, win10-amd64, win10-asus, ...
Las versiones de Acrobat ya no funcionaean exactamente igual y tendran configuraciones distintas. Los de Acrobat se le acabarán inchando los cojones y dirán no doy soporte para packardbell porque no me vale la pena...
Los desarrolladores pequeños tendrán que elegir para que procesador trabajan y cuál no...
#20 Hombre la aplicaciones de usuario como el acrobat hablaran con SO Windows 20 y ya será él el que se encargará...
#11 Graviton2 (La cpu usada en instancias con una g al final) es un diseño de Amazon basado en Neoverse. Los diseños los hace Annapurna Labs, comprada por Amazon hace unos años.
Amazon no ha añadido ninguna instrucción adicional, la cpu usa el juego ARMv8.2 sin las “Vector extensions”, que son opcionales. No veo por qué Microsoft iba a hacer algo distinto como dice #1, probablemente diseñen una CPU basada en una versión específica de la ISA. La única excepción que se me ocurre es sistemas tipo hololens, pero aquí hablamos de portátiles.
Y si, quizá al final sea lo más cómodo ejecutar todo en Java, al menos en servidores. Microsoft ya ha presentado un port de OpenJDK para Windows/aarch64 y en el proceso, ese mismo equipo han hecho (en colaboración con Azul) el port de macOS/aarch64
#1 Ya arm como tal en el kernel de linux y el soporte para aplicaciones en general es un pequeño lío de cojones de por sí (por cosas como estas: https://blogs.oracle.com/jtc/is-it-armhf-or-armel o en el pasado, esta: https://arstechnica.com/information-technology/2012/10/next-linux-kernel-release-supports-more-arms-with-less-code/). Y cuantas más modificaciones hagan al juego de instrucciones base por parte de terceros y más haya que mantener, más irán quedando por el camino con el tiempo. Están fabricando (modificaciones de) arquitecturas de usar y tirar (no son extensiones que soportas o no soportas, son cambios que muchas veces incompatibilizan y que llevarán a que aunque el 95% del código pueda ser el mismo, sin soporte, algunas variantes de algún fabricante específico tengan que ser abandonadas) dado que se terminan centrando siempre en sus SOCs más modernos y (salvo que tengan un éxito comercial destacable y se use en aparatos de larga vida comercial) desechando los más antiguos rápidamente (como los móviles).
Es bueno que haya variedad (mientras que Linux funcione todos)
#3 No sé si esto no traerá más problemas aún con los drivers en linux....
Es de Microsoft, será una mierda, como todo lo que hacen (y no se por qué, la verdad, con la de recursos que tienen).
#15 pues yo tengo una surface go y va estupenda, para el día a día, ocio y algo de trabajo es perfecta
Windoseros, recordad zune.
Antes todo esto era intel.
Gracias Intel
Y esto supone una mejora con respecto a los actuales x86_64 porque...? Siempre había pensado que ARM era más veloz en pequeños dispositivos por tener menos instrucciones, y que esto precisamente era el motivo por el cual nuestros ordenadores y servidores usaban Intel. Ha cambiado algo?
#7 abro las cajas de los truenos, mejor manejo de vcpu por tener mayor números de núcleos por sistema a precio «similar», no conozco cuanto pueden salir los graviton o los altra, los thunderX no me parecen baratos, pero depende al final de economía de escalas.
#7 Básicamente, en términos de consumo energético y costes de escala. Además que, al final, estás diseñando un SOC (un integrado de procesador principal+memoria+gpu/chips de cálculo/loquepuñetasnecesites) que es más rápido para las tareas para las que ha sido diseñado que tener una arquitectura de propósito general.
De hecho, Amazon en su AWS tiene ya máquinas disponibles para despliegue basadas en micros ARM que permiten un menor coste por hora al tener menor consumo (lo que ya no sé es si los diseños de esas máquinas son propios de Amazon o no).
#11 en principio en un servidor los SoC ARM son más toscos que los x86, para cualquier otra cosa compra instancias de GPU, inferencia o lo que sea y se tira de PCI-E.
Lo de Amazon y Ampera son núcleos neoverse y Marvell con el thunder3x también va a usar los neoverse.
#13 no he entendido nada de lo que has dicho, y eso que trabajo en el sector
#18 https://amperecomputing.com/wp-content/uploads/2020/11/Altra_PB_v0.65_20201102.pdf en el diagrama del SoC se ve que no hay conseciones a otros servicios a mayores. 80 núcleos, como unirlos, memoria, PCI-e y poco más, el de Marvell es muy similar, el Graviton se supone que también es similar, Amazon tiene también su procesador sistólico, el Neuron, así que se supone que no tiene nada de especial en los Graviton, son servicios separados que no comparten SoC.
#13 qué quiere decir que un SOC es "tosco"?
Será que el diseño de x86 es de una finura inusitada, lol.
#28 yo he visto a un SOC Arm eructar en público y ni siquiera disculparse
#28 que mientras los SoC de consumo de ARM llevan muchos núcleos específicos y los x86 llevan instrucciones para varios usos en servidor los ARM se ciñen al núcleo duro de computación multiplicado en número mientras que los x86 conservan o añaden instrucciones específicas de consumo.
A eso me refiero, procesadores ceñidos a un tipo de computación, descargando en GPU, TPU(en el caso de Amazon también procesador propio) o aceleradora FPGA, lo cual es lógico, más cuando el servicio en venta es virtualizar hardware.
#34 Pues a mi me parece que, en todo caso, meter hardware específico para mejorar la eficiencia es lo fino y hacerlo todo a lo bruto como x86 es lo tosco, llámame raro.
#37 la CPU es más tosca, se vuelve menos polivalente. El sistema no tiene que ser más tosco a cubrir con más núcleos, expansión, virtualización y adaptación del cliente.
Obviando precios de los que no tengo ni idea, principalmente solo conozco características del Cavium con los thunderX ya que son quien más o menos publica precios, más lógico parece usar el sistema así para vender servicios.
#7 al tener un set reducido de instrucciones, el ciclo de desarrollo es mas corto, y es mas eficiente en todos los sentidos
a cambio, el código ocupa mas memoria ram, pero hoy en día eso no es un problema.
hace muchos años que se sabe que la tecnología RISC se comería a la CISC, y está pasando ante nuestros ojos.
#7 Tanto ARM como x86 son RISC y sobre esa capa RISC de microinstrucciones simples, hay una capa de instrucciones más complejas. Por herencia y demás, las instrucciones del x86 son bastante más complejas de traducir en microinstrucciones, las ARM están mejor diseñadas para que dicha traducción sea más eficiente, la capa de abstracción es más pequeña y más eficiente.
Quitando eso (que será un porcentaje tampoco tan grande como nos quieren vender de diferencia de rendimiento y consumo), ya la potencia, el consumo y demás dependen de la propia arquitectura del chip, tecnología de fabricación y demás.
La mejora que busca MS es la típica de: tomamos una arquitectura de la que tengamos licencia y podamos modificar, observamos qué tipo de cosas vamos a hacer con el chip, diseñamos nuevas instrucciones que puedan acelerar esas tareas, fabricamos el chip y adaptamos el software para usar esas nuevas instrucciones. Supongo que con ARM es fácil de hacer porque es más simple y seguramente ARM sea más permisiva sobre las modificaciones y la fabricación de chips que si lo intentaran con un x86. Por otro lado, MS querrá chips que consuman poco, y las alternativas (las arquitecturas power y la risc-v) quizá no le convengan o están verdes.
¿Ya han vuelto a poner a funcionar las fotocopiadoras? Ah, bueno, que seguro que es casualidad que anuncien esto -que de momento es sólo vapor- un mes después del lanzamiento del M1 de Apple. Uno, que es mal pensado
Amd, Apple, Microsoft, Nvidia, Intel.. la cosa se pone compleja..
#39 IBM con el power10 a ddr5 y pci‑e 5, saltándose el pci‑e 4.
Por suerte para los que desarrollaron para el pci‑e 4 es bastante similar, pero aún así si el pci‑e 5 puede ser traumatico.