Reprise du message précédent :
Ah mon avis ça ne sera pas parfait au début car en plus du hardware il faut que le software gère correctement la passage d'un type de core à l'autre et ça doit être assez compliquer pour le système de bien estimer tout ça. Mais bon c'est du software donc ça pourra être mis à jour et même modifié par les rom custom.

En gros, tu insinue que les ingé Samsung vont se trouer sur la gestion du BigLittle mais que des petits malins vont faire mieux après coup ? Hum...

grosso modo il vont implémenter une solution qui sera le meilleur compromis pour tout le monde entre vitesse/conso,
Mais c'est pas forcement ce que tout le monde veux. C'est pour ça qu'en général il y a des applis perso qui sortent pour changer les paramètres de gestion d'énergie, on pourrait imaginer l’extrême par exemple: désactiver les coeurs A15, et ça ne sera pas forcement disponible sur la ROM de base.

Y'a déjà des governors qui savent gérer le nombre de cores actifs et leur fréquence. Sur GS3, sans partir dans les tunings de malade, il me semble que le governor de Samsung (pegasusq) est un des plus efficaces.
 
Je fais en général extrêmement confiance à la communauté pour pousser un tél à son maximum. Mais là, on touche à quelque chose qui est très proche du hardware. J'aurais tendance à faire confiance à Samsung pour pondre un governor qui fait le boulot correctement.

merci pour ces infos

Tu penses que le switch sera software ? Le système n'est pas piloté d'un point de vue hardware/firmware ?

ou qu'ils sortiront un firmware/software donné, qu'ils amélioreront avec le temps...
 
Comme le GS2 qui était plus fluide 1 an après sa sortie    
 

Sur PC tu avais Notebook Hardware Control qui permettait de se définir des profils de changement de fréquence, et pour le coup ça permettait de bien optimiser le fonctionnement de la machine, avec à la clé une baisse de conso/chauffe par rapport aux réglages prédéfinis par Intel
(qui sont pourtant loin d'être des boulets).

J'ai pas dit le contraire.

 
J'avais lu justement à ce propos (je ne sais plus où, quelqu'un disait "mais en fait c'est rien de nouveau, Nvidia fait déjà ça avec le Tegra 3" ) que la différence entre la solution Tegra 3 avec le 5ème "coeur compagnon" et l'architecture BIG.little c'est que pour le Tegra 3 c'est software (d'où pas mal de petites merdes à régler) alors que pour BIG.little le switch est hardware.

Ca m'étonnerait que la gestion des cores soit faite de maniére software (surtout au niveau de l'os), ça sera plutot directement intégré dans la puce. Ce qui n'empéchera pas par la suite des bidoulleurs de bloquer/forcer l'usage de certains cores de maniére logicielle.

ca peut être fait d'un point de vue soft à bas niveau via un kernel personnalisé qui supporte les instructions spécifiques pour le switch.
Mais je partage ton avis : une solution "propre" devrait être transparente pour l'OS....

 
En fait le gros du travail de migration est fait en hardware via l'interconnect: le transfert du contexte, des caches et des instructions ainsi que leur cohérence. Le soft n'aura pas à se taper des memcopy à tout bout de champ.
Par contre tu as vu juste, les instructions bas niveau de contrôle restent software dans le kernel, mais comme le gros du boulot est fait en hard, très peu d'instructions sont nécessaires pour lancer une migration. On aura donc toujours des governor à tuner en fonctions des points de fonctionnement du DVFS (dynamic voltage and frequency scaling). Et ça promet d'ailleurs moult réglages, puisqu'il existe pas mal de modes de fonctionnement de big.LITTLE.    
Par exemple on s'imagine souvent la migration totale des A7 vers les A15 (et l'inverse), c'est d'ailleurs le mode originel: la migration de cluster. Mais ils ont rajouté un mode plus intéressant: la migration de CPU. C'est à dire que chaque A7 est pairé avec un A15. Ainsi le DVFS donne la charge pour chaque CPU, et si on a un A7 qui est chargé à fond, on va migrer vers son copain A15, tout en laissant les autres A7 tourner. On peut alors avoir les tâches peu gourmandes qui vont tourner sur les A7 et un jeu qui va tourner sur un A15, tout ça simultanément.
Il y a aussi un peu de soft fourni par ARM pour rendre transparent à l'OS l’existence de CPU différents, donc à plus haut niveau le scheduler de l'OS n'a pas à se préoccuper de big.LITTLE et qu'il y ait des A7 et des A15 qui tournent simultanément.
 

Je viens de me taper la doc sur la site arm et effectivement ya une petite partie software mais comme tu dis le gros c'est hardware.

Tu bosses la dedans ?

 
Oui je bosse dans l'embarqué et le design de SoC, et ARM est venu nous faire une présentation de leur big.LITTLE.  
Sur le papier ça a l'air vraiment sympa, reste plus qu'à voir en pratique.

Et si on revenait au S4 ?  

Oui parce que si ça se trouve il a le S600  

Le mec qui casse tout

Ok merci

