¿Por qué los teléfonos Android tienen más núcleos que las computadoras?

Las computadoras portátiles generalmente tienen como máximo cuatro núcleos, y los núcleos duales son probablemente más comunes. Recientemente cambié de quadcore a dualcore y puedo confirmar que hay un número limitado de casos de uso para quadcore, incluso con tareas intensivas de CPU.

Por otro lado, en los teléfonos móviles, los quadcores, hexacores y octacores parecen ser comunes. ¿Por qué? ¿Qué tareas pueden utilizarlos?

Entiendo que big.LITTLE puede ser parte de la respuesta. Es decir, el principal beneficio de tantos núcleos no es la capacidad de usarlos todos simultáneamente, sino usar un núcleo con un consumo de energía adecuado para la carga de trabajo actual. Sin embargo, por ejemplo, el Snapdragon 625 tiene ocho núcleos Cortex-A53, lo que no parece ser un caso para big.LITTLE.

Quizás la arquitectura ARM tiene un punto más bajo de rendimiento óptimo por vatio. Es decir, tener un solo núcleo ajustado para un rendimiento óptimo por vatio da como resultado un rendimiento más bajo en ARM que en Intel. Por lo tanto, se utilizan más núcleos para ofrecer el rendimiento. Esto es solo una hipótesis.

Pero incluso en este caso, no veo qué carga de trabajo puede usar de manera eficiente, digamos, ocho núcleos en un teléfono móvil. En las computadoras portátiles, puedo imaginar algunos como la compilación completa (no incremental) de un proyecto. Pero en los teléfonos?

  • Los juegos pueden tener un alto nivel de rendimiento, pero por lo general requieren el rendimiento de la GPU en lugar de la CPU, ¿no es así?
  • Teóricamente, varios núcleos podrían acelerar la compilación AOT de Android Lollipop/Marshmallow al instalar o actualizar (es decir, la fase "Optimización de aplicaciones 3/121"). Sin embargo, no estoy seguro de si esto puede utilizar múltiples núcleos. Por lo que recuerdo del código, solo se compila una aplicación a la vez, pero tal vez haya cierto paralelismo dentro del proceso de compilación en sí.
  • Además, Android 7+ podría utilizar múltiples núcleos al compilar. Pero dado que, según se informa, compila cuando está inactivo y cargando, el beneficio parece ser bastante mínimo. Al menos cuando uno carga el teléfono durante la noche, realmente no me importa si toma 30 minutos o dos horas en ese escenario.
Como señalé en mi respuesta, tenga en cuenta que parece estar mirando las cosas al revés. La ejecución de muchos núcleos/paralelos es la norma, no es su teléfono el que es una anomalía por tener muchos núcleos, es la CPU de la PC la que es una anomalía.
Su pregunta es errónea, las PC pueden tener más núcleos que teléfonos. intel.com/content/www/us/en/products/processors/core/x-series/… Y eso ni siquiera se refiere a las máquinas de clase servidor, que pueden tener docenas o incluso cientos de núcleos. (Y algunas supercomputadoras entran en el rango de miles de núcleos).
@JAB Claro, pero no estoy hablando de la cantidad máxima de núcleos, sino de la cantidad típica. Para las computadoras portátiles, más que quadcores son bastante poco comunes, pero podría encontrar alguna excepción, tal vez con Xeon. Para los teléfonos móviles, incluso los octacores parecen ser relativamente comunes.
"Recientemente cambié de quadcore a dualcore y puedo confirmar que hay un número limitado de casos de uso para quadcore, incluso con tareas intensivas de CPU". - ¿Puede ampliar y explicar cómo llegó a esa conclusión?
@Abdul Proviene principalmente de mis observaciones (ver la carga del sistema usando htop o una herramienta similar) y parcialmente de mis conclusiones. Incluso algunas tareas en las que esperaría paralelización (p. ej., representación mediante OpenScad) son de un solo núcleo. Firefox (ESR) generalmente consume como máximo un núcleo. Compilación incremental: no la he medido, pero intuitivamente, no hay muchas oportunidades para encontrar tareas independientes. (La compilación completa es un caso diferente).
Tenga en cuenta que FF puede hacer uso de múltiples núcleos. Abra about:configy verifique la entrada Multiprocess Windows. En mi caso, dice 0/1 (Disabled by add-ons)pero si desactivo los complementos ofensivos, estará activo.
@Daniel Tal vez esté allí en versiones más nuevas, tengo 45 ESR. De todos modos, esto permitirá el uso de múltiples núcleos para múltiples páginas (y tal vez las páginas estén agrupadas en procesos por dominio, creo), sin usar múltiples núcleos para una página. Pero tal vez incluso esto llegue, como sugieren los experimentos con Servo.

