[ ARTICULO ] Realidad o ficción. Las aplicaciones de Android sólo usan un núcleo

[skullman]

A continuación os resumo en castellano un artículo que he encontrado sobre cómo funcionan los microprocesadores "multi core" en Android, en concreto la tecnología que muchos fabricantes están usando llamada big.LITTLE y sus supuestas ventajas sobre los micros de un sólo núcleo.

Esto en un principio iba a ser una respuesta de este largo hilo del Xiaomi Redmi Note 3, pero he creído conveniente ponerlo en General, ya que no es exclusivo de este móvil, ni mucho menos de un sólo fabricante.

Esta es mi traducción de andar por casa, muy muy resumida. Espero que pueda servir a alguien, como me ha servido a mi, para entender en qué consiste esto del "multi core" y cerrar así muchas discusiones estúpidas de si este micro tiene más núcleos que el otro o si el Antutu da más puntos a uno o a otro.

El artículo original lo podéis encontrar aquí: http://www.androidauthority.com/fact...u-core-610352

Realidad o ficción. Las aplicaciones de Android sólo usan un núcleo

En artículo empieza destacando las diferencias entre los micros de escritorio y los móviles. Los de escritorio usan los núcleos para obtener rendimiento y en cambio la tecnología que se ha seguido en el diseño de micros para móvil ha sido para obtener rendimiento + consumo. Esa es la mayor diferencia que veremos entre un 8 core de escritorio y un 8 core en móvil.

Los micros en móviles usan por ejemplo dos Cortex-A57/A72 (potentes) y dos A53 (gran eficiencia energética). Este tipo de estructura se conoce como big.LITTLE donde procesadores potentes te mezclan con procesadores PEQUEÑOS (little). Y esto difiere totalmente en los microprocesadores de escritorio, donde no se usa este tipo de estructura.

El artículo continúa explicando la multitarea y que es básicamente el sistema operativo el encargado de repartir las cargas entre los microprocesadores. Aunque hay excepciones en este punto ya que los desarrolladores pueden escribir su código usando hilos (1). Las distintas tareas que reparte el micro son limitadas y traduzco un párrafo completo que ilustra perfectamente el porqué:

Algunas tareas son secuenciales por la naturaleza. Para hacer un pastel necesitamos romper algunos huevos, añadir un poco de harina, hacer la mezcla para pastel, etc, y luego, al final ponerlo en el horno. No se puede poner la lata del pastel en el horno hasta que la mezcla de pastel esté lista. Así que incluso teniendo dos cocineros en una cocina, no vamos a ahorrar tiempo necesariamente en esta tarea. Hay pasos a seguir y no se puede alterar el orden. Pero hay tareas que sí pueden ser simultáneas, de hecho, mientras que un cocinero está haciendo el pastel el otro puede preparar una ensalada, pero las tareas que tienen una secuencia predefinida no puede beneficiarse de los procesadores de doble núcleo o incluso de 12 núcleos.

El artículo continúa explicando como Android internamente gestiona la multi tarea, a pesar de que una aplicación no haga uso de ella en su código, y cómo automáticamente gestiona las tareas en segundo plano, uso de wigets, envío de gráficos a pantalla... Todo ello se gestiona por parte del sistema operativo y si el micro tiene más de un núcleo, Android reparte la carga entre ellos de la forma más eficiente posible.

Pero queda una pregunta importante en el aire. Ya que la mayoría de aplicaciones en Android están escritas para usar sólamente un núcleo, por lo tanto no hay diferencia entre correr estas aplicaciones en un micro con 8 núcleos o correrlas en uno con 1 sólo núcleo. En los micros de escritorio, todos los núcleos son iguales, pero en los procesadores "multi-core" tenemos micros potentes junto a micros "eficientes". Y la idea es que estos eficientes se utilicen sólo en las tareas que no requieran mucha potencia. Aunque también es cierto que todos se pueden usar de forma simultánea, no hay que olvidar que la tecnología big.LITTLE usa 8 núcleos para ahorro enegético, no para potencia.

La siguiente parte del artículo analiza unas gráficas muy interesantes donde se lanzan aplicaciones Android como Google Chrome y se analiza los núcleos que se han usado y el tiempo que se ha usado cada núcleo.

Usando Google Chrome (que está optimizado en móvil y escritorio para hacer uso de todos los núcleos disponibles) se ve que realmente TODOS los cores se utilizan de una forma o de otra, y que la tecnología big.LITTLE realmente está siendo usada, repartiendo la carga de trabajo entre los distintos núcleos.

Se analizan después Youtube, Gmail y un par de juegos y la conclusión es que en ambas aplicaciones de Google no se llegan a usar todos los núcleos, y en los dos juegos analizados a penas se usan 4 núcleos de los ocho disponibles en un caso y UN SÓLO NÚCLEO estaba haciendo todo el trabajo en el otro juego en un micro Qualcomm de ocho núcleos, en un Qualcomm Snapdragon 801 de 4, sólo dos eran utilizados, y en cambio en un Mediatek, los cuatro disponibles eran usados.

