levhieu a écrit :



Question aux INPACTicients en (bon) rapport avec ARM:



Quel est l’intérêt du big.little avec un A12 si il consomme vraiment moins qu’un A15?





Heu… c’est moi ou j’ai l’impression que la réponse est dans la question ? " />

Un big.LITTLE A12/A7 consommera moins qu’un A15/A7, mais sera aussi moins puissant. Question de positionnement de gamme, ni plus ni moins.







levhieu a écrit :



On pourrait pas, en cas d’activitté réduite, se contenter de jouer avec la fréquence (si jamais c’est possible) ou bien de ne garder actif que le ou les cœurs suffisant à la charge et d’arrêter les autres ?







Le changement de fréquence INpacte moins que le changement d’architecture sur le rapport perfs/conso.



Le big.LITTLE permet de basculer sur une archi faite et pensée pour la basse conso en cas de faible charge, et ensuite basculer sur une archi faite et pensée pour les perfs en cas de forte charge.



Hélas, pour l’INstant, une archi orientée perfs aurait un rendement totalement pourri à très faible fréquence (OoO, pipeline long, etc…), donc ce n’est pas INtéressant, en terme de rapport perfs/conso, de faire tourner trop bas en fréquence un A15 par exemple.

levhieu a écrit :



Non, la réponse n’est pas dans la question, mais on peut dire que ma question nétait pas claire. J’essaye d’être plus explicite: On nous annonce un A12 qui consomme beaucoup moins qu’un A15. Je demande donc si la consommation du-dit A12 est tant que ça au dessus de celle de l’A7 ?







Ha d’accord, je comprends mieux la question.

L’A12 étant, pour catégoriser grossièrement, une archi orientée perfs, il aura fatalement une différence significative de consommation, à fréquence égale à un A7.

Ensuite, je suppose que c’est aux constructeurs d’avoir une certaine cohérence dans leur conception, en mettant un A7 faiblement cadencé en tandem avec un A12 dans un SoC ; puis un A7 plus fortement cadencé avec un A15 dans un SoC positionné dans la gamme supérieure.



J’avoue que j’apprécierais moi-même des démonstrations (davantage) chiffrées de ces théories sur les consos, mais ce genre de démonstrations ne court pas le net.







levhieu a écrit :



Merci de cette réponse. C’est clair, net et précis (me coucherai moins bête aujourd’hui).



Toutefois à la relecture je constate que ça ne réponds qu’à une de mes 2 «propositions».

Reste à traiter (des volontaires?) le cas de l’arrêt de cœur(s) en cas de baisse de charge de travail.







Ha, je vois que tu as remarqué mon (pas si) habile bottage en touche sur cette question ? " />

J’avoue manquer d’éléments de réponse sur ces aspects.

A ma modeste connaissance, il est techniquement possible d’activer indépendamment les coeurs d’une architecture big.LITTLE, mais ça engendre des complications/situations délicates à gérer :

Avec un big.LITTLE A7/A15 en 4*4, tels que les derniers Exynos de Samsung, sous Linux, la fréquence de l’A7 est augmentée en fonction de la charge jusqu’au maximum, puis l’A15 prend le relais si la charge augmente, et les fréquences de l’A15 évoluent à leur tour.

Le passage est transparent et rapide pour l’OS.



Si on est dans le cas de figure, à priori pas impossible techniquement, où les deux A7 et A15 sont activés, on est plus dans un SMP (Symetrical Multi Processing) que l’OS sait gérer. En effet, les noyaux actuels (courants, du moins) ont un scheduler qui répartissent les tâches indépendamment de la nature du core qui les exécute.



Je ne sais pas ce qui se fait actuellement en support AMP (Asymetrical Multi Processing), ou si le noyau Linux sait le gérer.



Concernant l’activation ou non indépendante de cores, j’ignore aussi quelles limitations rendent peu courante (impossible ?) la pratique.