Jump to content

Andropov

Usuarios Activos
  • Posts

    1816
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Andropov

  1. El 4/11/2021 a las 23:59, sombra divina dijo:

    Creo que Apple la ha cagado bien , los nuevos procesadores de portatil IINTEL i9 12900HK son superiores en fuerza bruta a los M1MAX y seguramente mas baratos.... Al final tendran que abandonar la tecnologia ARM. Poco les ha durado el  portatil mas rapido ... una semana?

    Aunque Intel ha recuperado la 'corona' del máximo rendimiento en portátiles, realmente esto tiene más de maniobra de cara a la prensa que de avance real. Para la experiencia de usuario final, las mejoras que trae la 12ª generación de Intel no son tan grandes como parece. Lo más importante, los núcleos de eficiencia, que parecen ser el camino a seguir para bajar los consumos y conseguir una duración de batería decente. No obstante, esto debe ir acompañado de una gestión de procesos que sepa qué poner en cada tipo de núcleo de forma más o menos inteligente... y la solución de Intel, de momento, es pésima (más sobre esto luego).

    En cualquier caso, para conseguir superar ligeramente en rendimiento a los M1 Pro/Max, han tenido que volver a subir el consumo. Mi impresión es que han metido núcleos y subido la frecuencia hasta conseguir superar a Apple, y han sacado el procesador tal cual. No tiene mucho sentido, de otro modo, seguir subiendo el consumo y el TDP de sus procesadores para portátiles. El resto de la gama (los que no son el 12900HK) posiblemente tengan un consumo más contenido, y peor rendimiento. El 12900HK está ahí para decir "tenemos más potencia que Apple", aunque sea a costa de un consumo que se acerca al de una estufa eléctrica.

    En cualquier caso, Apple lleva años ya mejorando el IPC de sus procesadores a razón de un ~20% año a año, de forma totalmente estable. Intel lleva años atascado en mejoras del IPC de en torno al 2-5% (salvo cuando añadieron más núcleos) y este año ha sido el primero que ha conseguido un ~20% de mejora respecto al año anterior pero a costa de:

    • Nuevo proceso de fabricación Intel 10SF -> Intel7 (el próximo no llegará hasta 2023, si mal no recuerdo).
    • Nueva microarquitectura para los núcleos (solían rediseñarla cada 2 años, con el famoso 'tick-tock', nunca menos de un año, así que posiblemente tampoco haya nueva microarquitectura hasta 2023).
    • Paso de memoria DDR4 -> DDR5, que aumenta mucho el ancho de banda que puede usar la CPU (para el año que viene como mucho subirá la frecuencia de los módulos disponibles, pero no habrá un cambio de standard).
    • Incorporación de los núcleos de eficiencia (mejoran relación potencia/consumo, pero esta mejora ya la han 'quemado', no van a tener ningún salto similar en futuras generaciones porque los núcleos de eficiencia ya están ahí).
    • Nueva subida de consumos. Esto, lógicamente, tiene un límite, tanto por el lado de la batería como por el de la disipación de calor, e Intel ya se está pasando de rosca desde hace mucho.

    Así que no sé qué presentarán el año que viene, pero ya en este han agrupado las mejoras de varios años, para conseguir igualar un procesador de Apple que se basa en unos núcleos que salieron al mercado hace ya más de un año (con el A14). Apple lo tiene 'fácil' para mejorar otro 20% el año que viene, y es lo que se espera, pero Intel... no está nada claro. Parece que ya han puesto todo lo que tenían en este procesador. De hecho, no hay más que ver lo del Thread Director, o lo que ha pasado con AVX-512: se anunció que la 12ª generación mantendría el soporte para las instrucciones AVX-512, luego dijeron que no y que estaba desactivado por hardware en el SoC, y finalmente se ha revelado (según AnandTech) que no están desactivados por hardware (solo por firmware, y ciertas placas base lo desactivan) y que el motivo por el que se desactivó es que los núcleos de eficiencia no soportan AVX-512 (los de alto rendimiento sí) e Intel no sabía qué hacer para no enviar flujos que usasen AVX-512 a los núcleos que no lo soportasen. Una ñapa de última hora, vaya.

     

    El 8/11/2021 a las 8:09, borjam dijo:

    Olvidaba... Eso del planificador "inteligente" que Microsoft llama Thread Director lo tiene Apple desde hace mucho tiempo. En los iCacharros con núcleos "de eficiencia" y núcleos "para altas prestaciones" ¿cómo crees que decide qué correr en qué núcleo si no? 😉

    ¡Qué más quisiera Intel que que el Thread Director fuese ni una décima parte de lo inteligente que es Grand Central Dispatch + procesos con QoS en macOS! Verás, según ciertos reportes (https://twitter.com/deepschneider/status/1456314755380097027?s=21), el sistema parece tener una heurística la mar de compleja... pone la aplicación en primer plano en los núcleos de alto rendimiento y el resto en los de eficiencia. Así que si estás compilando un proyecto, o renderizando un vídeo, o algo que requiera potencia bruta, y te pones a leer el periódico en Safari mientras tanto, le puede costar el doble o el triple de tiempo. Una genialidad.

     

    • Me gusta 1
  2. El 27/11/2020 a las 20:02, jp dijo:

    Lo que comentas de la razón de no usar OpenMP, ni idea la verdad. Es una manía de Apple porque para Windows y Linux no se usan estas versiones tan extrañas del gcc, que usa Apple. Por cierto a que te refieres con GCD?

    Grand Central Dispatch, la librería de Apple para gestionar tareas multihilo en aplicaciones nativas. Creo que se introdujo en Snow Leopard. Y ahora hay unas cuantas mejoras propuestas para Swift ¿6? también sobre la gestión de tareas asíncronas y multihilo. Supongo que Apple sabe que es posible que no quede otra que mejorar sus CPUs a base de añadir más y más núcleos (porque la mejora del 30% en monocore año tras año es difícil de mantener) y eso requiere que las aplicaciones estén preparadas para trabajar con varios hilos, y las librerías para controlar eso (como GCD) pueden ser una tecnología clave en el futuro.

     

    El 22/1/2021 a las 12:15, krollian dijo:

    Tarde o temprano tendrán que “reconstruir” sus aplicaciones viejas. Porque ¿Hasta qué punto conviene remodelar y actualizar una aplicación que tiene más de monstruo de Frankenstein que de ser humano? Es decir, son tantas las capas, atajos y trucos que han de hacer para mantener vivo Illustrator, que llegará un momento que tendrán que crear uno nuevo.

    Yo también pensaba eso, pero parece que a Adobe le gusta que sus aplicaciones no tengan un "look & feel" propio del sistema operativo en el que están, sino un "look & feel" de Adobe. Lo cual también lleva a que nunca soporten bien las funciones de cada sistema operativo, sino con chapuzas. Pero parece que a Adobe eso no solo no le molesta sino que es lo que buscan. 

    El 22/1/2021 a las 19:05, krollian dijo:

    Hasta en Xataka lo comentan. Y se deduce lo inútil que es la política y métodos de actualización de aplicaciones de Adobe adaptando por partes o módulos el código antiguo a Apple Silicon.

    https://www.xataka.com/ordenadores/potencia-consumo-eficiencia-procesador-apple-m1-a-prueba-antes-despues-numeros-uso-real

    Anda, pues han hecho un buen análisis. No lo había visto.

    Hace 15 horas, krollian dijo:

    En todo de acuerdo. Pero que menor cantidad de RAM rinda más con Apple Silicon que en intel es porque precisamente es un SoC (System on a chip). Un sistema integrado con memoria RAM unificada, chips específicos y otra serie de elementos que se encuentran en la misma “placa”.

    Sí y no. Es cierto que tiene más hardware dedicado a tareas específicas que otras CPUs, pero en alguna medida eso lo hay en todas las CPUs modernas. E independientemente de eso, las tareas que pasan por los núcleos "normales" del M1 son más rápidos que los de Intel igualmente.

    La memoria unificada es más util para tareas que usan CPU+GPU a la vez, lo cuál hace que la mejora (la que corresponde a la memoria unificada) se note casi únicamente en aplicaciones profesionales. La otra novedad en la RAM es lo de meterla en el mismo paquete que la CPU, pero si no me equivoco la única ventaja con eso es "únicamente" en latencia al hacer las pistas entre la CPU y la RAM más cortas.

  3. El 23/11/2020 a las 1:45, jp dijo:

    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.

    Anda! Hace poco me hizo falta instalar otra versión de gcc con Homebrew para poder compilar un proyecto de GitHub que usaba OpenMP. Supongo que tendría algo que ver con esto. Sobre por qué Apple no incluye OpenMP, ni idea. Supongo que intentan forzar en lo posible que la gente use GCD.

    Suerte que tienen tus alumnos de que les des instrucciones para macOS también. Durante la carrera a mí me ha tocado hasta tener que configurar Wine sobre la marcha en unas prácticas porque hacía falta un programa para Windows y no habían avisado previamente 🙂 Menos  mal que ahora cada vez hay más Macs.

     

    El 23/11/2020 a las 20:49, kerouack dijo:

    Comparación de 8 GB VS 16GB. 

    Bueno, si la única diferencia significativa de rendimiento que ha encontrado es al exportar vídeo en RAW 8K parece que los 8GB de RAM son un mínimo más que aceptable. Con los SSD cada vez más rápidos tener que usar memoria virtual o leer desde disco cada vez tiene menos impacto en el rendimiento (aunque los SSD siguen siendo mucho más lentos que la RAM).

     

    Hace 53 minutos, iban2003 dijo:

    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.

    Ojo que la RAM no está en el SoC. Sí que está en el mismo paquete, pero no en el SoC.

    El límite de 16GB podría ser porque necesitarían aumentar los cachés del procesador para que al utilizar más de 16GB no empeorase el rendimiento o porque físicamente no hay chips de más densidad en el espacio que les ha designado Apple en el paquete. Si te fijas en el teardown de iFixit los chips de memoria tienen un espacio determinado y añadir más RAM probablemente requiera añadir más chips (y no chips de más densidad como probablemente hagan en el paso de 8 -> 16GB) y ocupar más superficie en el paquete (o stackearlos en altura). Sea como fuere no creo que se trate de una decisión de negocio para segmentar el mercado.

    ZRQGFteQwoIVFbNn.huge

    (Lo de la derecha son los chips de la RAM)

    Y lo de que la RAM esté compartida con la GPU no es nada nuevo, también pasaba con los Macs con gráficas integradas. Además en los programas que utilizan explícitamente la GPU muchas veces se mantiene una copia de las texturas o buffers que está utilizando la GPU en la RAM así que no tiene por qué ser tanto problema como parece. De hecho tiene sus ventajas, no tienes que estar copiando cosas de la RAM a la VRAM constantemente (aunque lógicamente el ancho de banda empeora).

    Sobre la potencia que tendrán las futuras GPUs de Apple aún no hay nada seguro. Los núcleos de la GPU que utiliza el M1 parecen tener un rendimiento/vatio bastante bueno, y en una GPU pudes aumentar la potencia "solo" con aumentar los núcleos sin demasiado problema, y la potencia aumenta casi linealmente con el número de núcleos que vas añadiendo. Así que nada impide a Apple hacer GPUs de potencia comparable a la de los MBP de 16" (por ejemplo). Lo que habrá que ver si les parece aceptable el consumo que eso implicaría. En las GPUs no llevan tantísima ventaja en eficiencia como en las CPUs.

    Está claro que dentro de los Macs no van a montar gráficas de terceros, y la duda que queda es si volverá a haber soporte para eGPUs en los Macs con Apple Silicon. Yo creo que sí, aunque no es precisamente la opinión mayoritaria. El soporte para eGPUs es una cosa que han implementado hace relativamente poco y la transición a Apple Silicon ya tenía que estar en marcha desde hacía tiempo. No le veo mucho sentido a que implementen soporte para eGPUs y al año o dos años lo eliminen de los nuevos Macs. Pero ya veremos.

  4. 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.

  5. 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.

     

     

  6. 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.

  7. 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...

  8. 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
  9. 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.

  10. Hace 15 horas, manelcat dijo:

    Yo tengo un iPhone SE que en enero cumplirá cuatro años. Antes tuve un 4S que me duró cinco. Estoy pensando de comprar un iPhone 12 Mini, ¿pero qué cable / cargador me tendría que comprar?

    He leído que lo mejor para la vida de la bateria es usar un cargador de 5W, esto quiere decir que puedo usar el cable/cargador que tengo del iPhone SE?

    Con el cable lightning - USB-c que trae el iPhone 12 Mini, hay que comprarme un cargador de USB-c de 5W?

    Gracias, saludos.

    El cargador que vende Apple para el iPhone es USB-C de 20W y funciona con el cable que viene en la caja (USB-C a Lightning). Yo no me preocuparía demasiado por lo de la vida de la batería y la potencia del cargador. Hay otras cosas, como la función de cargar la batería hasta el 80% por la noche y solo al 100% en las últimas dos horas antes de despertarte que ayudan más con eso.

  11. Hace 3 horas, borjam dijo:

    La aplicación está muy mal diseñada. Recordemos que ante problemas para recoger datos decía que todo estaba bien en lugar de mostrar algún tipo de error y conocer su estado (si funciona o no, una vez más) es muy confuso. Esto lo hace un alumno de la asignatura de programación y no solamente le suspenden, le dan un sopapo. 

    De hecho, sigue siendo así. Arreglaron el error con iOS 13.7 pero ante cualquier nuevo fallo pasará lo mismo. De hecho, hace unos días alguien abrió un issue en GitHub diciendo que le había llegado una notificación de exposición alta pero que al entrar en la app todo le salía normal...

     

    Hace 3 horas, borjam dijo:

    Ahora ya es muy tarde, no sirve para nada. Esto era útil cuando había brotes y no contagios comunitarios. Como tantas otras cosas, mucho postureo y coaching de globitos de colores y nula sustancia.

    Totalmente de acuerdo. Ha sido un fracaso absoluto, ya no tiene solución.

  12. Hace 5 horas, APB dijo:

    En este trozo del artículo no dicen eso:

    (Las negritas son mías)

    Si fuera como tú dices el fracaso aún sería peor.

    Sí, tienes razón, no sé por qué pensaba que eran sólo los generados.

    Respecto a cuánto se usan, hay alguien que está trackeando el uso de la app en GitHub.

    Hace 5 horas, APB dijo:

    Viendo que al conectarse Madrid el porcentaje de positivos comunicados a la app pasó del 0’8 a 1’2%  ahora subirá al ¿2%?!!! (Siendo generoso)

    Si estos datos son reales ¡que desperdicio de tiempo y dinero!. Desconozco si en los otros países ha funcionado “tan bien”.

    Por lo que he visto en Suiza el porcentaje está en torno al 20%.

  13. Hace 1 minuto, APB dijo:

    Viendo que al conectarse Madrid el porcentaje de positivos comunicados a la app pasó del 0’8 a 1’2%  ahora subirá al ¿2%?!!! (Siendo generoso)

    Si estos datos son reales que desperdicio de tiempo y dinero. Desconozco si en los otros países ha funcionado “tan bien”.

    Según entiendo por la noticia el 1,2% no es el porcenataje de positivos introducidos en la app, sino el porcentaje de positivos a los que se les ha asociado un código. Luego, de ese 1,2% de positivos que sí tienen un código asociado, los usuarios lo meterán (o no) en la app cuando se lo comunique el rastreador, si es que tienen la app instalada.

  14. El 28/10/2020 a las 11:13, Arroway dijo:

    Pero aun así, la diferencia es tremendísima (adjunto fotos de la pantalla retina del mac, y del monitor externo).

    De forma que estoy dispuesto a cambiar el monitor externo si es necesario para quitar este efecto. Pero como no entiendo la causa real, no quiero lanzarme a comprarlo y que siga pasando lo mismo. El monitor externo tiene una resolución ahora mismo de 2560x1080 (panoramica), y tiene 96 ppi.

     

    CONSULTA: qué monitor y/o qué características de monitor debo conseguir para que el texto se vea de forma similar al mac?. No necesito tiempos de latencia altísimos ni de refresco altísimos. Pero sí una definición buena y un ajuste del color decente.

    Un monitor de resolución estándar (1080p o incluso 1440p) no se ve ni parecido a la pantalla del Mac. El MacBook utiliza 4 píxeles por cada píxel que usa el monitor, y con unas dimensiones más reducidas, así que se ve todo mucho más "suave".

    Lo que estarías buscando para tener un monitor con una pantalla de calidad similar a la de tu Mac (que no es fácil) es uno con una densidad de píxeles (ppi) parecida, IPS (amplio ángulo de visión) y P3 (soporte para más colores que el estándar de color sRGB, aunque esto probablemente sea lo menos importante).

    Así de memoria (estuve mirando hace poco) tienes o los UltraFine de LG (4K en 24" que equivale a ~186 ppi o 5K en 27" que equivale a ~219 ppi) o el Dell P2415Q (4K en 24", ~186 ppi). Cualquiera de ellos es IPS, pero el Dell no tiene gama de colores P3 (los UltraFine sí). Todos tienen un refresco de 60Hz.

    El resto de monitores suelen ser 4K en 27", que ya tiene una densidad de píxeles bastante más baja (163 ppi), aunque se seguiría viendo notablemente mejor que tu monitor actual.

  15. Hace 58 minutos, jad.mac dijo:

    Ah, y tu noticia del País no se puede ver sin suscripción...

    Qué raro, yo no estoy suscrito y la podía ver. ¿Quizá haya un límite diario o mensual de artículos que se pueden ver? En resumen, hablan de una "brecha de seguridad" y de que Amazon tenía acceso a los "usuarios" positivos y que los "datos" de los usuarios no estaban protegidos de terceras personas. Realmente lo único que estaba expuesto eran las direcciones IP públicas de las personas que subían un positivo a la aplicación (porque los usuarios que no subían un positivo no conectaban con el servidor nunca).

    Al contactar con el servidor de DNS para resolver la dirección del servidor al que se suben los positivos alguien en la red local podría monitorear el tráfico y deducir que si has establecido una conexión con el servidor en cuestión es porque estás subiendo un positivo. Además, Amazon (que hostea el servidor) puede ver las IPs que se conectan a él y por el mismo motivo deducir que son IPs de positivos.

    Pero claro, esto a lo que han llamado "brecha de seguridad" que es solo un análisis de tráfico tiene muchas pegas que luego no explican. Amazon solo ve las IPs públicas, y ahora que en España todos los proveedores están usando CG-NAT, esas IPs están compartidas entre varios usuarios y no podrían identificar a personas individuales. Y aunque no fuese así y hubiese una IP pública por cada router, muchos de ellos se comparten (por ejemplo, en la WiFi de una familia) y no podrían saber cuál de todos ellos ha subido el positivo. Y del análisis local del tráfico, que requeriría a una persona físicamente presente en el rango de tu WiFi y conectado a ella, ya ni hablamos...

  16. Bueno el otro día leí en un (disparatado) artículo de El País que sólo en el 1,2% de los positivos Sanidad generaba un código para introducir en la app de Radar Covid. Así que casi que da igual cómo funcione la app, si las administraciones no la usan... 

    (Lo de disparatado lo decía porque el artículo habla de una supuesta brecha de seguridad en la que se habrían estado filtrando todos los datos de los usuarios, que al final resultaba ser que el host del servidor que usa la app (Amazon) puede ver las direcciones IP de las personas que se conectaban).

  17. Otros años no lo tenía, ¿no? A mí me parece un error ligar la pantalla más grande a una mejor cámara. Sobre todo porque ya estamos hablando de tamaños de pantalla que no son cómodos para todo el mundo.

  18. El 12/9/2020 a las 18:15, Subversiondeluxe dijo:

    Y uso TOR para hacer búsquedas en Google cuando DuckDuckGo no me ofrece resultados suficientemente relevantes. Tb para conectarme a mi banco y otras cosas.

    Esto es una idea horrenda. Tor sólo sirve para anonimizar tu conexión a internet y no para ofrecerte más seguridad. Cualquier nodo de salida de la red Tor puede inspeccionar todo el tráfico que salga de él. Teóricamente seguirías protegido porque los bancos (y la mayoría de internet, realmente) usan HTTPS, pero es un riesgo innecesario no sé muy bien para qué. Tor es precisamente lo que *nunca* deberías usar para conectarte a tu banco.

     

    El 3/9/2020 a las 12:15, AzagraMac dijo:

    pero luego tienen la wifi de casa tal y como se lo da el operador

    La última vez que tuve que (digamos) auditar una serie de WiFis las únicas contraseñas vulnerables eran, precisamente, las que habían puesto los propios usuarios. Y un par de redes de hace más de una década que sí que tenían la contraseña del operador. Pero actualmente ningún operador configura las WiFis que instala con contraseñas predecibles o vulnerables.

  19. El 11/9/2020 a las 10:13, borjam dijo:

     

    Me da la sensación de que esto es el típico ejemplo de programación cárnica. Con la pasta que ha costado deberían haber montado un equipo de soporte pendiente del Twitter que anunciaron y está muerto y tener un grupo de programadores ¡aunque sea uno! pendiente de actualizaciones, probar betas de iOS, etc. 

    En lugar de eso sospecho que han subcontratado el desarrollo y ya, y lo mismo tienen que volver a subcontratar correcciones o, al menos, si son programadores en plantilla ahora estarán dedicados a otra cosa.

    Trescientos mil lereles en números redondos, dicen por ahí.

    Sí, suena exactamente a lo que dices. De momento no están respondiendo a los issues ni a las PR desde hace días, así que imagino que ahora mismo no habrá nadie asignado.

     

    Hace 21 horas, Albarre dijo:

    Pues entonces esperemos que lo solucionen cuanto antes ( ya sea Apple, el Gobierno o los dos), porque para que queremos tener esto instalado si no está funcionando y encima, que es lo peor, creyendo que nos puede servir para algo

    Y esto sólo ocurre en iOS o también en Android?

    Por cierto si no se desinstala y se vuelve a instalar, que es cuando aparece lo de actualizado el 01/07/2020, se queda en la fecha en la que se actualizó a iOS 13.7

    Creo que el problema es solo en iOS, pero no estoy muy al día en las noticias sobre Android. Lo de que se quede en la fecha de actualización a iOS 13.7 es porque se queda en el último momento en el que funcionó.

    Y el problema parece ser del gobierno. Otras aplicaciones (SwissCovid) funcionan en iOS 13.7 desde el primer día.

  20. Hace 3 horas, borjam dijo:

    Parece claro que tienen que actualizarla.

    https://github.com/RadarCOVID/radar-covid-ios/issues/4

    Me sorprende porque en la versión subida a GitHub ya están utilizando DPT3 1.2.1, pero la versión de la AppStore está evidentemente desactualizada. ¿Podría ser problema de Apple?

     

    Hace 5 horas, APB dijo:

    Ya que lo has mirado, ¿accede directamente al registro o hace una llamada al iOS para que le pase la información? Si accediera directamente tendría sentido el fallo si Apple hubiera decidido cambiar el registro de sitio, al no encontrarlo considera que aún no existe y aparece la fecha por defecto. No lo tiene tanto que Apple haya decidido cambiar la llamada y no haya mantenido la vieja temporalmente activa, aparte que iOS respondería con algún error ¿verdad?.

    Lo que no sabemos si también falla el apartado de declarar tu positivo. Eso si es preocupante, para los que estéis en una CCAA donde los podáis declarar, ya que seguramente iOS se encargará de avisarte si aparecen contactos positivos en tu lista.

     

    A menos que Borjam consiga acojonarlos, dudo que saquen una nueva versión hasta que iOS 14 haya salido o esté en fase GM.

     

    Hasta donde he visto hace una llamada a la API de DPT3 que es la encargada de gestionar todo lo de las Exposure Notifications, que no es directamente accesible por las aplicaciones. Simplemente en el código para recuperar la información devuelta por la API tienen esto (ExpositionUseCase.swift):

    private func tracingStatusToExpositionInfo(tStatus: TracingState) -> ExpositionInfo? {
    
            switch tStatus.trackingState {
            case .inactive(let error):
                var errorEI = ExpositionInfo(level: expositionInfoRepository.getExpositionInfo()?.level ?? .healthy)
                errorEI.error = dp3tTracingErrorToDomain(error)
                return errorEI
            default: break
            }
    
            switch tStatus.infectionStatus {
            case .healthy:
                var info = ExpositionInfo(level: ExpositionInfo.Level.healthy)
                info.lastCheck = tStatus.lastSync
                return info
            case .infected:
                return ExpositionInfo(level: ExpositionInfo.Level.infected)
            case .exposed(days: let days):
                var info = ExpositionInfo(level: ExpositionInfo.Level.exposed)
                info.since = days.first?.exposedDate
                info.lastCheck = tStatus.lastSync
                return info
            }
        }

     

    ExpositionInfo es la estructura/clase que tienen definida para almacenar los valores devueltos por la API en una estructura más manejable para la aplicación. En esa estructura tienen varias propiedades, una de ellas llamada "lastCheck". En el primer caso (.inactive) no modifica el valor de lastCheck en el objeto ExpositionInfo recién creado. Como no tiene ningún valor y en el viewcontroller de la pantalla de la exposición hay un valor por defecto hardcodeado ("01.07.2020") si no le dan ningún valor a la propiedad lastCheck del ExpositionInfo recién creado (como sucede en el caso .inactive) aparece en pantalla el valor por defecto, "01.07.2020". ExpositionViewController.swift:

    func expositionDateWithFormat() -> String {
        if let date = self.lastCheck {
            let formatter = DateFormatter()
            formatter.dateFormat = "dd.MM.YYYY"
            return formatter.string(from: date)
        }
        return "01.07.2020"
    }

     

    Bueno y como veis en el primer fragmento de código, en caso de error y no encontrar el estado de exposición actual lo pone por defecto en modo "exposición baja" ("?? .healthy" en el código). Aquí de acuerdo con borjam, lamentable que por defecto en vez de mostrar que no está funcionando falle "silenciosamente" y diga que todo va bien.

    En los otros casos (si el tracingState no es .inactive) si os fijáis sí que le dan un valor a la propiedad lastCheck ("info.lastCheck = ..." en el código) y por tanto la fecha sí que aparece bien en el código.

    Así que se ha juntado el que la aplicación no está funcionando en iOS 13.7 / iOS 14b6 (hace 10 días ya...) con que cuando la app falla muestra lo mismo que cuando está funcionando que cuando no.

  21. La mía sigue en "actualizado 30.08.2020".

    Por cierto, han subido el código de la aplicación a GitHub (justo hoy): https://github.com/radarcovid

     

    EDIT: Viendo el código fuente parece que la fecha 01.07.2020 está hardcodeada en el código y es el valor que devuelve cuando no ha conseguido recuperar la fecha de la última sincronización con la base de datos. Vaya, que no se está sincronizando.

    EDIT 2: Parece que por defecto en caso de error la app muestra "Exposición baja" (aunque no haya podido determinar si realmente es así) y en ese caso aparece la fecha de 01.07.2020 que está por defecto en el ViewController. En mi opinión, una idea regular eso de que en caso de error la app aparezca como si estuviese funcionando bien y no muestre ningún error (más allá de la fecha mal puesta).

  22. El 3/9/2020 a las 15:26, borjam dijo:

    - La propia aplicación dice que la última comprobación se hizo hace días.

    - Si se intenta reinstalar se queda bloqueada en la pantalla de petición de permiso para activar el rastreo, requiriendo un reinicio de aplicación para poder progresar a la siguiente (petición de autorización para notificaciones).

    A mí me pasa lo mismo en iOS 14.0 Developer Beta 6. Es más, aunque la tenía activada, al entrar a la aplicación hoy después de varios días ha salido un aviso de que las Exposure Notifications no estaban bien configuradas en ajustes (sí lo estaban). Desactivando y activando el switch deja de quejarse pero la última comprobación sigue apareciendo de hace varios días.

×
×
  • 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.