Por eso los benchmarks no son fiables, ya que en el uso diario de nuestro teléfono, dependemos de que la aplicación o juego que ejecutemos haga o no uso de los núcleos disponibles.

Las pruebas concluyen que en ningún caso de los probados los ocho núcleos se usaban al 100% y que es exactamente así como este tecnología fue ideada. Recordemos que de lo que la idea detrás de esta tecnología es ahorrar batería, no aumentar la potencia como en los micros de escritorio de Intel o AMD.

Dicho todo eso, claramente las aplicaciones de Android son capaces de usar las ventajas de los procesadores multi core. Y big.LITTLE permite al programador elegir la mejor combinación para la carga de trabajo actual del núcleo. Si la gente sigue diciendo cosas como "los móviles no necesitan 8 núcleos" es que no han entendido que esta tecnología no tiene que ver con rendimiento bruto, si no con eficiencia energética.

1) Para quien quiera profundizar en las distintas opciones que tienen los desarrolladores para usar hilos en Android:
https://developer.android.com/guide/...d-threads.html
https://developer.android.com/traini...ads/index.html
https://developer.qualcomm.com/blog/...ssors-part-1-2

[danko9696]

Buen artículo para desmitificar el número de cores. Claro que es mejor tener pocos cores potentes que tener muchos cores poco potentes, por lo menos de cara al rendimiento. Y es parte del motivo por el que los iphone rinden tan bien. Contando con pocos cores muy potentes, limitan el multitarea para evitar sobrecargarlos, de modo que no haya demasiadas aplicaciones simultaneas relativamente exigentes que puedan sobrecargarlos, pero que las que ejecuten lo hagan a la máxima velocidad.

Algo que creo que falta comentar en el artículo es que la propia gestión de los threads tiene un coste en rendimiento. Si tienes una tarea que llevaría un 40% en un core, por ejemplo, si se pudiese repartir el trabajo fácilmente entre dos cores identicos, estos podrían trabajar a un 25% (por poner algo), por el overhead que supone repartir el trabajo.

Lo ideal creo que sería pocos cores (o un monocore) lo más potentes posible y a la vez con gran flexibilidad en cuanto a frecuencias disponibles / gran velocidad de transición entre estas (un poco más o menos la estrategia del iphone), pero eso es más fácil decirlo que hacerlo. Porque lo mismo en pc, es mucho más fácil escalar potencia (aunque no esté disponible en un solo hilo) aumentando número de cores que aumentando complejidad de cpu y/o MHz. Además de que en PC sí hay aplicaciones capaces de aprovechar de manera muy eficiente cualquier número de cores que les eches a la cara, como servidores de bases de datos, por ej.

[kisler]

 Cita: Originalmente Escrito por danko9696

Buen artículo para desmitificar el número de cores. Claro que es mejor tener pocos cores potentes que tener muchos cores poco potentes, por lo menos de cara al rendimiento. Y es parte del motivo por el que los iphone rinden tan bien. Contando con pocos cores muy potentes, limitan el multitarea para evitar sobrecargarlos, de modo que no haya demasiadas aplicaciones simultaneas relativamente exigentes que puedan sobrecargarlos, pero que las que ejecuten lo hagan a la máxima velocidad.

Algo que creo que falta comentar en el artículo es que la propia gestión de los threads tiene un coste en rendimiento. Si tienes una tarea que llevaría un 40% en un core, por ejemplo, si se pudiese repartir el trabajo fácilmente entre dos cores identicos, estos podrían trabajar a un 25% (por poner algo), por el overhead que supone repartir el trabajo.

Lo ideal creo que sería pocos cores (o un monocore) lo más potentes posible y a la vez con gran flexibilidad en cuanto a frecuencias disponibles / gran velocidad de transición entre estas (un poco más o menos la estrategia del iphone), pero eso es más fácil decirlo que hacerlo. Porque lo mismo en pc, es mucho más fácil escalar potencia (aunque no esté disponible en un solo hilo) aumentando número de cores que aumentando complejidad de cpu y/o MHz. Además de que en PC sí hay aplicaciones capaces de aprovechar de manera muy eficiente cualquier número de cores que les eches a la cara, como servidores de bases de datos, por ej.

No opino para nada igual que tu y te lo voy a explicar copiando lo que ya dije en otro hilo diferente a este.

Primero: Mas núcleos no implica más potencia, ya que esto dependerá en gran parte de la arquitectura usada, frecuencias y otra serie de parámetros. Por ejemplo un i5 de 2 nucleos actual es mucho mas potente que un QuadCore de los de hace años por lo anteriormente descrito.