Respuestas (8)

Como ya ha señalado, la estrategia de combinación big.LITTLE (técnicamente, HMP , clústeres heterogéneos de procesamiento múltiple ) es la razón principal de tantos (ya veces abrumadoramente muchos) núcleos. Un dispositivo móvil a menudo se encuentra con múltiples escenarios, incluidos los de carga pesada y ligera.

Un ejemplo de clase de consumidor extremo es Helio X20 de MediaTek, que tiene 2 núcleos A72 orientados al rendimiento, 4 núcleos A53 balanceados, más 4 núcleos A35 de bajo consumo. Eso es muy flexible en diferentes casos de uso. Sin embargo, creo que 8 núcleos 2 clústeres suelen ser suficientes.

También hay otro ejemplo de escritorio, la serie Snapdragon 800 de Qualcomm (S 800, S 801 y S 805). Solo hay 4 núcleos de la misma microarquitectura en cada SoC, con 2 con frecuencia más alta y 2 con frecuencia más baja. Qualcomm fabricó estos SoC porque confiaba mucho en su propia microarquitectura (Krait 400 y Krait 450).

Para los juegos, incluso si aparentemente exigen el rendimiento de la GPU en lugar de la CPU, aún suponen una gran carga para la CPU. Una GPU no puede funcionar sola sin que otra cosa le suministre datos para procesar, y ese es uno de los principales trabajos que realiza la CPU mientras juegas. En la mayoría de los casos de juegos, la GPU solo genera gráficos, mientras que todos los demás trabajos, como cargar datos, recursos y activos, y calcular la mecánica del juego, como el sistema, el entorno y la física, los realiza la CPU. No observará una velocidad de fotogramas más alta si actualiza su GPU mientras se limita a una CPU de gama baja.

Una razón secundaria es cómo Android utiliza los recursos de la CPU . Android prácticamente crea su propio entorno de aplicación. No usa nada más que códigos (y API) de Java, pero tiene su propia máquina virtual llamada Dalvik, que luego fue reemplazada por ART (API Nivel 21). Los APK tienen sus códigos ejecutables en un formato "neutro", muy parecido a los .classarchivos en Java. Antes de que se ejecuten, los códigos se compilan una vez más en las instrucciones nativas de la máquina [1] . El proceso de compilación es multiproceso y puede utilizar varios núcleos para mejorar el rendimiento.
Y cuando se ejecuta una aplicación, hay varios otros procesos y mecanismos (como el recolector de basura) que se ejecutan junto con la aplicación o en paralelo a ella. Más núcleos pueden permitir que los procesos de apoyo se ejecuten de manera más eficiente, así como la aplicación principal.
1. Si usa un identificador de tipo de archivo, encontrará que los archivos dex "optimizados" están en formato ELF, mientras que los archivos dex "neutrales" solo tienen un formato propio.

Otra razón menor es que los núcleos ARM no pueden funcionar tan rápido como un chip Intel x86 . La microarquitectura Intel x86 se remonta a 1976, cuando se empezó a diseñar el chip Intel 8086 , lo que significa que el x86 se ha desarrollado durante mucho tiempo. Un solo núcleo ARM Cortex-A73 moderno de gama alta es tan poderoso como un núcleo Intel Clarkdale, tomando como ejemplo el Core i5-660 (GeekBench, de un solo núcleo). Esto se debe a que x86 es una microarquitectura CISC mientras que ARM es una RISC.microarquitectura. Seguramente no querrás un teléfono que se vuelva lento con solo dos o más aplicaciones activas. Más núcleos ayudarán a aliviar la presión. Es por eso que los SoC de doble núcleo son relativamente populares solo en los relojes inteligentes. ¿Quién necesita rendimiento en un reloj inteligente?

Curiosamente, más núcleos darán como resultado menos energía que un solo núcleo con la misma carga . La relación entre la frecuencia de la CPU y el consumo de energía es más que lineal, por lo que el doble de la frecuencia siempre resultará en una demanda de más del doble, o incluso 3 o 4 veces más de energía, mientras se entrega menos del doble de rendimiento (debido a otras limitaciones de recursos como la memoria caché). ). Por lo tanto, 4 núcleos pueden vencer fácilmente a un solo núcleo con la misma carga, brindando un mejor rendimiento y, al mismo tiempo, demandando menos energía.