C'est clair, quand je vois déjà le bordel des règles de gestion de fréquences & voltage sur un CPU Intel... j'ose pas imaginer ici où l'on a deux CPU avec chacun de multiples coeurs.

C'est super balaise comme concept !
Et niveau alimentation du A15, seul le coeur utilisé sera alimenté ? ou ils seront tous alimentés mais à des fréquences différences ?

Ma dernière question concerne les jeux d'instruction : le A15 a des instructions supplémentaires ? ou le A15 et le A7 partagent exactement les mêmes caractéristiques ?
Je veux dire par là : d'un point de vue compilation, est-ce qu'un code assembleur issu d'un compilateur optimisé pour le A15 tournera correctement sur un A7 ?
(je suppose que oui, sinon ça sera un GROS bordel...)

on va se faire un topic TECH pour discuter des archi.
Perso je trouve ça super intéressant

Chaque core est "power gated" indépendamment.
 

Les 2 ont exactement les mêmes jeux d'instruction (ARM V7a). Sinon je pense que le switch serait pas possible.

 
Les CPU inutilisés seront clock-gaté de manière classique (clock coupée).
 
 

 
Justement, c'est pour ça que l'A7 est très similaire à l'A15, ils ont exactement les mêmes features et le même jeu d'instructions, sinon effectivement ce serait carrément ingérable.
 
 
Voilà, j'ai fini, on passe au S600 ?    

comme dit plus haut c'est carrément du power gating: alimentation totalement coupée.

 
Et oui il en faut toujours un !    
 
 

 
Oui, alors vas-y, on dit que le S600 n'est plus vraiment un A9 sans pour autant être un A15, explique-nous pourquoi. Tu as une heure.    

 
Oui c'est vrai, là on a le temps pour s'autoriser du full power gating, ce que d'habitude on évite.

pour ceux qui s'interessent à la technique:
http://www.arm.com/files/downloads [...] _Final.pdf
 
la migration entre un A15 et un A7 prend ~20µS, sur la figure 5 on voit les opérations de passage d'un coeur vers un autre, ce sont des opérations classiques d'un OS (le soft contrôle la migration en suavegardant/restorant les registres, en envoyant des commandes de gestion des caches et de power)

drap!!!

Ca restera en plastique. La raison principale est d'eviter tout soucis d'approvisionnement avec l'alu comme a pu connaitre Apple ou HTC.
 
Source : mon job

J-5 çà approche!!
J'en peux plus d'attendre, je l'attends encore plus que mon SGII que j'ai toujours.
J'espère ne pas être déçu sinon je ne sais pas quoi prendre pour changer mon SGII!!

Un SGS3

... ou un Z...
 
ou un one...
 
 

Oui peut être. A la fin de la semaine je serai décidé !!

Nop pas de SG3:-)

 
pareil, j'attends la présentation pour me décider avec le One  
 
le Z m'attire moins  

Le Z est pas mal mais je sais pas j'ai peur que les maj soient un peu foireuses.
L'avantage de samsung c'est que même 2 ans après, il y a des updates pour le SG2 et je trouve çà plutôt pas mal.
Je pars sur un smartphone qui va me faire 2 ans mini avec les specs suivantes :
- Processeur véloce
-ecran de 4.7 ou 5" max FULLHD
-APN de belle qualité (pour une smartphone )
- 4G/NFC
-Android
-Bonne autonomie
-Design classe ou sobre
 
Y a pas mal d'appareils qui correspondent à çà  en ce moment : HTC One / Xperia Z/ peut être le Galaxy 4, wait & see

ce que j'espère le plus sur le GS4 c'est qu'ils gardent le slot microSD et la batterie amovible (ou au moins facilement remplaçable).

 
C'est prévu    
 
Galaxy S4... J-4  

Enfin J-5 pour nous en France puisqu'avec le décalage horaire, la présentation sera pour nous à 1h du matin le 15 mars.

Je pense toutefois que Sony à frappé très fort avec la IP 55/57, à mon avis c'est aussi cet aspect qui amènera des clients chez Sony. Parce que je pense que la plupart des clients n'ont aucune connaissance de ce que c'est que des mise à jour android. Tant que ça tourne bien pour les taches basiques, ils ne s'en soucient pas ou peu. Maintenant pour des connaisseurs comme nous il est clair que les mise à jours font peur, surtout chez Sony.
 
Maintenant nul doute que ce GS4 sera très très bien vendu. Peut-être plus que la concurrence ? Wait & See

Oui mais bon à ce prix, la majorité des gens lambdas iront sur le S4 car c'est une valeur sur.

C'est sur

tout le monde s'en cogne de cet norme... personne va a la piscine avec son smartphone!
A mes yeux, c'est purement marketing....

 
Je viens de commander mon xperia z, ce qui m'a fait penché, ce n'est pas cette norme IP55, mais le fait que le téléphone ne soit pas en plastoc.
Si le S4 est finalement en verre/alu... j'annulerai ma commande pour un S4.
 
Parce que bon, le S2 a quand même très mal vieilli par rapport à mon Iphone 4 (esthetiquement parlant)
 
Edit : le one est magnifique, mais le manque de port micro SD m'a refroidi