Segundo: Muchas veces he leido comentarios en distintos foros "Ponerle nosecuantos nucleos es una tonteria". Teniendo en cuenta el punto anterior mi opinion al respecto es que SI importan. En una CPU existe la multiprogramacion, es decir, la capacidad de ella de intercalar procesos para aprovecharla al máximo, pero esto no quiere decir que haga tareas en paralelo ya que para eso requiere el multiprocesamiento que es cuando se pueden lanzar varios procesos de forma simultanea y esto solo es posible con 2 o más nucleos. Teniendo en cuenta esto ultimo un procesador con 2 nucleos como máximo va a poder ejecutar 2 procesos en paralelo, uno con 4 podrá ejecutar 4 y así sucesivamente. "La sensación" de que un procesador con menos núcleos ejecuta más tareas simultaneas que uno con más nucleos no es real y depende en gran medida del planificador (lo tipico que cambiais muchos cuando se cambia el kernel como ondemand, intellidemand....) que es el encargado de decirle al kernel como se deben multiplexar los procesos.

Tercero: Más núcleos no implica más potencia pero si más eficiencia. Os pongo un ejemplo, ¿que es mejor tener 1 CPU funcionando a 4.0 Ghz o 4 nucleos funcionando a 1Ghz? Teniendo en cuenta el punto anterior esta comprobado que es mas eficiente tener 4 núcleos a una frecuencia más baja que 1 núcleo a una más alta por la posibilidad de multiprocesamiento. Además no es igual activar núcleos según se van necesitando que tener 1 sola CPU activa de mayor potencia en lo que respecta al consumo etc.

Por ejemplo yo desarrollo aplicaciones y sin ir mas lejos una que estoy desarrollando actualmente me viene bien para este tema. La aplicacion es una como tantas que podeis ver, twitter, instagram, hoteles etc basicamente se trata de que haces una llamada a un servidor y estas pueden ser consultas a base de datos para obtener información sobre determinadas cosas (perfiles de usuario, información sobre un hotel, ultimos comentarios de twitter...). Pues bien este tipo de llamadas se suele hacer mediante hilos o tareas asincronas las cuales en paralelo estan realizando estas operaciones y una vez finalizados realizan una determinada accion. ¿Por qué se debe hacer esto asi? Porque si no la app se puede bloquear. Por ejemplo una de las cosas que tengo que hacer es descargar un archivo ZIP y realizar una serie de operaciones, este archivo puede tener varios MB y si no lo hiciese a traves de hilos estaría metiendole sobrecarga al proceso principal y si la descompresión tampoco la hiciese mediante hilos y el archivo es grande el proceso principal puede llegar a bloquearse o incluso dar error y salir de la app. Una cosa de la que seguro estais muy habituados a ver es cuando enviais o recibis un archivo por whatsapp, en el que le dais y comienza a subir o descargar y os vais a hablar con otra persona o ha realizar alguna otra actividad, pues bien esto esta hecho tambien por hilos porque sino podria pasar lo anteriormente descrito. Cuando vais a ver una aplicación que visualiza una galeria de fotos es posible que tambien esté hecha por hilos (seria lo ideal) para que las fotos se vayan cargando de esa forma.

1 nucleo = no existe multitarea real pero si multiplexación de procesos.
2 o más nucleos = existe multiprocesamiento real de tantos procesos como nucleos existan.

Un procesador con de un solo nucleo NUNCA puede ejecutar 2 procesos a la vez y tener una CPU de por ejemplo 8Ghz es mucho peor que tener 4 CPUs a 2Ghz u 8 CPUs a 1Ghz. La suma de la potencia final es la misma pero permite multiprocesamiento y además posiblemente mas eficiencia. En 1 solo nucleo el planificador (hay muchisimos tipos) intercambia tan rapido los procesos que realmente crees que se estan ejecutando a la vez pero esto no es asi y esta demostrado que es mucho mejor varios nucleos con menos potencia que su equivalente en un unico nucleo.

Y por ultimo decir sinceramente que hay una sobrecarga de la multitarea cuando hay varios nucleos y por eso es mejor limitar la multitarea... Yo no se que concepto tienes por multitarea pero si has leido lo anterior creo que deja claro que cuantos mas nucleos disponibles mayor POSIBILIDAD de multitarea y por tanto mayor cantidad de procesos simultáneos que se pueden hacer. Y esto es dicho desde el punto de vista de rendimiento, desde el punto de vista energético (a igual arquitectura) es muy posible que sea mejor mas nucleos a menos frecuencia que lo contrario.

Por cierto cuando dices...

 Cita: Originalmente Escrito por danko9696

Algo que creo que falta comentar en el artículo es que la propia gestión de los threads tiene un coste en rendimiento. Si tienes una tarea que llevaría un 40% en un core, por ejemplo, si se pudiese repartir el trabajo fácilmente entre dos cores identicos, estos podrían trabajar a un 25% (por poner algo), por el overhead que supone repartir el trabajo.