Otras lecturas:

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
Recuerdo haber leído o visto en alguna parte que el kernel de Linux había funcionado originalmente en un buen soporte multinúcleo con un enfoque en las supercomputadoras, hace muchos años, y estos esfuerzos resultaron útiles "en el futuro" (ahora) para los teléfonos inteligentes, como una especie de " accidente"
Esta respuesta no parece responder realmente a la pregunta, a pesar de ser aceptada. Esta respuesta parece estar respondiendo "¿Por qué podría querer núcleos adicionales en mi teléfono?" que no es la cuestión que nos ocupa. No explica la diferencia entre PC y teléfono. Los puntos dados sobre por qué un teléfono puede querer más núcleos también se aplican a las computadoras de escritorio, especialmente los puntos sobre los juegos.
Volví a agregar el comentario anterior después de que se eliminó con los comentarios movidos al chat. Mi comentario no fue parte de ninguna "discusión extendida" y fue específicamente sobre la integridad de la (no) respuesta que se presenta aquí. Si realmente respondiera la pregunta, haría +1, pero dado que en realidad no responde la pregunta, necesita que se agregue algún contenido apropiado.
El reclamo de 1976 sobre las CPU x86 es algo engañoso. Los núcleos ARM se remontan al proyecto Acorn RISC Machine en 1983, solo 7 años después, y en cierto modo ser más nuevos es una ventaja, Acorn aprendió varias cosas que estaban mal con el desarrollo de x86 y diseños de CPU similares y las incorporó en BRAZO.
La principal diferencia entre los dos ahora es que Intel ha invertido cantidades masivas en la construcción de CPU que sean lo más rápidas posibles excluyendo todo lo demás, mientras que ARM se centró en CPU que son mucho más eficientes, tanto en términos de consumo de energía por ciclo, y costo
Además, RISC vs CISC no tiene nada que ver con eso, las CPU Intel ejecutan un núcleo RISCish internamente (uops). La verdadera diferencia es fuera o orden vs en ejecución de órdenes.
Las tarjetas de video tienen miles de núcleos. Todo depende de para qué se utilicen.
@user1937198 AFAIK hay ambos tipos de CPU (en orden y fuera de servicio) para ARM y x86/x64.
@Overmind Las tarjetas de video son una categoría bastante diferente (los núcleos de la CPU son independientes, los "núcleos" de la GPU de los que está hablando son, de hecho, hilos acoplados) y están diseñados para una carga de trabajo bastante diferente.
Lo de x86 está bastante... mal. Son chips superescalares, las implementaciones básicas no serían tan buenas como la canalización RISC clásica utilizada en la mayoría de los chips ARM. También vale la pena señalar que vincular núcleos con diseños superescalares es MUY difícil debido a la ejecución fuera de orden y la jerarquía de caché. Nadie sabía lo que se estaban perdiendo, por lo que realmente no había demanda. Si nota que algunas de las iteraciones más nuevas de Intel no están en los chips de alto número de núcleos, están en Broadwell, esto se debe a que descartaron cosas de sincronización, sin espacio.
Ni el ISA x86 ni JavaScript son intrínsecamente particularmente adecuados para ser rápidos; de hecho, en muchos aspectos es todo lo contrario (por ejemplo, en x86, las instrucciones complejas e irregulares ejercen presión sobre el decodificador, todos los efectos secundarios dificultan el análisis de las dependencias y la explotación de las instrucciones). -nivel de paralelismo, tener tan pocos registros fuerza el derrame en la pila; en JavaScript, tener tipificación dinámica y búsqueda de atributos obliga a que muchas decisiones se retrasen en tiempo de ejecución).
Aun así, son los más rápidos de su clase por la misma razón: alguna gran empresa contrató a las mejores mentes en su campo y les hizo trabajar duro en el problema; con suficiente I+D, se pueden solucionar muchos problemas de diseño y el resultado puede tener un mejor rendimiento que los diseños que serían equivalentes o mejores en su diseño inicial.
El comentario sobre Java es totalmente irrelevante. La mayoría de las aplicaciones de rendimiento informático serias no usan Java, sino código nativo a través de NDK: juegos, motores de navegador, procesadores de PDF... nadie está tan loco como para probar esto con Java. Java en Android estaba destinado a los lenguajes de secuencias de comandos en las computadoras de escritorio.
Estuve contigo hasta "Esto se debe a que x86 es una microarquitectura CISC mientras que ARM es una microarquitectura RISC", que no tiene nada que ver con eso. Se debe a que el x86 lanza hardware para identificar dependencias y enviar el flujo de instrucciones a múltiples canalizaciones específicas de chip de la manera más eficiente posible, donde "tan eficientemente" significa "superar su ejecución", con el ahorro de energía como una preocupación secundaria seleccionable. La forma específica en que lo hace el x86 es decodificando el CISC ISA a un RISC µISA y alimentándolo a un núcleo RISC , luego reasignando los resultados al modelo CISC al finalizar.

La razón es tan simple como complicada.

