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

@iBug Esta respuesta se aplica a la pregunta del PO mejor que la respuesta aceptada. La respuesta aceptada es la que no está respondiendo a la pregunta correcta.

"inflar artificialmente los precios de las CPUs" -> Si Intel estaba inflando artificialmente los precios, por qué su competencia utiliza hardware de precio similar y por qué ordenadores con tecnología ARM chupar tan fuerte en comparación con el hardware de Intel? Este odio a Intel es ridículo. Hacer CPU's es duro . Lo que hizo a ARM 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 que comenzó con lo de los núcleos múltiples a precios económicos, con el Celeron D línea. Su 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 se encontraban con algunas limitaciones físicas fundamentales. Más núcleos era un problema mucho más difícil de resolver, así que lo pospusieron hasta que fuera la forma más rentable de seguir aumentando el rendimiento.

Esta respuesta se refiere definitivamente a 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 los PC. No por qué los teléfonos tienen más núcleos que los PC de Intel. Esta respuesta asume que Intel = PC, lo cual no es el caso.

Esto es más bien una bronca a la malvada corporación Intel, que en mi opinión no es merecida ya que ARM jode a los fabricantes de chips independientes con las licencias igual de bien.

No entiendo por qué esto está recibiendo tantas respuestas negativas hablando de golpear a Intel. Soy un gran fan de Intel, y son todo lo que compro, pero claramente han estado frenando el progreso (EN ESTE FRENTE) mientras han dominado el mercado sobre AMD durante los últimos años. Con el lanzamiento de las CPUs Ryzen, que son realmente competitivas, sorpresa, sorpresa, se filtra que Intel de repente está haciendo un procesador Xeon de 32 núcleos (64 hilos), junto con los rumores de cpus de 10 núcleos para entusiastas. Pero no olvidemos que han progresado con la reducción de las matrices en los últimos años.

Intel ha hecho tratos turbios que salieron a la luz hace 20 años; en ese momento tenían a AMD y Cyrix y a sus competidores y estaban tratando de tener un cuasi monopolio. Tienen algunas de las fábricas más avanzadas que puedas encontrar y las series x86 han sido cpu's RISC internamente durante mucho tiempo con un decodificador delante para las instrucciones CISC. Estás dando una opinión totalmente inculta y desinformada

No entiendo por qué esto está recibiendo tantos positivo respuestas; esto no responde a la pregunta original y está lleno de tonterías. Siempre se ha perseguido el aumento del rendimiento de un solo hilo porque acelera fácilmente todo. Todos los programas antiguos de un solo hilo tendrán el almuerzo gratis, y los de varios hilos también se beneficiarán. Dejamos de aumentar la frecuencia debido a los límites físicos - y aún así, hay que ser muy iluso si se piensa que la única diferencia entre un 486 y un Pentium 4 es el reloj de instrucciones - los procesadores x86 superescalares son extremadamente ...

... bestias complejas que consiguen ejecutar una IA heredada aplicando todo tipo de optimizaciones automágicas (ejecución fuera de orden/paralelismo a nivel de instrucción, renombramiento de registros, predicción de bifurcaciones, todo tipo de cachés, explosión/fusión de µops) de forma casi completamente transparente. No se puede alcanzar este nivel de rendimiento simplemente fabricando un 486 de mayor velocidad. 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...

... retos a los que nos enfrentamos, y en muchos casos (normalmente, cuando se necesitan datos de la etapa anterior del algoritmo para alimentar la siguiente) simplemente no se puede hacer, a menos que se tenga un flujo interminable de datos para elaborar, por lo que se puede canalizar. Además, eficiente y correcto La programación paralela cuando se tienen recursos compartidos para hacer malabares entre múltiples hilos de ejecución es un reto extremadamente difícil por sí mismo. Incluso Linus Torvalds advirtió del peligro de pasarse de listo a la hora de inventar primitivas de sincronización, dado que normalmente casi nadie lo hace bien.

@Abdul No necesariamente. De hecho, aparte de los juegos y las simulaciones de física, el punto flotante no se utiliza tanto. Además, muchos chips ARM consiguen unos FLOPS decentes reduciendo la precisión, así que tampoco es la única medida verdadera.

Las aplicaciones de Android no se ejecutan en la máquina virtual de Java. Se ejecutan en la VM Dalvik

@LuuVinhPhúc Aun así, el código de Davlik se genera a partir del bytecode de Java y, por tanto, depende de que la GC esté ahí.

Las tareas en segundo plano, como la sincronización, son, en mi opinión, principalmente de E/S y pueden tener una prioridad baja. La GC puede ser un caso de uso, pero con una GC concurrente (es decir, una GC que puede mantener la aplicación en funcionamiento cuando se está recolectando), dudo que se vea un beneficio de más de un núcleo extra a menos que la GC tenga que ejecutarse muy a menudo. Y cuando la GC tiene que ejecutarse muy a menudo, probablemente hay algo que no funciona.

@v6ak Cierto, pero ¿no habría un hilo de GC para cada proceso? Así que una vez que hay 2-3 procesos activos corriendo en el teléfono, 4-8 núcleos no parecen tan descabellados.

@DmitryGrigoryev ¿Consideras la GC pesada en múltiples procesos como un escenario común? De hecho, muchos procesos en segundo plano probablemente funcionarían mejor con la GC de parada del mundo que con la GC concurrente. El principal inconveniente de la GC de parada del mundo es el hipo repentino, que normalmente no importa en los procesos en segundo plano (con algunas excepciones como la reproducción de música, pero en su mayoría son manejados por un código nativo o la aceleración HW de todos modos). La GC concurrente tiene cierta sobrecarga, reduciendo el rendimiento total, por lo que no es ideal para los típicos procesos de fondo.

La GC concurrente tiene una ventaja, utiliza menos ancho de banda de memoria al usar en general más memoria. El ancho de banda de la memoria es uno de los verdaderos problemas de la tecnología ARM y de los smartphones.