Por qué asumes que el proceso se debe dividir si o si y eso produce overhead? No puede ser que ese nucleo se encargue de esa tarea y el resto de nucleos esten haciendo tareas del sistema operativo o de otras apps? Por que asumes que se tiene que dividir?
Como ha comentado el compañero comparando diversos procesadores con varias apps la misma app dependiendo del procesador usaba un numero de nucleos u otro, eso como es? pues porque los planificadores son los encargados de realizar estas acciones y si el planificador de la CPU fulanita esta enfocado a que un proceso con unas caracteristicas X lo reparta en 2 nucleos y la CPU benganita tiene un planificador que reparte los procesos de otra forma... No ves que eso no va en los nucleos sino en los planificadores? los nucleos son simples CPUS esperando a que alguien le diga QUE HACER y esto lo hace el planificador que redistribuye el trabajo entre ellos, si un tipo de planificador es mas o menos efectivo eso es otra cosa... Y no hay mejor ejemplo que lo que el propio compañero extrae del analisis y que cito:

 Cita: Originalmente Escrito por skullman

Se analizan después Youtube, Gmail y un par de juegos y la conclusión es que en ambas aplicaciones de Google no se llegan a usar todos los núcleos, y en los dos juegos analizados a penas se usan 4 núcleos de los ocho disponibles en un caso y UN SÓLO NÚCLEO estaba haciendo todo el trabajo en el otro juego en un micro Qualcomm de ocho núcleos, en un Qualcomm Snapdragon 801 de 4, sólo dos eran utilizados, y en cambio en un Mediatek, los cuatro disponibles eran usados.

En resumen: Tener el sistema dividido en núcleos (aunque sean muchos) en mi opinión es mejor por lo expuesto anteriormente y no por ello implica que consuma más que la mitad de ellos con el doble de velocidad de reloj. Los planificadores son los encargados de elegir qué núcleos usar y cual es su propósito por lo que ni va a consumir más batería ni otro tipo de cosas que se leen a veces.

No se si tu comentario esta realizado desde el punto de vista de aficionado a la tecnología o desde un punto de vista mas técnico, pero en caso de ser el segundo discrepo claramente con lo que opinas.

Un saludo.

[danko9696]

 Cita: Originalmente Escrito por kisler

No opino para nada igual que tu y te lo voy a explicar copiando lo que ya dije en otro hilo diferente a este.

Primero: Mas núcleos no implica más potencia, ya que esto dependerá en gran parte de la arquitectura usada, frecuencias y otra serie de parámetros. Por ejemplo un i5 de 2 nucleos actual es mucho mas potente que un QuadCore de los de hace años por lo anteriormente descrito.

Segundo: Muchas veces he leido comentarios en distintos foros "Ponerle nosecuantos nucleos es una tonteria". Teniendo en cuenta el punto anterior mi opinion al respecto es que SI importan. En una CPU existe la multiprogramacion, es decir, la capacidad de ella de intercalar procesos para aprovecharla al máximo, pero esto no quiere decir que haga tareas en paralelo ya que para eso requiere el multiprocesamiento que es cuando se pueden lanzar varios procesos de forma simultanea y esto solo es posible con 2 o más nucleos. Teniendo en cuenta esto ultimo un procesador con 2 nucleos como máximo va a poder ejecutar 2 procesos en paralelo, uno con 4 podrá ejecutar 4 y así sucesivamente. "La sensación" de que un procesador con menos núcleos ejecuta más tareas simultaneas que uno con más nucleos no es real y depende en gran medida del planificador (lo tipico que cambiais muchos cuando se cambia el kernel como ondemand, intellidemand....) que es el encargado de decirle al kernel como se deben multiplexar los procesos.

Tercero: Más núcleos no implica más potencia pero si más eficiencia. Os pongo un ejemplo, ¿que es mejor tener 1 CPU funcionando a 4.0 Ghz o 4 nucleos funcionando a 1Ghz? Teniendo en cuenta el punto anterior esta comprobado que es mas eficiente tener 4 núcleos a una frecuencia más baja que 1 núcleo a una más alta por la posibilidad de multiprocesamiento. Además no es igual activar núcleos según se van necesitando que tener 1 sola CPU activa de mayor potencia en lo que respecta al consumo etc.

Por ejemplo yo desarrollo aplicaciones y sin ir mas lejos una que estoy desarrollando actualmente me viene bien para este tema. La aplicacion es una como tantas que podeis ver, twitter, instagram, hoteles etc basicamente se trata de que haces una llamada a un servidor y estas pueden ser consultas a base de datos para obtener información sobre determinadas cosas (perfiles de usuario, información sobre un hotel, ultimos comentarios de twitter...). Pues bien este tipo de llamadas se suele hacer mediante hilos o tareas asincronas las cuales en paralelo estan realizando estas operaciones y una vez finalizados realizan una determinada accion. ¿Por qué se debe hacer esto asi? Porque si no la app se puede bloquear. Por ejemplo una de las cosas que tengo que hacer es descargar un archivo ZIP y realizar una serie de operaciones, este archivo puede tener varios MB y si no lo hiciese a traves de hilos estaría metiendole sobrecarga al proceso principal y si la descompresión tampoco la hiciese mediante hilos y el archivo es grande el proceso principal puede llegar a bloquearse o incluso dar error y salir de la app. Una cosa de la que seguro estais muy habituados a ver es cuando enviais o recibis un archivo por whatsapp, en el que le dais y comienza a subir o descargar y os vais a hablar con otra persona o ha realizar alguna otra actividad, pues bien esto esta hecho tambien por hilos porque sino podria pasar lo anteriormente descrito. Cuando vais a ver una aplicación que visualiza una galeria de fotos es posible que tambien esté hecha por hilos (seria lo ideal) para que las fotos se vayan cargando de esa forma.