La respuesta corta es "porque el mercado de la telefonía móvil nunca ha sido ni es impulsado por Intel".

La respuesta larga es demasiado larga para resumirla aquí, pero el concepto básico es que Intel ha dominado el mercado de PC durante años con todos los medios posibles, hasta el punto de pagar y corromper (y ser multado por ello) para que sus CPU sean las mejores. primera y única opción para los fabricantes de PC.

Tener el control total del mercado le ha permitido a Intel inflar los precios de las CPU mientras decide artificialmente qué características y cuánta potencia de procesamiento deberían haber querido los usuarios, y si analizas un poco la historia de Intel notarás que su principal fortaleza está básicamente en el aumento de la frecuencia de las CPU, por lo que en su mayoría nunca trató de hacer algo realmente inteligente o innovador; y no lo necesitaba, porque simplemente puede decirle a la gente "no necesitas más núcleos, pero tengo esta nueva y jugosa CPU que funciona 100 MHz más rápido". Al mismo tiempo, podría vender CPU multinúcleo en el mercado de servidores a precios absurdamente altos (porque los servidores siempre han necesitadotoneladas de energía paralela, hasta el punto de que hay una tendencia actual en intentar realizar servidores que usen... ¿adivinen qué? Cientos de las CPU de su teléfono barato trabajando en paralelo)

Esto, a su vez, se ha reflejado en la comunidad de desarrolladores que nunca se ha dado cuenta de la importancia de la programación paralela, por lo que muchos, si no la mayoría, nunca se molestaron en usar más de un subproceso a la vez, o, para expresarlo en un no manera técnica, haciendo que su software haga más de una tarea a la vez. Lo cual, por cierto, tiene sentido cuando el 99 % de su base de clientes tiene dos núcleos como máximo. Lamentablemente, esto ha llevado a la leyenda de que los algoritmos paralelos son realmente difíciles de implementar y solo se aplican a un pequeño subconjunto de problemas.

En cambio, finalmente, el mercado móvil nunca ha visto el éxito de Intel; todo lo contrario, en realidad, como sucede la mayoría de las veces, Intel intenta hacer algo diferente a la arquitectura X86 habitual. Entonces, al carecer de influencia y control del mercado, los otros productores de CPU se han ido en la dirección que ha sido la normalidad durante mucho tiempo fuera del mercado de las PC: la computación paralela.

