Jump to content

Apple Event de 10 de noviembre


Recommended Posts

  • Replies 70
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Bueno. Ni tanto ni tan poco. El M1 este lo han presentado en los modelos de entrada de gama a los precios más bajos de la gama Apple,... así que los están posicionando como el modelo básico. (800

En principio no tendrían problemas y parece que es lo que harán. Previsiblemente 2 o 4 núcleos Firestorm más. Leía estos días comentar a un ex-ingeniero de AMD que el patrón de diseño que parece estar

Según veo la ampliación de RAM a 16GB y disco duro a 512GB cuestan una barbaridad, ambas juntas cuestan 500 euros, un 50% de lo que cuesta el macbook air. No sé si es mas eficiente comprar el Air

Posted Images

Hace 15 horas, kerouack dijo:

Urian quería que metieran un Mac Pro dentro de un MacBook  Air! Eso si hubiera sido mágia! El M1 uno es lo que es, para un ordenador de mil euros. Para los de 2 ml euros ya saldrá otra cosa. 

No, no es eso.

Entiendo que en un smartphone o una tablet no es normal pasar de los 120mm2 por chip.

Si tienes un portátil puedes tener un chip algo más grande y colocar una CPU con 8 núcleos, recordemos que es una 4+4, y una GPU de 12 o 16 núcleos.

Yo me esperaba que el M1 no fuese un A14X reciclado, que vale que es muy potente en los benchmarks, pero un par de núcleos más hubiesen ido muy bien.

Lo otro que me ha dejado frío es la GPU, parece ser que si tienes una pantalla de 1440p o menos entonces Apple te coloca un A... Este, el M1. Ya me veo el iMac base con un M1 también.

Y alto, que hay que tener en cuenta que cuando pasamos de PPC a Intel x86 ocurrió lo mismo, los primeros modelos x86 eran modelos PPC con la placa base cambiada.

Link to post
Share on other sites
Hace 5 horas, Urian dijo:

Ya me veo el iMac base con un M1 también

Si no lo ha sacado ahora es que deben estar esperando a tener pulido el M1 Pro. Para los iMac Pro y MacPro sacarán el M1 Pro Max. Seguramente los llamará M1X y M1Z para seguir con la nomenclatura de los Axx y no la de los iPhone (no creo que suban de número hasta que sean de una generación posterior) pero no me suenan tan bien.

Link to post
Share on other sites
El 14/11/2020 a las 8:51, Urian dijo:

Si tienes un portátil puedes tener un chip algo más grande y colocar una CPU con 8 núcleos, recordemos que es una 4+4, y una GPU de 12 o 16 núcleos.

Hombre, pero es que es la CPU del MacBook Pro y el MacBook Air básicos. Que esos llevaban un quad core (ni siquiera 4+4) de Intel en la última actualización (o incluso dual core en el MacBook Air). De hecho 8 núcleos en portátil, salvo en el i9, no hay. Ni siquiera en PC, donde lo típico en la franja de 1500-2500€ es el i7 10750H de 6 núcleos. Y de todas formas los núcleos de Apple son mucho más rápidos, que al final es mejor que tener un montón de núcleos pero poco potentes.

Aún así, ya llegarán, que está pendiente el M1X para los MacBook Pro 13" de gama alta y los de 16". De momento los resultados de estos benchmarks han estado exactamente dentro de lo esperado, no tiene pinta de que vayan a aflojar con el M1X.

Edited by Andropov
Link to post
Share on other sites
Hace 14 horas, Andropov dijo:

Aún así, ya llegarán, que está pendiente el M1X para los MacBook Pro 13" de gama alta y los de 16". De momento los resultados de estos benchmarks han estado exactamente dentro de lo esperado, no tiene pinta de que vayan a aflojar con el M1X.

No tiene pinta, no... más bien al contrario: el margen para la mejora es enorme... por ejemplo colocando más núcleos de los rápidos (creo que Apple los llama Firestorm).

El actual M1 tiene cuatro de esos y otros cuatro de bajo consumo (y menor potencia) porque es un SoC pensado para consumir lo menos posible. Pero hasta donde yo alcanzo, nada le impide a Apple poner directamente 8 núcleos Firestorm y prescindir de los 4 de bajo consumo para un equipo de sobremesa donde los requerimientos son diferentes. Por ejemplo en un iMac....

Para ser la primera versión, y encima pensada para funcionar en un Air de forma pasiva (sin ventilador), el rendimiento es aplastante. Si eliminas el requerimiento del consumo extremadamente bajo que tiene este diseño, puedes hacer muchas cosas... desde subir la frecuencia a colocar más núcleos "de los gordos" por no hablar de que la tecnología y el diseño va a seguir evolucionando.

Sorprende que el Mini M1 no llegue a los 30W de consumo eléctrico total ni siquiera en los momentos de máxima carga (eso que llaman stress tests). No hay Thermal throttling, y el máximo rendimiento permanece constante...... El mini i7 de 2018 que tengo en casa consume más del triple que eso a plena carga, y el ventilador empieza a bufar con ganas para evacuar todo el calor generado, rozando los 100ºC en el procesador y provocando Thermal throttling para evitar que el sistema se fría. Y encima para rendir MENOS que el M1... que cuesta casi la mitad de pasta.

El manotazo en la mesa ha sido de órdago. No pasaba desde los mejores tiempos de los PowerPC.

Link to post
Share on other sites
Hace 7 horas, Jorge dijo:

No tiene pinta, no... más bien al contrario: el margen para la mejora es enorme... por ejemplo colocando más núcleos de los rápidos (creo que Apple los llama Firestorm).

El actual M1 tiene cuatro de esos y otros cuatro de bajo consumo (y menor potencia) porque es un SoC pensado para consumir lo menos posible. Pero hasta donde yo alcanzo, nada le impide a Apple poner directamente 8 núcleos Firestorm y prescindir de los 4 de bajo consumo para un equipo de sobremesa donde los requerimientos son diferentes. Por ejemplo en un iMac....

En principio no tendrían problemas y parece que es lo que harán. Previsiblemente 2 o 4 núcleos Firestorm más. Leía estos días comentar a un ex-ingeniero de AMD que el patrón de diseño que parece estar siguiendo Apple para sus procesadores es el típico en los SoCs: diseñar núcleos que sean independientes de la latencia a componentes externos del paquete (caché, GPU, controladores de memoria) de forma que al crear un nuevo diseño (por ejemplo, con más núcleos) no tengas que rediseñar los núcleos. La otra opción es afinar uno a uno el diseño de cada núcleo para aprovechar que esté más cerca o más lejos de la caché (con la reducción de latencia que eso conlleva), pero cuesta muchísimo más diseñar nuevos procesadores con el mismo diseño general de los núcleos porque no puedes aprovechar todo el diseño.

Lo único que tendrán que hacer al aumentar el número de núcleos es aumentar la caché L2 porque con más núcleos para la misma caché tendrían más cache misses y que tirar de memoria más a menudo (y parece que esta es una de las claves del A14/M1 vs la competencia en ARM). Los Icestorm cores probablemente los mantendrán, imagino que estarán activos cuando el Mac esté en reposo (como hace App Nap ahora) gastando mucha menos batería que despertando a los Firestorm. Y en servidores, el rendimiento por vatio es muy importante, así que en los Mac Mini de gama alta tienen un buen incentivo para mantenerlos también. Me sorprendería mucho que los eliminasen, aunque no creo que ningún Mac acabe montando más de 8 núcleos Icestorm.

Por cierto, parece que dado que el M1 tiene ocho canales de RAM LPDRR4X debería poder soportar ya 32GB de RAM sin modificación (aunque no esté disponible en los Macs con M1 que han sacado de momento), así que esa (preocupate, al menos para mí) limitación a 16GB no es tal.

  • Me gusta 1
Link to post
Share on other sites

Aunque no tengo los conocimientos suficientes para confirmarlo, este artículo explica algunas razones por las que las comparativas de rendimiento entre procesadores deben cambiar con la llegada de los M1. Y porque los nuevos Macs son más rápidos de lo que según la velocidad de sus procesadores deberían ser.

Link to post
Share on other sites
Hace 51 minutos, APB dijo:

Aunque no tengo los conocimientos suficientes para confirmarlo, este artículo explica algunas razones por las que las comparativas de rendimiento entre procesadores deben cambiar con la llegada de los M1. Y porque los nuevos Macs son más rápidos de lo que según la velocidad de sus procesadores deberían ser.

Uf. No es el primer artículo que leo de ese autor. Voy a leerlo, pero como sea como el resto...

Link to post
Share on other sites
Hace 15 horas, APB dijo:

Aunque no tengo los conocimientos suficientes para confirmarlo, este artículo explica algunas razones por las que las comparativas de rendimiento entre procesadores deben cambiar con la llegada de los M1.

Acabo de leer ese artículo y no tengo nada claro que sus disertaciones sobre CISC vs. RISC tengan algún sentido a estas alturas de la película. Creo que está muy desfasado respecto a cómo funciona un procesador moderno realmente.

Las cosas que dice tenían más o menos sentido en la primera época del PowerPC (primera mitad de la década de 1990). Pero los X86 de Intel y de AMD hace muuucho tiempo que internamente son procesadores RISC con una unidad que va "traduciendo" (decodificando) las instrucciones X86 a su arquitectura interna. Se podría decir que son procesadores "híbridos"...

Pero en todo caso, da lo mismo si el procesador internamente trabaja en CISC o en RISC, lo que importa es si el mismo algoritmo (compilado para cada plataforma) es más rápido o más lento ejecutándose. Ya NADIE hace código en ensamblador... se programa en alto nivel y se compila. Que vaya en CISC, RISC es irrelevante para eso. Por no hablar de las instrucciones vectoriales tipo MMX, Altivec,... que en realidad son especializadas y suponen a efectos prácticos un coprocesador (como en su momento era el coprocesador matemático que hoy se da por hecho que está integrado en el micro).

Y el resto de cosas que dice tampoco tienen mucho sentido hoy en día. Por ejemplo, es cierto que el M1 tiene un hardware especializado en descodificar vídeo sin necesidad de que los núcleos del procesador trabajen... pero eso también lo tienen los chips de Intel... O los procesadores gráficos integrados que tanto los Intel X86 como el M1 tienen.

Es cierto que Apple ha llevado todo un par de pasos más allá y ha integrado muchos más compontenes dentro del chip (por eso se llama SoC). Pero el resto de micros van por el mismo camino en mayor o menor medida. Ya se da por hecho que la gráfica esté "integrada", o la "gestión de memoria" , el control de los buses,... Ese es el camino para Apple y también para el resto. Pero sí, Apple lleva bastante ventaja.

Edited by Jorge
Link to post
Share on other sites
Hace 2 horas, Jorge dijo:

Las cosas que dice tenían más o menos sentido en la primera época del PowerPC (primera mitad de la década de 1990). 

Realmente son cosas que se oían más por aquel entonces (supongo vaya, yo ni había nacido 😂) y que dejaron de tener sentido ya a principios de los 2000. Ars Technica hizo un genial artículo sobre cómo el diseño de procesadores se adentraba en un mundo "Post-RISC" y que el término estaba dejando de tener sentido. El artículo (aún válido hoy en día, y muy interesante) es de 1999. Desde entonces la cosa se ha difuminado aún más y no tiene mucho sentido hablar de RISC vs CISC hoy en día.

Además, no en este artículo en concreto pero sí en otros, el mismo autor comenta que CISC es inherentemente más rápido que RISC porque según dice más instrucciones disponibles implica mayor rendimiento y algún otro disparate que indica que no termina de entender de lo que está hablando. Mejor no doy mi opinión sobre lo que me parece que le sigan dejando publicar artículos.

Varias de las cosas que dice en el artículo son falsas, como lo que mencionas del hardware específico para decodificar vídeo. Es por ejemplo el motivo de que los MacBook de 2016 en adelante puedan usar Sidecar y los anteriores no (no tenían soporte por hardware para HEVC). Irónicamente lo mismo sucede con el ejemplo que pone en el artículo para explicar esto, que habla del soporte para encriptación AES. Eso también está en los procesadores Intel desde hace mucho. Es el motivo por el cual activar FileVault ahora apenas supone una pérdida de rendimiento mientras que en los tiempos de FileVault 1 sí lo suponía (no había soporte para descifrar AES por hardware). Lo que dice después de que los procesadores de Intel descifran los hashes AES utilizando los núcleos normales es otro disparate.

También menciona que una de las ventajas de los M1 frente a Intel es la computación heterogénea (esto sí es cierto) pero luego descarrila y dice que en x86 los núcleos han de ser todos iguales y a la misma frecuencia. Esto tampoco es así, los núcleos de Intel no están todos a la misma frecuencia y en principio nada en la arquitectura x86 les impide montar núcleos de alto y bajo rendimiento como hace Apple (o Qualcomm). De hecho, muy probablemente es lo que acaben haciendo.

O lo de decir que el M1 no es el procesador más rápido del mercado en monocore, especialmente de forma tan tajante como lo hace, cuando resulta evidente que sí lo es, aún descontando las tareas que en el M1 están aceleradas y en Intel no...

Hay más cosas mal, pero no tiene mucho sentido desgranarlo más. Creo que está claro que en general, por cada cosa que acierta, hay dos en las que patina.

Link to post
Share on other sites
Hace 36 minutos, Andropov dijo:

Ars Technica hizo un genial artículo sobre cómo el diseño de procesadores se adentraba en un mundo "Post-RISC" y que el término estaba dejando de tener sentido. El artículo (aún válido hoy en día, y muy interesante) es de 1999. Desde entonces la cosa se ha difuminado aún más y no tiene mucho sentido hablar de RISC vs CISC hoy en día.

Exactamente.

Yo no tengo ni idea de quién es la persona que ha escrito ese artículo de applesfera, pero al leerlo se nota que tiene ciertas lagunas de concepto y algunas ideas que hace lustros que están desfasadas. Tanto es así, que ya a mediados de los años 90 (hace 25 años nada menos), Intel lanzó el procesador Pentium PRO y con él la microarquitectura P6, que se caracteriza precisamente por decodificar internamente las instrucciones CISC X86 en otras de más bajo nivel (llamadas micro-ops) y ejecutarlas de una forma mucho más cercana a como lo hace un procesador RISC.

Desde entonces todos los micros Intel han ido evolucionando esta técnica que, diciéndolo "a lo bruto", lo que hacen es "descomponer al vuelo" el código CISC X86 en un microcódigo interno RISC y ejecutar ese código. Por tanto, afirmar que los micros X86 "son CISC" es un error de concepto. Una cosa es que cara al exterior tengan un juego de instrucciones CISC, y otra es que internamente trabajen siguiendo un modelo CISC, que NO es el caso. Son micro híbridos, que además aúnan todo tipo de unidades de procesamiento dentro del mismo chip. Desde unidades vectoriales (MMX, 3DNow!, SSE, AVX,...) pasando por el coprocesador matemático "de toda la vida", hasta incluir núcleos de procesamiento gráfico (que se pueden usar para cosas que NADA tienen que ver con los gráficos),... o motores de compresión/descompresión de vídeo por hardware entre otras muchas cosas.

De todas formas, el error es asumir que todo eso tiene alguna relevancia a la hora de comparar la velocidad del procesador (de sus núcleos) tal y como hace GeekBench, que es lo que se ha hecho con el M1 y los Intel. La prueba de CPU de GeekBench utiliza exclusivamente los núcleos del procesador, no utiliza nada más... por tanto está midiendo la potencia de esos núcleos y de nada más. Que el M1 tenga un "neural engine" es irrelevante para el resultado de GeekBench porque no lo usa. Y por eso se puede afirmar que en rendimiento mononúcleo, los cores Firestorm del M1 son más rápidos que los del Intel de turno con el que se esté comparando.... toda la parrafada CICS vs. RISC no viene al caso para nada.

Link to post
Share on other sites
El 20/11/2020 a las 2:40, Andropov dijo:

Uf. No es el primer artículo que leo de ese autor. Voy a leerlo, pero como sea como el resto...

Hola a todos:

Pues nada, sólo comentar que coincido con Andropov y Jorge en los comentarios del artículo de JCFM. Esta persona tiene cierta fama dentro del mundillo Apple en España (Apelianos podcast) porque creo que tiene un site de programación llamado AppleCoding o algo así. De sus conocimientos de soft no digo nada. Pero en los de hard y en el tema de micros, bueno, mejor lo dejamos....

Mi impresión, es que hay cosas de las que sabe. Pero muchas de las que no sabe. Y cuando se mete en temas de los que no sabe, da la impresión (ojo, o al menos eso parece) que se inventa lo que dice. Y se queda tan tranquilo. Lo de los cores que cuenta Andropov, que dice que todos en Intel son iguales...Bueno....sin comentarios.

Ya me dirá por poner un ejemplo, que tiene que ver un core hyperthreading con uno normal. Cuando los hyperthreading dan de un 20% a un 30% del rendimiento de uno de los normales. Hay más cosas, y algunas ya las habéis comentado.

Por último y para acabar me llama un poco la atención que todo el tema del M1 haya pillado desprevenida a la prensa especializada. ¿Conocéis la lista del TOP500? (top500.org). Es una lista de las 500 máquinas HPC más potentes del mundo. ¿Sabéis cual es la primera en la última lista de Junio 2020 y que procesador lleva?

FUGAKU. Un súpercomputador de Fujitsu. Y si. Un ARM. Bueno, miles de ellos. El ARM A64FX de FUJITSU. 48 cores. Así que mirad si Apple va bien encaminada.

Para mi este tema (es una opinión) va a producir, una revolución en el mundo de la informática.

Saludos

JP

 

 

Edited by jp
Link to post
Share on other sites
Hace una hora, Jorge dijo:

Yo no tengo ni idea de quién es la persona que ha escrito ese artículo de applesfera, pero al leerlo se nota que tiene ciertas lagunas de concepto y algunas ideas que hace lustros que están desfasadas. Tanto es así, que ya a mediados de los años 90 (hace 25 años nada menos), Intel lanzó el procesador Pentium PRO y con él la microarquitectura P6, que se caracteriza precisamente por decodificar internamente las instrucciones CISC X86 en otras de más bajo nivel (llamadas micro-ops) y ejecutarlas de una forma mucho más cercana a como lo hace un procesador RISC.

Creo que entonces la motivación era conseguir Out of Order Execution e intentar hacerlo con las instrucciones de longitud variable de x86 era inviable. Irónicamente, y si mal no recuerdo, Intel consiguió tener out of order execution antes que nadie. Y es un buen ejemplo de algo que a priori sería más acorde con la filosofía CISC (hacer más por ciclo de reloj) pero que sin embargo pronto adoptaron también muchas arquitecturas RISC (PowerPC y ARM también lo hacen).

Sobre lo último que comentas, yo no estaba seguro de si GeekBench usaba sólo los núcleos de la CPU. Para algunas cosas como los tests de Machine Learning que incluye imaginaba que sí (sólo se puede acceder a la Neural Engine usando la librería de CoreML, y no tendría mucho sentido en un test de procesador), pero en otras cosas no estoy seguro. Yo diría que la descompresión usando AES-XTS sí que está acelerada por hardware (en todas las plataformas). Imagino que si está disponible como una instrucción a la hora de compilarlo GeekBench lo usará (acelerando así cosas como AES) pero si requiere una librería del sistema (como CoreML para el Machine Learning) no.

 

Hace 1 hora, jp dijo:

Mi impresión, es que hay cosas de las que sabe. Pero muchas de las que no sabe. Y cuando se mete en temas de los que no sabe, da la impresión (ojo, o al menos eso parece) que se inventa lo que dice. Y se queda tan tranquilo. Lo de los cores que cuenta Andropov, que dice que todos en Intel son iguales...Bueno....sin comentarios.

Ya me dirá por poner un ejemplo, que tiene que ver un core hyperthreading con uno normal. Cuando los hyperthreading dan de un 20% a un 30% del rendimiento de uno de los normales. Hay más cosas, y algunas ya las habéis comentado.

Hola jp, cuánto tiempo 🙂

Pues la verdad es que no tenía ni idea de cómo estaba implementado el tema del hyperthreading en los procesadores Intel. Tanto hablar de núcleos "lógicos" y "físicos" nunca me había parado a pensar en cómo estaría implementado en el hardware. Parece que los núcleos "lógicos" duplican los registros pero comparten las unidades de ejecución con otro núcleo.

De todas formas a mí esto del hyperthreading nunca me ha dado buenos resultados. Hace no mucho programé una simulación (usando Python compilado a C con Numba) en la que se generaban 16 hilos por defecto (ya que dependía del número de núcleos que reportase la CPU, que en mi caso es un i9 de 8 núcleos con hyperthreading) y una de las cosas que hizo que la simulación fuese más rápido fue... crear sólo 8 hilos. Resulta que el overhead de tener 16 hilos en vez de 8 no se compensaba siquiera por usar los núcleos lógicos.

Con otra simulación me pasó algo parecido. En Swift hay una función, llamada "concurrentPerform()" que básicamente ejecuta el bloque de código que le pases, repartiendo las N iteraciones que le indiques en paralelo entre los núcleos disponibles. Y me di cuenta de que al utilizarla sólo invocaba 8 hilos nuevos, no 16.

Supongo que habrá otras cosas que sí utilicen el hyperthreading pero para cosas que sean "number crunching" mi impresión de momento es: meh. Y de hecho Apple no ha implementado nada parecido en sus M1.

 

Hace 2 horas, jp dijo:

Por último y para acabar me llama un poco la atención que todo el tema del M1 haya pillado desprevenida a la prensa especializada. ¿Conocéis la lista del TOP500? (top500.org). Es una lista de las 500 máquinas HPC más potentes del mundo. ¿Sabéis cual es la primera en la última lista de Junio 2020 y que procesador lleva?

FUGAKU. Un súpercomputador de Fujitsu. Y si. Un ARM. Bueno, miles de ellos. El ARM A64FX de FUJITSU. 48 cores. Así que mirad si Apple va bien encaminada.

Para mi este tema (es una opinión) va a producir, una revolución en el mundo de la informática.

Ah, es que además imagino que en servidores la potencia por vatio también será importantísima. Curiosamente los dos siguientes utilizan la arquitectura POWER9 de IBM, que vienen del desarrollo del que un día salieron los G5 (usaban la arquitectura POWER4 de IBM).

Pero sí, totalmente de acuerdo en que será una revolución en el mundo de la informática. O debería serlo, pero ya veremos. La evolución natural sería que algunos PCs también se pasasen a ARM. Pero claro, en Windows aún siguen para algunas cosas con el lío de los 32 o 64 bits, como para decirles que se deshagan completamente de x86/x64 y utilicen una nueva arquitectura en la que nada es compatible de base. Veremos.

 

 

Link to post
Share on other sites
Hace 4 horas, Andropov dijo:

Creo que entonces la motivación era conseguir Out of Order Execution e intentar hacerlo con las instrucciones de longitud variable de x86 era inviable. Irónicamente, y si mal no recuerdo, Intel consiguió tener out of order execution antes que nadie. Y es un buen ejemplo de algo que a priori sería más acorde con la filosofía CISC (hacer más por ciclo de reloj) pero que sin embargo pronto adoptaron también muchas arquitecturas RISC (PowerPC y ARM también lo hacen).

Sobre lo último que comentas, yo no estaba seguro de si GeekBench usaba sólo los núcleos de la CPU. Para algunas cosas como los tests de Machine Learning que incluye imaginaba que sí (sólo se puede acceder a la Neural Engine usando la librería de CoreML, y no tendría mucho sentido en un test de procesador), pero en otras cosas no estoy seguro. Yo diría que la descompresión usando AES-XTS sí que está acelerada por hardware (en todas las plataformas). Imagino que si está disponible como una instrucción a la hora de compilarlo GeekBench lo usará (acelerando así cosas como AES) pero si requiere una librería del sistema (como CoreML para el Machine Learning) no.

 

Hola jp, cuánto tiempo 🙂

Pues la verdad es que no tenía ni idea de cómo estaba implementado el tema del hyperthreading en los procesadores Intel. Tanto hablar de núcleos "lógicos" y "físicos" nunca me había parado a pensar en cómo estaría implementado en el hardware. Parece que los núcleos "lógicos" duplican los registros pero comparten las unidades de ejecución con otro núcleo.

De todas formas a mí esto del hyperthreading nunca me ha dado buenos resultados. Hace no mucho programé una simulación (usando Python compilado a C con Numba) en la que se generaban 16 hilos por defecto (ya que dependía del número de núcleos que reportase la CPU, que en mi caso es un i9 de 8 núcleos con hyperthreading) y una de las cosas que hizo que la simulación fuese más rápido fue... crear sólo 8 hilos. Resulta que el overhead de tener 16 hilos en vez de 8 no se compensaba siquiera por usar los núcleos lógicos.

Con otra simulación me pasó algo parecido. En Swift hay una función, llamada "concurrentPerform()" que básicamente ejecuta el bloque de código que le pases, repartiendo las N iteraciones que le indiques en paralelo entre los núcleos disponibles. Y me di cuenta de que al utilizarla sólo invocaba 8 hilos nuevos, no 16.

Supongo que habrá otras cosas que sí utilicen el hyperthreading pero para cosas que sean "number crunching" mi impresión de momento es: meh. Y de hecho Apple no ha implementado nada parecido en sus M1.

 

Ah, es que además imagino que en servidores la potencia por vatio también será importantísima. Curiosamente los dos siguientes utilizan la arquitectura POWER9 de IBM, que vienen del desarrollo del que un día salieron los G5 (usaban la arquitectura POWER4 de IBM).

Pero sí, totalmente de acuerdo en que será una revolución en el mundo de la informática. O debería serlo, pero ya veremos. La evolución natural sería que algunos PCs también se pasasen a ARM. Pero claro, en Windows aún siguen para algunas cosas con el lío de los 32 o 64 bits, como para decirles que se deshagan completamente de x86/x64 y utilicen una nueva arquitectura en la que nada es compatible de base. Veremos.

 

 

Hola Andropov:

¿Que tal? Si la verdad es que si que hace tiempo 😀.  Me alegro de charlar un rato con vosotros. Me han hecho gracia vuestros comentarios (Jorge y tu) con lo de este hombre,  porque pienso como vosotros. Ya digo que mi impresión es que algo sabe del tema de programación Mac. Pero a veces cuando se sale de ahí...

La verdad es que lo del hyperthreading siempre ha sido una chapucilla de Intel. Los Xeon no tienen, asi que... Y nosotros en las máquinas que tienen hyperthreading, lo que hacemos es desconectarlos a través de la BIOS, porque que yo sepa no es que no se pueda seleccionar que tu algoritmo funcione con hyperthreading o no., como te pasa a ti. Es que ni siquiera, que yo sepa, puedes seleccionar entre cores hyperthreading y los que no lo son. Y como bien comentas, no son iguales unos que los otros.

En mi caso, el OpenMP los detecta todos., pero no los distingue. Supongo que es algo que depende del OS. Yo tambien tengo un i9 (como tu). En mi caso en un MacBook Pro. Pero vamos, no lo uso para medir tiempos, al menos por ahora. Yo sigo de momento con las gráficas de NVIDIA, que Apple ha despreciado en repetidas ocasiones.

Respecto de los rendimientos de ARM, vamos a ver. La cosa promete. Y creo que en el mundo Windows la cosa va a ser como comentas.

Saludos

 

JP

 

 

Edited by jp
Link to post
Share on other sites

Según veo la ampliación de RAM a 16GB y disco duro a 512GB cuestan una barbaridad, ambas juntas cuestan 500 euros, un 50% de lo que cuesta el macbook air.

No sé si es mas eficiente comprar el Air con 256GB y 8GB de RAM y en dos años venderlo por mitad de precio y comprar el que haya dentro de dos años. 

Esto tendría el mismo coste que comprar ahora mismo el actual Air con la ram y disco duro ampliado.

Da cosa comprar 7 años despues un ordenador con la misma RAM y tamaño de disco duro.... pero claro en aquel momento compré un Pro al que no he sacado rendimiento. 

Y es que lo que pide apple por ampliar RAM y disco duro parece una absoluta barbaridad. Sabeis si merece realmene la pena ? como no se puede ampliar tras comprarlo es una decisión deficil, igual ahora no necesito más RAM pero en 6 meses lo uso para trabajar y sí la necesito.

Edited by kerouack
  • Me gusta 1
Link to post
Share on other sites
Hace 22 horas, jp dijo:

La verdad es que lo del hyperthreading siempre ha sido una chapucilla de Intel. Los Xeon no tienen, asi que... Y nosotros en las máquinas que tienen hyperthreading, lo que hacemos es desconectarlos a través de la BIOS, porque que yo sepa no es que no se pueda seleccionar que tu algoritmo funcione con hyperthreading o no., como te pasa a ti. Es que ni siquiera, que yo sepa, puedes seleccionar entre cores hyperthreading y los que no lo son. Y como bien comentas, no son iguales unos que los otros.

Sí, en principio es el sistema operativo el que "coloca" los hilos en en núcleo que le parece apropiado. Pero me pareció significativo que una función nativa de swift como concurrentPerform ignore completamente el hyperthreading. En principio, ya que controlan el compilador y el SO, si hubiese alguna ventaja en utilizar el hyperthreading en esos casos lo habrían optimizado ya.

Además me da la impresión (aunque no sé lo suficiente como para opinar con rigor) de que con la cantidad de cores actuales el hyperthreading cada vez tiene menos sentido.  La ventaja principal era que si un hilo llegaba a un momento de stall y no podía continuar con la ejecución (porque estaba esperando a que llegase algún elemento desde la memoria principal, por ejemplo) otro hilo, sus unidades de ejecución (ALUs y demás) quedasen libres para el hilo que estuviese funcionando con hyperthreading y así aprovecharlas mientras el otro hilo está esperando. Pero claro, hoy en día hay procesadores con 8, 12 y 16 núcleos. Si estás ejecutando tareas diferentes probablemente te "sobren" núcleos que utilizar y no tengas que recurrir a uno lógico, y si estás utilizando todos los núcleos probablemente sea porque estás ejecutando alguna tarea altamente paralelizable y es poco probable que los núcleos lleguen a tener momentos de stall como para aprovechar el hyperthreading.

 

Hace 6 horas, kerouack dijo:

Según veo la ampliación de RAM a 16GB y disco duro a 512GB cuestan una barbaridad, ambas juntas cuestan 500 euros, un 50% de lo que cuesta el macbook air.

No sé si es mas eficiente comprar el Air con 256GB y 8GB de RAM y en dos años venderlo por mitad de precio y comprar el que haya dentro de dos años. 

Esto tendría el mismo coste que comprar ahora mismo el actual Air con la ram y disco duro ampliado.

Da cosa comprar 7 años despues un ordenador con la misma RAM y tamaño de disco duro.... pero claro en aquel momento compré un Pro al que no he sacado rendimiento. 

Y es que lo que pide apple por ampliar RAM y disco duro parece una absoluta barbaridad. Sabeis si merece realmene la pena ? como no se puede ampliar tras comprarlo es una decisión deficil, igual ahora no necesito más RAM pero en 6 meses lo uso para trabajar y sí la necesito.

Al ritmo al que van mejorando los procesadores de Apple año a año probablemente sea más rentable cambiarlo en 2 años que aumentarle la RAM y SSD ahora. Pero sí, la verdad es que da cosa comprarse un ordenador con la misma RAM y SSD varios años después... Además que la RAM y SSD de Apple tampoco tienen nada de especial, y es una salvajada lo que piden por ampliarlos. Sobre si merece la pena o no la verdad es que no lo sé. Mira a ver cuánto espacio tienes ocupado en disco en tu Mac actual, y echa cuentas. Y con la RAM lo mismo, mira a ver cómo va la presión de memoria en el monitor de actividad en el que estés usando.

Link to post
Share on other sites
El 21/11/2020 a las 15:39, jp dijo:

¿Que tal? Si la verdad es que si que hace tiempo 😀.  Me alegro de charlar un rato con vosotros. Me han hecho gracia vuestros comentarios (Jorge y tu) con lo de este hombre,  porque pienso como vosotros. Ya digo que mi impresión es que algo sabe del tema de programación Mac. Pero a veces cuando se sale de ahí...

 

Yo también me alegro. Desgraciadamente la participación no está en sus mejores momentos, y es una espiral difícil de cambiar.

Respecto al tema de la RAM,... sí que pienso que se han quedado un poquillo cortos. Hoy en día 16GB es una cantidad suficiente y ya. Teniendo en cuenta que el Mini de 2018 se puede ampliar hasta 64GB de RAM, es un paso atrás obvio para el consumidor pese a las ventajas que pueda tener meter la RAM en el propio SoC.

Dicho esto, puestos a elegir qué se amplía en estas máquinas,... siempre elegiría la RAM antes que el SSD interno. Por una sencilla razón: la capacidad de disco se puede ampliar de forma externa (por ejemplo con unidades SSD Thunderbolt tipo Samsung X5, que tiene velocidades similares a una unidad interna).

Sin embargo la RAM no se puede ampliar de forma externa. Es un límite absoluto... así que si hay que elegir, puestos a gastar esos 230 Euros mejor hacerlo en la RAM antes que en el SSD interno. Ya habrá tiempo de poner otro SSD externo cuando haga falta.

  • Gracias 1
Link to post
Share on other sites

Hay que ver test concretos de apps con máquinas de 8 y de 16 GB. 

Porque si a uno le es suficiente por ahora con 8GB, casi que prevé mejor opción pillarlo con 8 y venderlo a mitad de precio en dos años y comprar uno quizá base pero con 16GB. Todo tiene su riesgo, claro. 
 

mucha gente está dándole vueltas a lo mismo: https://9to5mac.com/2020/11/18/opinion-is-the-base-macbook-air-m1-8gb-powerful-enough-for-you/

Edited by kerouack
Link to post
Share on other sites
Hace 17 horas, Andropov dijo:

Sí, en principio es el sistema operativo el que "coloca" los hilos en en núcleo que le parece apropiado. Pero me pareció significativo que una función nativa de swift como concurrentPerform ignore completamente el hyperthreading. En principio, ya que controlan el compilador y el SO, si hubiese alguna ventaja en utilizar el hyperthreading en esos casos lo habrían optimizado ya.

Además me da la impresión (aunque no sé lo suficiente como para opinar con rigor) de que con la cantidad de cores actuales el hyperthreading cada vez tiene menos sentido.  La ventaja principal era que si un hilo llegaba a un momento de stall y no podía continuar con la ejecución (porque estaba esperando a que llegase algún elemento desde la memoria principal, por ejemplo) otro hilo, sus unidades de ejecución (ALUs y demás) quedasen libres para el hilo que estuviese funcionando con hyperthreading y así aprovecharlas mientras el otro hilo está esperando. Pero claro, hoy en día hay procesadores con 8, 12 y 16 núcleos. Si estás ejecutando tareas diferentes probablemente te "sobren" núcleos que utilizar y no tengas que recurrir a uno lógico, y si estás utilizando todos los núcleos probablemente sea porque estás ejecutando alguna tarea altamente paralelizable y es poco probable que los núcleos lleguen a tener momentos de stall como para aprovechar el hyperthreading.

 

 

Pues es bastante probable que sea como comentas. Yo tampoco me he metido a trabajar con el hyperthreading, porque como te digo, directamente lo desconectamos por BIOS. Es una historia si luego quieres medir prestaciones con mezcla de núcleos. El tema de Swift que comentas, lo desconozco la verdad. En OpenMP si los considera, pero la verdad es que Apple no le hace mucho caso al OpenMP, y no se pueden distinguir los núcleos (o yo no se como hacerlo). Fíjate que incluso el compilador de C de GNU, tiene el OpenMP incluido. Bueno pues la versión de Apple para MacOSX lo quita. No se por qué. No se si es que quieren que se usen sus librerias de threads o que es lo que ocurre. De hecho para trabajar con OpenMP en Mac, lo que se hace es montar una version del GNU C que si tiene OpenMP (por ejemplo la de MacPorts). Yo a mis alumnos les suelo suministrar (a los que tienen Mac) instrucciones para montar los entornos OpenMP y MPI, sobre MacOSX, que (para variar) cambian según la versión del operativo. La última que tengo es para Catalina. Y además Apple tarda un monton de tiempo en sacar todo el MacOSX con las Command Line Tools arregladas para que todo funcione.

Edited by jp
Link to post
Share on other sites

Es una delicia volver a leer vuestros ilustrados comentarios.
Sobre que la memoria RAM solo sea ampliable a 16 GB no se si se debe a una estrategia de segmentar productos o a que el proceso de fabricación del SOC se encarecería demasiado. Apple ha presentado estos 3 primeros modelos como gama de entrada.
Hay que tener en cuenta que la RAM es compartida con la GPU así que para muchas tareas seguramente 16 GB sean lo apropiado.
Mi única duda sobre le evolución de estos procesadores es cuál será la estrategia respecto a las GPU. ¿Será capaz o le interesará a Apple desarrollar e implementar GPUs de alto rendimiento que compitan directamente con las Gráficas de la competencia a alto nivel? ¿Va a permitir Apple implementar gráficas eGPUs de terceros ? Desde luego descarto a Nvidia y no tengo claro que AMD quiera dar soporte si va a dejar de suministrar GPUS a Apple.
Según pruebas ésta GPU del M1 está algo por debajo de la Radeon 580 , desde luego para ser la gama "baja" no está nada mal.

La verdad es que la relación rendimiento/consumo de estos procesadores M1 es increíble. No me extraña que ésta tecnología se esté implementando en servidores pues el ahorro energético en un data center puede ser muy muy grande.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.