1 nucleo = no existe multitarea real pero si multiplexación de procesos.
2 o más nucleos = existe multiprocesamiento real de tantos procesos como nucleos existan.

Un procesador con de un solo nucleo NUNCA puede ejecutar 2 procesos a la vez y tener una CPU de por ejemplo 8Ghz es mucho peor que tener 4 CPUs a 2Ghz u 8 CPUs a 1Ghz. La suma de la potencia final es la misma pero permite multiprocesamiento y además posiblemente mas eficiencia. En 1 solo nucleo el planificador (hay muchisimos tipos) intercambia tan rapido los procesos que realmente crees que se estan ejecutando a la vez pero esto no es asi y esta demostrado que es mucho mejor varios nucleos con menos potencia que su equivalente en un unico nucleo.

Y por ultimo decir sinceramente que hay una sobrecarga de la multitarea cuando hay varios nucleos y por eso es mejor limitar la multitarea... Yo no se que concepto tienes por multitarea pero si has leido lo anterior creo que deja claro que cuantos mas nucleos disponibles mayor POSIBILIDAD de multitarea y por tanto mayor cantidad de procesos simultáneos que se pueden hacer. Y esto es dicho desde el punto de vista de rendimiento, desde el punto de vista energético (a igual arquitectura) es muy posible que sea mejor mas nucleos a menos frecuencia que lo contrario.

- Primero: de acuerdo.
- Segundo: yo no he dicho que sea una tontería. Yo lo que he dicho es que en un mundo ideal sería mejor menos nucleos más potentes que muchos nucleos poco potentes.
- Tercero: también estoy de acuerdo que más nucleos implica más eficiencia en la práctica. Pero ¿que pasaría si pudieses escalar hacia abajo esos 4GHz sin latencia ni otros problemas acuerdo a la demanda, que de repente pudieses bajar de 4GHz a 50MHz si se diese el caso?. ¿Que diferencia teórica habría entre un procesador de 4GHz que ha bajado a 1.5GHz y otro procesador de 4 nucleos a 1GHz con uno al máximo, dos desactivados y otro a la mitad?. Entiendo que depende de lo que esté ejecutando, pero a primera vista no veo mucha.

Y dandole la vuelta a la tortilla ¿que pasa si usas una aplicación muy exigente (como un juego) con un thread principal muy hambriento y el resto para llevar cosas secundarias?. Si el thread principal, el que va a limitar en la práctica el rendimiento del juego corre a 1GHz, irá peor que si corre a 4GHz, donde sí va a serle más fácil aprovechar el potencial de la cpu. Naturalmente ahí influye mucho el tipo de tarea, según sea más fácil o más difícil de dividir en subtareas (por eso yo mismo he puesto antes un ejemplo de tarea que puede aprovechar al máximo cualquier cantidad de cores).

Mi razonamiento es que el de 4GHz es mejor en principio pero que por motivos de ingeniería es más sencillo (o no sencillo sino barato, con componentes de mayor calidad) integrar más nucleos para aumentar potencia que aumentar las frecuencias indefinidamente, y entiendo que el problema reside más bien en problemas de ingeniería y costes que hacen mucho más viable integrar múltiples cores antes que tener cpus de 8+ GHz en un móvil, 8GHz que además no escalarían tan bien hacia abajo bajando frecuencias como múltiples cores donde puedes jugar tanto con la activación/desactivación de estos para mejorar la eficiencia energética, un poco como las marchas de una bici.

Y en la práctica, aunque más cores tengan ventajas tambienen desventajas. Vuelvo a repetir el ejemplo del iphone. Limita el multitarea y sé que no es una comparación muy justa, pero es una muestra de que montones de cores no son imprescindibles.

 Cita: Originalmente Escrito por kisler

Por qué asumes que el proceso se debe dividir si o si y eso produce overhead? No puede ser que ese nucleo se encargue de esa tarea y el resto de nucleos esten haciendo tareas del sistema operativo o de otras apps? Por que asumes que se tiene que dividir?
Como ha comentado el compañero comparando diversos procesadores con varias apps la misma app dependiendo del procesador usaba un numero de nucleos u otro, eso como es? pues porque los planificadores son los encargados de realizar estas acciones y si el planificador de la CPU fulanita esta enfocado a que un proceso con unas caracteristicas X lo reparta en 2 nucleos y la CPU benganita tiene un planificador que reparte los procesos de otra forma... No ves que eso no va en los nucleos sino en los planificadores? los nucleos son simples CPUS esperando a que alguien le diga QUE HACER y esto lo hace el planificador que redistribuye el trabajo entre ellos, si un tipo de planificador es mas o menos efectivo eso es otra cosa... Y no hay mejor ejemplo que lo que el propio compañero extrae del analisis y que cito:

Creo que me expresé de forma imprecisa, debería haber usado la palabra aplicación, y me refiero al overhead de sincronizar y pasar información entre distintos threads.

 Cita: Originalmente Escrito por kisler

En resumen: Tener el sistema dividido en núcleos (aunque sean muchos) en mi opinión es mejor por lo expuesto anteriormente y no por ello implica que consuma más que la mitad de ellos con el doble de velocidad de reloj. Los planificadores son los encargados de elegir qué núcleos usar y cual es su propósito por lo que ni va a consumir más batería ni otro tipo de cosas que se leen a veces.

¿Entonces toda esa gestión del planificador y de la propia aplicación para mantener la consistencia entre distintos threads, sobre todo cuando no son fácilmente paralelizables (como un juego), no tiene coste?, porque es no es lo que tenía entendido. Ah, y no digo que no se pueda hacer en juegos, solo que no es fácil y por eso ha tardado mucho en ser frecuente (pensando en juegos de PC).


Y bueno, lógicamente todo esto es a nivel aficionado. Si fuese un experto o un profesional lo diría.

[Soytudios]

 Cita: Originalmente Escrito por danko9696

- Primero: de acuerdo.
- Segundo: yo no he dicho que sea una tontería. Yo lo que he dicho es que en un mundo ideal sería mejor menos nucleos más potentes que muchos nucleos poco potentes.
- Tercero: también estoy de acuerdo que más nucleos implica más eficiencia en la práctica. Pero ¿que pasaría si pudieses escalar hacia abajo esos 4GHz sin latencia ni otros problemas acuerdo a la demanda, que de repente pudieses bajar de 4GHz a 50MHz si se diese el caso?. ¿Que diferencia teórica habría entre un procesador de 4GHz que ha bajado a 1.5GHz y otro procesador de 4 nucleos a 1GHz con uno al máximo, dos desactivados y otro a la mitad?. Entiendo que depende de lo que esté ejecutando, pero a primera vista no veo mucha.

Y dandole la vuelta a la tortilla ¿que pasa si usas una aplicación muy exigente (como un juego) con un thread principal muy hambriento y el resto para llevar cosas secundarias?. Si el thread principal, el que va a limitar en la práctica el rendimiento del juego corre a 1GHz, irá peor que si corre a 4GHz, donde sí va a serle más fácil aprovechar el potencial de la cpu. Naturalmente ahí influye mucho el tipo de tarea, según sea más fácil o más difícil de dividir en subtareas (por eso yo mismo he puesto antes un ejemplo de tarea que puede aprovechar al máximo cualquier cantidad de cores).

Mi razonamiento es que el de 4GHz es mejor en principio pero que por motivos de ingeniería es más sencillo (o no sencillo sino barato, con componentes de mayor calidad) integrar más nucleos para aumentar potencia que aumentar las frecuencias indefinidamente, y entiendo que el problema reside más bien en problemas de ingeniería y costes que hacen mucho más viable integrar múltiples cores antes que tener cpus de 8+ GHz en un móvil, 8GHz que además no escalarían tan bien hacia abajo bajando frecuencias como múltiples cores donde puedes jugar tanto con la activación/desactivación de estos para mejorar la eficiencia energética, un poco como las marchas de una bici.

Y en la práctica, aunque más cores tengan ventajas tambienen desventajas. Vuelvo a repetir el ejemplo del iphone. Limita el multitarea y sé que no es una comparación muy justa, pero es una muestra de que montones de cores no son imprescindibles.

Compañero, creo que te estás liando. Estás comparando los núcleos en potencia simplemente en GHz, y ese es tu principal fallo. Me explico:

Un núcleo puede tener 1GHz por ejemplo velocidad máxima de procesamiento, pero aquí lo que cuenta es la energía. Si como bien dices tienes un procesador de un núcleo a 4GHz y otro de 4 núcleos a 1GHz, en total parece que tienes la misma velocidad (aunque por la paralelización, el de más núcleos tendrá mejor rendimiento y luego te explicaré porqué), pero lo que cuenta es que en el caso del núcleo de 4GHz, necesita para estar trabajando a esa velocidad un determinado voltaje, mientras que los núcleos de 1GHz necesitan bastante menos voltaje aunque estén trabajando al 100% de capacidad también.

Ese es el primer punto de las ventajas de los multinúcleo, el ahorro energético que suponen frente al los mononúcleo. Ahora, como puse antes, te voy a explicar porqué un procesador con varios núcleos puede trabajar mejor que uno de un sólo núcleo aunque tengan la misma potencia en conjunto.