¿Estás seguro de que estás respondiendo la pregunta correcta ?
@iBug Obviamente, sí. Si alguien elige una oveja blanca y una oveja azul y pregunta "¿por qué la oveja blanca no es azul como todas las demás ovejas?" el problema al que se enfrenta el OP es pensar que una oveja blanca es una excepción, mientras que la verdad es todo lo contrario.
¿Mmm? Creo que necesita más inteligencia para hacer un núcleo rápido que para hacer un núcleo lento y luego Ctrl-C/Ctrl-V. Recuerdo haber leído sobre una entrevista en la que discutían la dificultad de Intel para acelerar aún más las CPU y un científico informático dijo: "No quiero más núcleos, quiero núcleos más rápidos", y el chico de Intel dijo algo así como "Núcleos más rápidos es lo que quieres". , pero más núcleos es lo que obtendrás"
@iBug Esta respuesta se aplica a la pregunta del OP mejor que la respuesta aceptada. La respuesta aceptada es la que no responde a la pregunta correcta.
"inflar los precios de la CPU artificialmente" -> Si Intel estaba inflando los precios artificialmente, ¿por qué su competencia usa hardware de precio similar y por qué las computadoras con tecnología ARM apestan tanto en comparación con el hardware de Intel? Este odio a la inteligencia es ridículo. Hacer CPU es difícil . Lo que hizo que ARM fuera tan popular entre los dispositivos móviles fue la idea big.LITTLE, algo que concibieron antes que Intel.
Además, estoy bastante seguro de que fue Intel quien comenzó con el multinúcleo a precios económicos, con la línea Celeron D. Tu respuesta no tiene sentido.
Intel no controla el mercado de chips para PC y no lo ha hecho durante muchos años. Y la razón por la que los diseñadores de chips cambiaron de relojes más rápidos a más núcleos es que los relojes más rápidos estaban enfrentando algunas limitaciones físicas fundamentales. Más núcleos era un problema mucho más difícil de resolver, por lo que lo pospusieron hasta que fue la forma más rentable de seguir aumentando el rendimiento.
Esta respuesta es definitivamente sobre shesp.
Esta respuesta no tiene sentido. Intel es uno de los fabricantes de chips para PC. Y la pregunta es por qué los teléfonos tienen más núcleos que las PC. No por qué los teléfonos tienen más núcleos que las PC Intel. Esta respuesta asume Intel = PC, que no es el caso.
Esto es más una diatriba sobre la malvada corporación Intel, que en mi opinión no es bien merecida ya que ARM también jode a los fabricantes de chips independientes con licencias.
Intel ha hecho tratos turbios que quedaron expuestos hace 20 años; en ese momento tenían AMD y Cyrix y competidores y estaban tratando de tener un cuasi monopolio. Tienen algunas de las fábricas más avanzadas que puede encontrar y la serie x86 ha sido CPU RISC internamente durante mucho tiempo con un decodificador al frente para las instrucciones CISC. Estás dando una opinión totalmente inculta y desinformada.
No entiendo por qué esto está recibiendo tantas respuestas positivas ; esto no responde a la pregunta original y está lleno de tonterías. Siempre se ha buscado aumentar el rendimiento de un solo subproceso porque acelera todo fácilmente. Todos los programas más antiguos de un solo subproceso obtendrán el almuerzo gratis, y los de subprocesos múltiples también se beneficiarán. Dejamos de aumentar la frecuencia debido a los límites físicos, y aún así, debe estar seriamente engañado si cree que la única diferencia entre un 486 y un Pentium 4 es el reloj de instrucciones: los procesadores superescalares x86 son extremadamente ...
... bestias complejas que logran ejecutar un IA heredado aplicando todo tipo de optimizaciones automágicas (ejecución fuera de orden/paralelismo a nivel de instrucción, cambio de nombre de registros, predicción de bifurcaciones, todo tipo de cachés, explosión/fusión de µops) en una forma casi completamente transparente manera. Simplemente no puede lograr este nivel de rendimiento simplemente haciendo un 486 con mayor velocidad de reloj. La afirmación de que "los algoritmos paralelos son realmente difíciles de implementar" es una leyenda también es completamente falsa. Además de los llamados problemas "vergonzosamente paralelos", hacer versiones paralelas de algoritmos es uno de los más difíciles...
... desafíos a los que nos enfrentamos y, en muchos casos (por lo general, cuando necesita datos de la etapa anterior del algoritmo para alimentar la siguiente), simplemente no se puede hacer, a menos que tenga un flujo interminable de datos para elaborar, para que pueda canalizar. Además, la programación paralela eficiente y correcta cuando tiene recursos compartidos para hacer malabarismos entre múltiples hilos de ejecución es un desafío extremadamente difícil por sí solo. Incluso Linus Torvalds advirtió contra ser demasiado inteligente al inventar primitivas de sincronización, dado que, por lo general, casi nadie lo hace bien.

Hay dos factores en marcha, uno muy práctico y el otro histórico.

La razón práctica es el uso de arquitecturas mixtas en los teléfonos. El consumo de energía es fundamental para los teléfonos y los teléfonos pasan mucho tiempo en modos en los que requieren muy poco rendimiento. Tiene sentido tener algunos núcleos optimizados para un consumo de energía mínimo cuando se necesita poco rendimiento y tener algunos núcleos optimizados para proporcionar el máximo rendimiento cuando se necesita.

La otra razón es en gran parte histórica. Hasta 2005 más o menos, las CPU de escritorio eran todas de un solo núcleo. Mejorar el rendimiento de la CPU de escritorio consistió casi exclusivamente en crear un núcleo que pudiera ejecutar tantas instrucciones por segundo como fuera posible. Incluso hoy en día, tanto software de escritorio no puede aprovechar al máximo los núcleos múltiples que muchos preferirían una CPU con 4 núcleos en lugar de una CPU de 8 núcleos con núcleos un 20 % más lentos.

Obtener el mayor rendimiento posible de un solo núcleo requiere grandes cantidades de espacio en la CPU. Se trata de bienes inmuebles que, de otro modo, podrían utilizarse para proporcionar más núcleos. Esta es la razón por la cual las CPU Kaby Lake más nuevas de Intel alcanzan un máximo de 4 núcleos y la gente las compra porque cada núcleo es más rápido que los núcleos de sus predecesores. Para muchos, son una actualización incluso de las CPU con una mayor cantidad de núcleos.

Con el tiempo, espere ver mucho más software de escritorio completamente optimizado para admitir más núcleos. Cuando eso suceda, las compensaciones de ingeniería comenzarán a favorecer más núcleos sobre núcleos más rápidos en las computadoras de escritorio. Si bien es casi seguro que los núcleos seguirán siendo más rápidos, comenzará a ver personas que prefieren una CPU de 8 núcleos a una CPU de 4 núcleos, incluso si cada núcleo es un 20% más lento. Los diseñadores de chips seguirán el mercado.

Es crucial que un teléfono pueda proporcionar potencia computacional en ráfagas cortas (necesitamos que ciertas aplicaciones sean rápidas), pero también evitar el sobrecalentamiento (la disipación de calor es mucho más difícil para los teléfonos que para las computadoras portátiles o PC). Para lograr esto, los arquitectos diseñan teléfonos para usar un solo núcleo cuando la carga de trabajo es ligera y proporcionan núcleos adicionales para aumentar el rendimiento cuando es necesario. Si los teléfonos usaran menos núcleos grandes, el sobrecalentamiento se convertiría en un problema incluso cuando la carga de trabajo sea bastante ligera.

Fuente: un curso de arquitectura informática de nivel de posgrado.

A decir verdad, la capacidad de proporcionar potencia computacional (si eso es lo que quiere decir con energía ) en ráfagas cortas también es crucial para el escritorio. Por eso tienen TurboBoost en los chips Intel.
Sí, el poder computacional es lo que quise decir. Es cierto que todos los dispositivos que pueden esperar tener una gran carga de trabajo en algún momento (incluidos los teléfonos y las computadoras de escritorio) deben poder manejarla. La principal diferencia es la disipación de calor.
Estoy de acuerdo con lo que dijo, solo quería señalar que la carga de trabajo en ráfagas no es específica de los teléfonos.

En primer lugar, la máquina virtual Java históricamente puede beneficiarse de los múltiples núcleos más que el software de escritorio típico. Incluso si escribe una aplicación de subproceso único en Java, se ejecutará más rápido en un multinúcleo porque la mayor parte del código del recolector de basura se ejecutará junto con su aplicación.

En segundo lugar, muchas cosas suceden en segundo plano en su teléfono: actualizaciones automáticas, descargas de anuncios, software antivirus, administración del módulo GSM, etc. En una computadora portátil, todas estas tareas apenas mantendrían ocupado un núcleo, pero los núcleos ARM son mucho menos potente, por lo que es posible que desee tener al menos un par de ellos dedicados a tareas en segundo plano si desea un sistema receptivo.

Por último, está la comercialización. No muchos usuarios son capaces de evaluar si se beneficiarían de 8 núcleos, pero un teléfono inteligente de 8 núcleos ciertamente suena más caro que uno de 2 o 4 núcleos.

Sigo viendo afirmaciones como "los núcleos ARM son mucho menos potentes". ¿Qué significa eso exactamente? ¿Tienen menos velocidad de reloj?
@Abdul menos operaciones por segundo. Los chips x86 pueden ejecutar varias operaciones a la vez, por lo que superan a ARM incluso con la misma velocidad de reloj. Mire esta comparación : el chip ARM superior (GT-I9100) es aproximadamente 10 veces más lento que el chip x86 superior (i7-2920XM).
¿Es "operaciones por segundo" sinónimo de FLOPS?
@Abdul No necesariamente. De hecho, aparte de los juegos y las simulaciones de física, el punto flotante no se usa mucho. Además, muchos chips ARM logran FLOPS decentes al paralizar la precisión, por lo que tampoco es la única medida verdadera.
Las aplicaciones de Android no se ejecutan en la máquina virtual Java. Se ejecutan en Dalvik VM
@LưuVĩnhPhúc Aún así, el código Davlik se genera a partir del código de bytes de Java y, por lo tanto, depende de que el GC esté allí.
En mi humilde opinión, las tareas en segundo plano, como la sincronización, están en su mayoría vinculadas a E/S y pueden tener una prioridad baja. GC podría ser un caso de uso, pero con GC concurrente (es decir, un GC que puede mantener la aplicación en ejecución mientras se recopila), dudo que normalmente vea un beneficio de más de un núcleo adicional a menos que GC se ejecute con mucha frecuencia. Y cuando GC tiene que ejecutarse con mucha frecuencia, probablemente haya algún problema.
@v6ak Cierto, pero ¿no habría un subproceso de GC para cada proceso? Entonces, una vez que hay 2-3 procesos activos ejecutándose en el teléfono, 4-8 núcleos no parecen tan poco razonables.
@DmitryGrigoryev ¿Considera GC pesado en múltiples procesos como un escenario común? De hecho, muchos procesos en segundo plano probablemente funcionarían mejor con GC de parada del mundo que con GC concurrente. El principal inconveniente de detener el mundo GC es el contratiempo repentino, que generalmente no importa en los procesos en segundo plano (con algunas excepciones, como reproducir música, pero de todos modos son manejados principalmente por un código nativo o aceleración HW). El GC simultáneo tiene algunos gastos generales, lo que reduce el rendimiento total, por lo que no es ideal para procesos típicos en segundo plano.
El GC simultáneo tiene una ventaja, usa menos ancho de banda de memoria al usar más memoria en general. El ancho de banda de la memoria es uno de los problemas reales de la tecnología ARM y de los teléfonos inteligentes.