Como imagino que sabrás por lo que has comentado antes, existe un planificador que se encarga de asignar un determinado proceso a un núcleo y que éste se ejecute. Las tareas de planificación son muy importantes en el trabajo de una CPU, pudiendo llegar a tener un gran impacto en el rendimiento del mismo. Con un procesador de un sólo núcleo, se dispone de un planificador con una sola cola de ejecución (por simplificarlo un poco, porque en realidad hay varias colas para varios estados de los procesos). Eso quiere decir que el planificador va cogiendo procesos que necesitan uso de CPU y los va añadiendo a la cola para ser ejecutados y la CPU se encarga de ir cogiendo un proceso en la cola, ejecutarlo, coger el siguiente, ejecutarlo, etc...

Bien, aquí es donde viene la clave. En un procesador multinúcleo cada núcleo dispone de su propia cola (colas en realidad), y el planificador es más complejo, pero digamos que su trabajo es el mismo, se encarga de poner un proceso que necesita CPU en una cola de ejecución. Al haber varios núcleos y varias colas, el planificador decide a qué cola puede añadir el proceso. Por ejemplo, puede añadir el proceso a la cola que esté menos llena, y así el proceso se podrá ejecutar antes que si lo añade a una cola que ya tiene bastantes más procesos. Eso es sólo un ejemplo, porque el planificador multinúcleo es muy complejo y tiene muchos parámetros en cuenta, como por ejemplo la energía, de manera que puede poner un proceso en un núcleo con varios procesos ya en cola antes que despertar un núcleo que está dormido y podría ejecutarlo al instante dado que eso supondría menor coste energético.

Sobre lo que apuntas de un juego que tenga mucha carga en un thread, vuelves a estar equivocado al pensar que eso hará que un núcleo esté trabajando a tope, uno a medias y otro dormido, la cosa no va así. Un thread, por mucho procesamiento que requiera por parte de la CPU, al fin y al cabo se divide en operaciones de ensamblador digamos (mejor no entrar a hablar del código máquina) por lo que por mucha carga que implique lo que está haciendo, cada una de esas operaciones se puede estar ejecutando en un núcleo distinto si se diera el caso de todas son paralelizables, las que no lo son, aún así, pueden ejecutarse en un núcleo distinto al que se ejecutó la operación inmediatamente anterior. Cuando un proceso ejecuta en CPU, no es que se le asigne para siempre esa CPU.

Un proceso digamos que tiene que ejecutar una operación que dura 100 ciclos de reloj, y el procesador digamos que tiene un quanto de 50 ciclos. Eso quiere decir que cuando el proceso se esté ejecutando, cuando lleve 50 unidades de tiempo, aunque le queden otros 50 por ejecutar, el procesador lo expropiará, lo pondrá a disposición del planificador (que se encargará de pasarlo a la cola de ejecución) y pasará a ejecutar otro proceso de la cola. Cuando le vuelva a tocar al proceso de antes, empezará por donde lo dejó dado que cuando lo expropió guardó todo su espacio de trabajo en ese momento.

Espero que con todo ese tocho te haya quedado claro como funciona el multiprocesamiento y la multiplexación de procesos y haya resuelto tu duda de los juegos que requieren mucha CPU.

[danko9696]

 Cita: Originalmente Escrito por Soytudios

Compañero, creo que te estás liando. Estás comparando los núcleos en potencia simplemente en GHz, y ese es tu principal fallo. Me explico:

Si he usado solo GHz era a efectos teóricos para dejar todo lo demás igual.

 Cita: Originalmente Escrito por Soytudios

Un núcleo puede tener 1GHz por ejemplo velocidad máxima de procesamiento, pero aquí lo que cuenta es la energía. Si como bien dices tienes un procesador de un núcleo a 4GHz y otro de 4 núcleos a 1GHz, en total parece que tienes la misma velocidad (aunque por la paralelización, el de más núcleos tendrá mejor rendimiento y luego te explicaré porqué), pero lo que cuenta es que en el caso del núcleo de 4GHz, necesita para estar trabajando a esa velocidad un determinado voltaje, mientras que los núcleos de 1GHz necesitan bastante menos voltaje aunque estén trabajando al 100% de capacidad también.

Ese es el primer punto de las ventajas de los multinúcleo, el ahorro energético que suponen frente al los mononúcleo. Ahora, como puse antes, te voy a explicar porqué un procesador con varios núcleos puede trabajar mejor que uno de un sólo núcleo aunque tengan la misma potencia en conjunto.

Esto no creo que disienta con lo que puse antes. En este aspecto el problema es de ingeniería, de limitaciones tecnológicas (y físicas) prácticas. Si pudieses tener esos 4GHz con el mismo consumo que cuatro nucleos a 1GHz la cosa cambiaría, ¿no?

 Cita: Originalmente Escrito por Soytudios