Las respuestas hasta ahora explican algunas facetas del problema que conduce a esta abrumadora cantidad de núcleos de CPU en los teléfonos Android. Lee eso de nuevo; Teléfonos Android. El iPhone ha logrado apegarse a solo un par de núcleos durante mucho tiempo y aún funciona mucho mejor que cualquier buque insignia de Android.

Los diseñadores de Android hicieron una gran apuesta al decidir elegir la programación Java y en consecuencia la JVM como tiempo de ejecución de las aplicaciones. Java, debido a sus principios de diseño, resuelve el problema de la necesidad de compilar y crear código para cada arquitectura de CPU antes de que pueda ejecutarse sacrificando el rendimiento. Java presenta una máquina virtual pesada y voluminosa, generalmente llamada JVM. La JVM en realidad emula una CPU a nivel de software para evitar la necesidad de compilar el código por separado para cada dispositivo. Piense en la JVM como una CPU virtual que tiene las mismas propiedades independientemente del dispositivo que la ejecute, por lo que el código solo debe compilarse una vez para la JVM y luego podría ejecutarse en todos los dispositivos. Esto permite a los fabricantes lanzar cualquier hardware que deseen antes de tener que preocuparse por la compatibilidad de las aplicaciones.

La JVM en sí es simplemente una especificación y las personas son libres de desarrollar su propia JVM siempre que se adhiera a esta especificación. La JVM de Android original se llamaba Dalvik. Hoy en día Google ha reemplazado eso con ART.

Ahora, ¿cuál es el problema con JVM? Es una pieza pesada de software que consume una gran cantidad de recursos informáticos. Agregue a esto algunas otras propiedades del lenguaje Java, como la recolección de basura, y el consumo de recursos de JVM simplemente se vuelve demasiado para un dispositivo con una potencia de hardware modesta. Cada aplicación y servicio del sistema abierto en su dispositivo es en sí mismo una instancia de ART JVM y, a estas alturas, podría concluir que administrarlos todos requiere un hardware realmente capaz. Las cosas empeorarán aún más cuando exista la necesidad de dibujar interfaces de usuario.

Cada aplicación se ejecuta en varios subprocesos. Cada núcleo de CPU puede ejecutar solo un subproceso a la vez. Cada aplicación tiene un hilo principal en el que hace las cosas relacionadas con la interfaz de usuario. Podría haber muchos más subprocesos por aplicación para acceder a archivos, redes, etc. Por lo general, hay más aplicaciones (y servicios del sistema) abiertas que núcleos de CPU y, como resultado, suele haber muchos más subprocesos que núcleos de CPU. Entonces, cada núcleo tiene que alternar entre procesar diferentes subprocesos constantemente, hacer un poco de cada uno y pasar al siguiente. Esta conmutación requiere mucho tiempo para la CPU y en caso de que las aplicaciones sean esencialmente JVM, esta tarea se vuelve aún más exhaustiva.

Según esta explicación, se podría deducir que Android necesita un hardware potente para funcionar sin problemas. Las primeras generaciones de dispositivos Android eran famosas por sus retrasos, fallas y muchas otras cosas desafortunadas. Pero a lo largo de los años, estos problemas se han resuelto en su mayoría al confiar en un hardware potente.

Por otro lado, las aplicaciones de iOS se compilan en un código de máquina nativo y, por lo tanto, no necesitan la virtualización. El idioma utilizado y el sistema operativo también son más eficientes y, por lo tanto, permiten que estos dispositivos se mantengan fluidos sin la necesidad de un conjunto de chips excesivo.