Bien, aquí es donde viene la clave. En un procesador multinúcleo cada núcleo dispone de su propia cola (colas en realidad), y el planificador es más complejo, pero digamos que su trabajo es el mismo, se encarga de poner un proceso que necesita CPU en una cola de ejecución. Al haber varios núcleos y varias colas, el planificador decide a qué cola puede añadir el proceso. Por ejemplo, puede añadir el proceso a la cola que esté menos llena, y así el proceso se podrá ejecutar antes que si lo añade a una cola que ya tiene bastantes más procesos. Eso es sólo un ejemplo, porque el planificador multinúcleo es muy complejo y tiene muchos parámetros en cuenta, como por ejemplo la energía, de manera que puede poner un proceso en un núcleo con varios procesos ya en cola antes que despertar un núcleo que está dormido y podría ejecutarlo al instante dado que eso supondría menor coste energético.

Sobre lo que apuntas de un juego que tenga mucha carga en un thread, vuelves a estar equivocado al pensar que eso hará que un núcleo esté trabajando a tope, uno a medias y otro dormido, la cosa no va así. Un thread, por mucho procesamiento que requiera por parte de la CPU, al fin y al cabo se divide en operaciones de ensamblador digamos (mejor no entrar a hablar del código máquina) por lo que por mucha carga que implique lo que está haciendo, cada una de esas operaciones se puede estar ejecutando en un núcleo distinto si se diera el caso de todas son paralelizables, las que no lo son, aún así, pueden ejecutarse en un núcleo distinto al que se ejecutó la operación inmediatamente anterior. Cuando un proceso ejecuta en CPU, no es que se le asigne para siempre esa CPU.

Si que sabía que pueden pasar los procesos de una cpu a otra, cuento con ello y puede que mi ejemplo no fuese muy bueno. Mi punto es que si tienes una app con un proceso no paralelizable que necesita el solito el 100% (o un 80%, por poner algo), aunque lo pases a otro core sigue usando el 100%. Pero creo que veo lo que quieres decir. Suponiendo que el planificador haga bien su trabajo puedes reducir latencias situando una tarea que corre prisa, sea o no exigente en un core relativamente desocupado.

Puede que simplemente el sistema de gestión interno de android sea muy distinto al de windows, donde al menos hasta hasta poco, por lo menos en juegos, era mejor nucleos muy potentes para ejecutar el thread principal, sobre todo en los casos donde la cpu fuese el cuello de botella.

Porque sigo sin ver como se produce la sincronización entre threads de una misma app y la dificultad de subdividir tareas exigentes tipicamente de un solo hilo (o con varios pero con uno que supone la mayoría de la carga) en otras más pequeñas, ya que según entiendo esta ha sido una de las mayores dificultades en la programación multihilo en PC y uno de los motivos por el que tardaron bastantes años en pc juegos multithread que derivasen a otros cores algo más que el sonido, carga de datos en segundo plano y cosas así.

[Soytudios]

 Cita: Originalmente Escrito por danko9696

Esto no creo que disienta con lo que puse antes. En este aspecto el problema es de ingeniería, de limitaciones tecnológicas (y físicas) prácticas. Si pudieses tener esos 4GHz con el mismo consumo que cuatro nucleos a 1GHz la cosa cambiaría, ¿no?

Bueno, aún con el mismo consumo, seguiría habiendo algunas ventajas en el procesador multinúcleo por el tema que comenté antes de la gestión de varias colas, así que al menos yo seguiría prefiriendo el multinúcleo aunque no suponga mejora en consumo.

 Cita: Originalmente Escrito por danko9696

Puede que simplemente el sistema de gestión interno de android sea muy distinto al de windows, donde al menos hasta hasta poco, por lo menos en juegos, era mejor nucleos muy potentes para ejecutar el thread principal, sobre todo en los casos donde la cpu fuese el cuello de botella.

El sistema de gestión de procesos en Android es el de UNIX, lo mismo que los sistemas operativos Linux, y no tiene nada que ver con los de sistemas NT (Windows), aunque a grandes rasgos tienen las mismas funciones, el funcionamiento interno y de la gestión de procesos es muy distinta. No es que haya uno mejor o uno peor, simplemente son distintos y algunos gestionarán mejor cierto tipo de programación y otros otra, simplemente eso.

Sobre lo que comentas de la sincronización de threads, actualmente la programación permite una abstracción bastante buena frente a ese tipo de problemas, y se pueden tener hilos con memoria compartida o paso de mensajes entre hilos de manera relativamente sencilla de programar a alto nivel, ya que los compiladores y ensambladores de hoy día son muy complejos y completos y se encargan de hacer el "trabajo pesado" por así decirlo. Yo, como programador, no me tengo que preocupar de la paralelización de procesos en mi programa o de la sincronización de hilos en el mismo a no ser que yo lo requiera explicitamente o que, y esto si es necesario, tenga que controlar que no haya inanición o provoque un mal funcionamiento.

[kisler]

Un resumen rápido, más cores a igual arquitectura es mejor.