Esta es una buena explicación de por qué los teléfonos móviles son mucho más poderosos que las computadoras de escritorio. ¿O no lo son?
“Esto permite a los fabricantes lanzar cualquier hardware que deseen antes de tener que preocuparse por la compatibilidad de las aplicaciones”. – buen punto, pero no estoy seguro de si esta era la intención de un sistema destinado (originalmente) a las cámaras.
“Podría haber muchos más subprocesos por aplicación para acceder a archivos, redes, etc.”, estos están más bien vinculados a E/S y no consumen mucha CPU. A veces, la E/S es manejada solo por un subproceso, porque la CPU es mucho más rápida que los dispositivos de E/S.
“Las primeras generaciones de dispositivos Android eran famosas por el retraso, los bloqueos y muchas otras cosas desafortunadas”: recuerdo ejecutar Marshmallow en ese teléfono (Xperia Mini Pro), y creo que hay muchas otras razones para ser lento además de la CPU. Se ejecutan con poca RAM, tenían dispositivos flash más lentos como MTD (mucho más lentos que las tarjetas microSD para algunas operaciones), los Android más antiguos tenían una "JVM" menos eficiente (que técnicamente no es una JVM). Claro, una mejor CPU también ayuda, pero estaría lejos de esa conclusión.
Además, el estilo de programación, como realizar E/S (u otras operaciones largas) en el subproceso de la interfaz de usuario, puede hacer que las aplicaciones se retrasen independientemente del rendimiento de la CPU. AFAIK, este estilo es bastante común en las primeras aplicaciones de Android. Estas aplicaciones pueden ser lentas incluso con teléfonos modernos. Probablemente serán menos lentos, pero eso se debe más a las memorias flash más rápidas que a las CPU más rápidas o más núcleos.
@v6ak RAM es sin duda un problema. La JVM es un proceso que consume muchos recursos y tener mucha RAM permite que el sistema operativo mantenga la mayor parte de la aplicación en la memoria principal, lo que reduce el tiempo que lleva cambiar entre ellos, etc. gran cantidad de memoria RAM.
@v6ak Tienes toda la razón. El problema es que en una aplicación de Android, todo (incluidos los servicios y los receptores de transmisión que son las funciones de mensajería del sistema operativo) se ejecuta en el subproceso de la interfaz de usuario de manera predeterminada, lo que puede afectar negativamente el rendimiento. Sin embargo, esto se está convirtiendo en un problema menor, ya que Google ha introducido funciones de creación de subprocesos eficientes y las versiones posteriores de la plataforma prohíben realizar E/S en el subproceso principal en el momento de la compilación.

Resumiendo todo lo anterior, puedo decir que los casos de uso de PC y teléfono son bastante diferentes. La PC se usa la mayoría de las veces en una o varias aplicaciones (por supuesto, el navegador con un montón de pestañas requiere muchos núcleos de CPU, puede retrasarse incluso en la parte superior i-3), los teléfonos se usan para realizar múltiples tareas. Al menos conexión de red, dibujo de interfaz de usuario, activadores del sistema, notificaciones. Si abre el administrador de tareas en la PC, también hay muchos procesos, pero usan menos del % de potencia de la CPU, incluso en el viejo Core 2 duo. 4 núcleos es bastante barato (MTK 65x2 costó 1 $ al inicio para OEM) También es RIESGO vs CISC cuando la última falta de rendimiento por núcleo. ¡Eficiencia energética! = potente, como podemos ver aquí . El multinúcleo es perfecto para dispositivos móviles, porque no tiene una carga pesada de una sola banda de rodadura y una experiencia dirigida a múltiples tareas (pero podemos ver que los iPhones necesitan menos núcleos y RAM debido a un buen softwarecomo en este video u otros )

Mucho de esto también se realiza a menudo en una computadora portátil. Y la multitarea no tiene que ser exigente con la CPU. La diferencia en los costos de fabricación podría causar algunas diferencias y podría ser la razón de que haya menos núcleos para las CPU de gama baja, pero dudo que los costos de fabricación sean la única razón por la que no todos los i7 tienen al menos cuatro núcleos. Creo que los costos de fabricación son solo una pequeña fracción del precio de esas CPU.
@v6ak, el problema es que los núcleos x86 son más grandes y más complicados, las CPU de Intel (o AMD) simplemente no son lo suficientemente buenas como para ser el mejor modelo. De hecho, la mayoría de ellos se bloquean en algunas partes y se convierten en Junior i7 o Pentium. Los núcleos ARM parecen menos complicados, por lo que no llegan tantos modelos cada año. Todavía es cierto que el octa core era Samsung Exynos Octa 7xxx , MTK Helio X10 , Latest (X30) incluso proponen little(4).Middle(4).BIG(2), podemos verla en los anuncios que es un procesador de 10 núcleos, marketing barato hace cosa.

Creo que uno de los principales factores impulsores más allá de un 4 u 8 (para configuraciones grandes: pequeñas) es solo marketing en este momento.

Un gran problema del alto número de núcleos es cuando se considera el tamaño de la memoria. Normalmente, en las aplicaciones de escritorio, cuando desea mejorar la utilización de múltiples núcleos, necesita duplicar estructuras y usar mucha más memoria que en una aplicación de un solo subproceso.

Esto no sucede porque la memoria RAM es muy cara (especialmente en la situación de crisis de RAM de 2017/2018). El departamento de marketing quiere números altos, pero el control quiere reducir los precios de los componentes. Si ve un saldo de menos de 1 Gigabyte de RAM por núcleo, entonces ve un compromiso fallido.