Ce week end, la société Chipworks a procédé à son traditionnel "teardown" des puces incluses dans l'iPhone 7, en se concentrant particulièrement sur le SoC A10 ...
Lire la suite ...

dans 15 jours je l'ai ma pupuce A10. Evidemment c'est une très bonne puce mais la course est loin d'être finie avec l'arrivée des puces mobiles @3GHz (Snapdragon 830, Exynos 8895 et Helio X35)

La première puce mobile a proposer du coil whine aussi

http://www.tomshardware.fr/article [...] 61191.html

Intel, c'est vraiment le moment de se sortir les pouces du cul. La meme chose pour Qualcomm. J'en ai marre qu'Apple tienne le haut du tableau, et que les autres agissent comme si de rien n'etait.
 
Ironiquement, quand ARM et les OEMs Android sont parti avec big.LITTLE, Apple et ses fans trouvais que l'idee n'avais aucun merite. FFW quelques annees plus tard... surprise, un design big.LITTLE!

 
Pour quoi faire ? M$ va continuer de leurs fournir du travail en maintenant le x86 en vie et AMD est encore plus à la ramasse. Intel à tous le temps qu'il lui faut pour développer son renouveau...

Pourquoi Apple ne communique pas directement sur le processeur?

Manque pas grand chose pour les mettre dans les macbook.

Je doute qu'Apple ait parlé de big.LITTLE, mais je veux bien un lien
 
Pour parler sérieusement, le plus gros problème de big.LITTLE (et d'ARM ces dernières années), c'est le Cortex A57, ou plutôt son manque de performances par rapport à l'A53. Exemple avec l'Exynos 5433, il a 4 coeurs big A57 à 1.9 GHz, et 4 coeurs LITTLE A53 à 1.3 GHz.  
 

 
Malgré 46% de fréquence en plus que les A53, les A57 ne sont "que" 34% plus performants sur les instructions entières (c'est heureusement mieux en float mais ça ne sauve pas tout). C'est gênant, pour ne pas dire autre chose  
 
Plus de détails et de benchs chez SiSoftware pour ceux que ça intéresse : http://www.sisoftware.eu/2015/06/2 [...] ky-number/  
 
On ne sait du coup pas ce qu'utilise Apple pour ses mini coeurs, mais il est probable qu'il s'agisse d'une version de son archi custom également, et probablement pas d'A53.  
 
C'est toujours dangereux de mixer les archis, l'Exynos 8890 de Samsung mixe M1 (son archi custom) en remplacement des A57 en big, et A53 en LITTLE. Mais ça crée des bugs improbables cf : http://www.mono-project.com/news/2 [...] 64-icache/

Personnellement je me baserai pas sur Geekbench pour tirer des conclusions.  
Les processeurs x86 ont toujours été relativement mauvais sur ce bench par rapport aux ARM. Linus Torvalds avait lui même fait un commentaire assez éloquent là dessus il y a quelques temps :  
http://www.realworldtech.com/forum [...] tid=136666
 
Personnellement je saurais pas dire ce qu'il en est, mais j'ai une confiance limitée en Geekbench.
Anandtech avait fait une comparaison entre Core M Broadwell et Skylake et Apple A9X à l'époque de la sortie de l'iPad Pro.
http://www.anandtech.com/show/9766 [...] o-review/4
On peu y voir que c'est assez serré avec Broadwell, et Skylake est un poil devant. L'A9X ayant probablement un TDP relativement similaire (sans doute un peu inférieur) aux Core M.
 
Concernant l'A10, il doit tourner autour de Skylake en terme d'IPC globalement je pense.
Dans tous les cas, le x86 n'a jamais vraiment brillé à basse consommation. La force du x86 c'est les systèmes haute performance à gros TDP.

"Déjà largement en avance côté performances sur le reste de l'écosystème ARM, l'A10 commence à devenir embarrassant même pour Intel, dépassant un Core M Skylake en monothread sous Geekbench 4 (voir ici  et là  ), avec un "TDP" au moins deux fois inférieur (et sans mécanisme Turbo). "
 
Pour moi il est clair qu'Apple va passer sous ARM pour le monde portable.

juste les applicatifs.
 
il faudra tout recompiler pour de l'ARM et ca fera tache d'avoir 2 type de CPU. je vois mal Apple supporter des MacBook a base d'ARM et des MacPro a base de X86

Ouais une intégration en macbook air est de plus en plus crédible ! La vache le bond en autonomie qu'il y aurait encore !

Apple a déjà eu le problème en 2006 en passant de PowerPC à x86, et ça c'est plutôt bien passé.  
 
Pour info sur Mac, les applis sont des dossiers (app bundle) dans lequel on trouve des exécutables pour chaque archi (pareil sur iOS ou on peut avoir plusieurs exécutables compilés/optimisés pour chaque archi, armv7, et les différents armv8 par exemple).  
 
Quand à la cross compilation le problème est résolu aussi depuis un moment vu qu'ils possèdent le compilo de la plateforme (LLVM) et qu'ils font du cross compile depuis un moment. Par exemple les développeurs d'applis iOS, lorsqu'ils utilisent le simulateur iOS intégré dans Xcode, compilent leur app nativement en x86.  
 
Mixer deux archis, au moins temporairement, serait osé pour un marché (MacOS) assez petit. Mais les problèmes d'Intel sur la production de ses SKU mobiles GT4e va finir par les irriter à un moment. Il a été rapporté maintes fois qu'Apple a testé des MacBook ARM en tout cas. De la à les commercialiser...

Le problème c'est les applications existantes qui ne seront pas recompilées pour ARM.  
Pour ça il faut un système d' "émulation" (compilateur JIT x86->ARM ?), qui rajoute une couche, et nuit aux performances.
 
Il y a aussi les applications qui utilisent explicitement des instructions x86 (via intrinsics, ASM...) qui doivent être adaptées, et pas juste recompilées.
 
Mais bon, c'est pas impossible, avec le contrôle total qu'à Apple sur son système, ils arriveront probablement à forcer le changement si ils le voulaient

Un mac sous ARM je doute fort que ça arrive avant qu'Apple aie intégré le SVE. Le test d'Anandtech montrait clairement que NEON dans sa forme actuelle n'est pas aussi performant que SSE/AVX. Or la performance vectorielle reste un paramètre important sur mac.
Puis il y a aussi la compatibilité Windows, qui ne tourne pas encore réellement sur ARM. C'est certes un bien moins gros argument aujourd'hui qu'en 2006, mais psychologiquement, dans la tête d'un acheteur, ça pourrait encore compter.

 
 
Toujours difficile de répondre à la question de ce qu'est un test représentatif !  
 
Geekbench 3 était extrêmement synthétique avec des benchs trop basiques avec quasi que de la crypto/compression (aes, sha, décodage jpeg, décodage png, bzip2) et une pondération discutable (cf le commentaire de Linus). La version 4 semble mieux balancée à première vue, avec des algos plus compliqués/réalistes, il y a toujours des classiques genre compression LZMA (7zip) et JPEG mais aussi des choses plus concrètes comme SQLite, compilation LLVM ou rendu PDF.  
 
Après on peut toujours critiquer tout bench synthétique, mais on doit faire la même critique à specint2006 (utilisé par Anandtech plus haut), plus spécifiquement aussi parce que c'est LE bench de référence d'Intel pour lequel il optimise (massivement) ses compilateurs.
 
Pour prendre un exemple, si je prends des benchs soumis par Intel à Spec pour un FX-8150 et un 6700k (avec ICC 12 et 16) :
FX-8150 : 22.3 (https://www.spec.org/cpu2006/results/res2011q4/cpu2006-20111121-18938.html)
Core i7 6700k : 72.8 (https://www.spec.org/cpu2006/results/res2016q3/cpu2006-20160623-42451.html)
 
Je ne suis pas sur qu'on puisse dire que le 6700k soit vraiment 3.26x plus rapide qu'un FX-8150. Si on compare avec notre protocole de test, que l'on essaye de rendre le plus représentatif possible avec de vraies applications/jeux, côté applicatif (multithreadé) on est a +52.8%, et en jeux 3D (ou les perfs single thread sont importantes) +93.8% (voir là http://www.hardware.fr/articles/94 [...] cpu.html).
 
Il y a plusieurs problèmes dans l'approche d'Anandtech, mais le principal vient de l'utilisation de deux compilateurs différents, d'un côté LLVM et de l'autre ICC 16. Donc on compare à la fois des archis différentes, et des compilateurs différents sans savoir d’où vient la différence.  
 
Si on regarde les liens spec dans le détail, ce qui vaut a l'indice d'être si élevé entre le FX et Skylake, c'est un des benchs, 462.libquantum, qui provoque l'écart démesuré. C'est aussi logiquement le bench ou il y a le plus d'écart chez Anandtech.  
 
Et forcément pas de surprise, c'est LE bench pour lequel les optimisations sont les plus efficaces. Anandtech supposait qu'on voyait une différence dans la qualité de la vectorisation, et donc la supériorité d'AVX sur NEON (qui pour le coup est probablement réelle), mais cela n'entre pas en jeu.  
 
Les développeurs de LLVM ont fait une présentation sur le sujet en 2015 justement ou ils expliquent les optimisations que fait ICC pour libquantum, et qu'ils ne font pas encore : http://llvm.org/devmtg/2015-10/sli [...] adroom.pdf
 
Pour faire très court, une des techniques d'ICC est de changer la manière dont sont stockées les données (Array of Structs (AoS) to Structs of Array (SoA)), c'est très bénéfique pour les benchs limités par la bande passante mémoire ou qui tournent en cache. ICC fusionne aussi des boucles de manière extrêmement cavalière. Tout ça distord fortement les benchmarks. LLVM essaye d'implémenter des optimisations généralisables, et pas uniquement pour briller dans les benchs (ce que fait Intel), ce qui les dessert (même problème pour GCC vis à vis de spec). La plupart de ces techniques sont utilisées sur les autres benchs spec, donc en pratique tous les écarts donnés par Anandtech sont faussés parce que l'on ne compare pas des choses identiques, mais libquantum est l'exemple le plus typique des scores déraisonnables. Sur un score spec global, LLVM estime pouvoir gagner 32% (!) avec ces optimisations, et d'autres qu'ils n'ont pas identifiées, autant dire qu'il faut nuancer fortement l'effort d'Anandtech (qui a tout de même eu le courage de tenter une comparaison). On notera aussi a propos de libquantum qu'il fait partie des benchs auto-parallélisable par ICC (transformation auto du single thread en multi thread).  
 
Bref, tout ça pour dire que le bench parfait n'existe pas, et que specint2006 comparé avec deux compilos différents - dans un benchmark qui est devenu au fil des années un benchmark de compilos - l'est probablement même moins que Geekbench. L'idéal reste de faire des tests applicatifs (ce que l'on essaye de faire pour vous), mais cela se limite à une seule plateforme/OS si l'on veut des résultats cohérents.

concernant l'hpothétique mac ARM, j'ai quand même des doutes:
lors du passage du 68K au PPC puis du PPC au x86, on passait de CPU à d'autres plus puissants;
ainsi, le temps mis par l'émulation est compensé par la puissance supérieure, et l'appli tourne aussi vite sur la nouvelle archi que sur l'ancienne.
pour passer du x86 à l'ARM, pas de gain de puissance notable, voire moins: l'émulation sera donc douloureuse:
les appli x86 tourneront moins vite sur ARM!
de plus, émuler un jeu d'instruction RISC (PPC) est plus simple qu'émuler un jeu CISC devenu aussi complexe avec le temps (x86 et x86-64)
le passage de x86 à ARM sera plus dur que celui qui a été fait de PPC à x86
et quid de l'émulation de SSE/AVX? j'ai des doutes sur l'efficacité à en attendre
 
un solution à ce problème pourrait venir du fait que Xcode utilise LLVM/Clang
les appli sont en fait une sorte de bytecode compilée juste à temps pour la bonne plateforme:
on passerait donc outre la phase d'émulation
reste toujours les optimisations pour SSE/AVX qui ne seront jamais bien traduites en NEON, à mon avis

 
Merci pour cette réponse détaillée.
Effectivement, on manque d'éléments de comparaison pour tirer des conclusions entre l'ARM d'Apple et le x86 d'Intel. Même si il est très probable que sur le format téléphone/tablette, la solution d'Apple soit effectivement supérieure.
Dommage du coup qu'Anandtech n'ait pas utilisé Clang pour leur comparaison, ça aurait été plus équitable qu'utiliser ICC.

On peut voir pour specint2006 l'impact du compilateur justement parce qu'on peut le compiler et qu'il y a beaucoup de données sur le sujet.
 
Par contre du moment ou le benchmark est propriétaire (comme 3D Mark ou Geekbench), on n'a aucune chance de savoir, a part comparer avec des données de nos propres benchs. Ce qui veut dire pour 3D Mark par exemple qu'on est incapable de détecter effectivement les remplacements de shaders dans les drivers. Idem avec des hypothétiques logiciels tiers qui seraient identiques sur Windows/iOS/Android (en pratique il n'y en a pas).  
 
Dans le cas de Geekbench, aux dernières nouvelles il utilise GCC sur x86 et android, et Clang sur iOS, ca n'est pas parfait, mais c'est "moins pire" que mettre ICC dans le mix (GCC et Clang sont plus proches). A première vue, les résultats de Geekbench 4 me semblent "relativement honnêtes" comparé à ce que j'ai pu voir dans mes propres tests.

L'année prochaine un gros A11 en 10 nm encore plus puissant pour un iPhone avec 8 go de ram et 512 go de stockage + un dock avec clavier et écran 11" pour l'utiliser comme un ordinateur portable le tout avec un OS convergent ?
Là pour le coup Apple pourrait vraiment dire que c'est une révolution.
Plus besoin d'ordinateur, ton smartphone peut-être utilisé comme un ordinateur.
 
Mais bon pour l'instant Apple ne semble pas s'intéresser à la convergence de leur OS (écosystème de macOS complètement différent de celui d'iOS).
C'est d'ailleurs la seul entreprise ayant un OS mobile et desktop a ne pas aller dans ce sens, Microsoft cherche à unifier Windows 10 mobile et Windows 10, Google cherche à faire fonctionner les app Android sur Chrome OS et Canonical bosse sur Ubuntu touch qui devra à terme partager presque tous ses composants avec Ubuntu desktop.
 
Je trouve ça étrange qu'Apple ne s'intéresse pas à la convergence.  

C'est déjà le cas avec Ubuntu Convergence (après côté puissance ça s'améliorera toujours, c'est sûr)

Pour être précis, Apple n'a pas convergé les interfaces utilisateur. Ils pensent que mélanger touch et souris est une mauvaise idée pour faire court (et après Windows 8 difficile de leur donner tort ).
 
Par contre techniquement, iOS et MacOS utilisent le même kernel, et si l'on met de côté l'interface utilisateur, a 99% les mêmes API (ce qui vaut la compatibilité cross platform que j'évoquais plus haut avec le simulateur iOS qui compile nativement pour x86).  
 
Donc la convergence est là techniquement, mais n'est pas visible parce que des UI différentes.

C'est pour ça que j'aime hardware.fr, les discussions sont tellement intéressantes qu'on passe plus de temps à lire les commentaires que lire l'article =)

Je plussoie

Oui c'est vrai que ce coup-ci les discussions sont au moins aussi intéressantes que l'article. Effectivement Geekbench n'est pas LE benchmarck définitif, juste un bench pour lequel on peut faire des optimisations. Mais effectivement je suis très impatient de voir un iPhone 8 avec 4 ou 6Go de RAM et 256 de SSD pour l'utiliser comme un vrai ordi. Apple a un coup à jouer

Ca ressemble plus aux spécifications de l'éventuel Surface Phone ça. Je doute qu'Apple aille dans cette voie à court terme.

+27% de fréquence et seulement +40% de perf en plus alors qu'on passe de > 2 milliards de transistors à 3.3 milliards ... (environ +65%)
 
Y a pas un problème de rendement ?

"Seulement" +40% de perfs à process identique en un an ?  
 
Sinon ce sont des SoC, System on a Chip, pas juste des CPU. La superficie des cores est minuscule comparativement à la puce, seulement 16mm2, cf la photo. Le reste du die est utilisé par le GPU (annoncé 50% plus rapide lui aussi par rapport à l'A9) et les blocs fonctionnels du SoC, contrôleurs mémoires, blocs pour l'appareil photo (qui prennent pas mal de place), etc.  
 
(sinon c'est l'A8 qui avait 2 milliards de transistors, pas l'A9, donc le chiffre des +65% n'est pas bon non plus)

J'ai rien trouvé à part "> 2B transistors"  
Du coup c'est peut être 2.99 milliards et là effectivement mon calcul est méga foireux.

Pas de chiffre public pour l'A9. Mais comparer les transistors à un éventuel rendement n'a pas de sens, les deux sont dissociés, encore plus sur un SoC ou le CPU n'est qu'une toute petite partie de la puce.

Oui mais malheureusement ce n'est pas encore 100% au point et Ubuntu touch souffre de quelques problèmes l'empêchant de rencontrer un succès commerciale (notamment le manque d'applications). Faire fonctionner les app Android sous Ubuntu Touch ou proposer quelque chose pour porter les app Android vers Ubuntu Touch rapidement (tout en gardant le Java, faire fonctionner Java sous Ubuntu touch ne devrait pas être trop compliqué) aiderait pour ce problème. Mais Canonical n'a pas énormément de ressource, il est mieux pour l'instant que leurs équipes se concentrent sur la base de l'OS.
Après oui logiciellement Ubuntu Touch est l'OS sur lequel la convergence est le plus avancé. Par contre niveau hardware la disponibilité du meilleur téléphone (le Meizu pro 5) est malheureusement de 0 à l'heure actuelle. La seule solution pour l'obtenir est de prendre la version Android, flasher un firmware beta qui permet de déverrouiller le bootloader pour enfin installer Ubuntu touch
Et sa puissance en single core (exynos 7420) est très moyenne à côté de l'a10.
 
Je pense que l'avenir du pc auprès du grand public se trouve dans la possibilité d'utiliser un téléphone comme un pc. De plus en plus de gens abandonnent leur pc pour des smartphone, le seul cas ou le pc sert encore pour le grand public c'est lorsqu'il faut un vrai clavier est un grand écran (pour taper sur microsoft word / libre office un pc reste toujours mieux qu'un smartphone).
Proposer un dock avec clavier et souris pour y mettre son smartphone qui sert de tour règle le problème sans avoir besoin d'acheter un pc complet. Et tout ce qui est dans la mémoire du téléphone est directement utilisable !
J'avais d'ailleurs vu des projets de financement participatif cherchant à produire ce dock.
 
Et à terme quand la fibre sera plus répandu, même les usages nécessitant beaucoup de ressource pourront être fait depuis un smartphone avec un dock grâce au cloud, puisque les services gourmand fonctionnerons sur des gros serveurs au lieu l'appareil de l'utilisateur (avec des avantages comme le fait d'être beaucoup moins limité par les ressources, backups transparent pour l'utilisateur sur l'infrastructure du serveur, etc ... mais aussi des désavantages comme les problèmes liés à la vie privé, la sécurité et la légère augmentation de latence).
Ce dernier désavantage va surement pousser les joueurs à garder un pc puissant chez eux (en plus du plaisir des choix des composants et du montage ).

Je partage également ce point de vue sur l'évolution de l'informatique
 
De mon côté je me sers au quotidien d'Ubuntu Touch sur un Nexus 4, ça marche pas si mal (d'ailleurs je viens d'installer l'OTA 13)
 
Pour la convergence j'ai testé (et ça fonctionne !) mais sans surprise ce téléphone de 2012 tire un peu la langue sur les applications les plus lourdes (Libreoffice, Gimp...). Mais c'est déjà beau que ça marche
 
Effectivement vivement de nouveaux téléphones avec cet OS très prometteur

Le kernel j'en doute pas, par contre je ne suis pas certains que tout ce qui est invisible à l'utilisateur est identique sous iOS et macOS. Par exemple le package des applications ? Je ne connais pas assez l'écosystème d'Apple pour en être certains, mais il ne me semble pas que c'est le même sous iOS et macOS.
 
La convergence de l'UI permet de proposer à l'utilisateur une expérience continu, ce qui lui évite d'apprendre deux fois l'utilisation d'un OS (une fois en mobile, une fois en desktop).
C'est donc un gros avantage quand on sait que les personnes s'attachent facilement à leur habitude. Par contre oui c'est très difficile à mettre en place techniquement. Windows 8 est en effet l'exemple parfait de ce qu'il ne faut pas faire. L'OS étaient tellement pensé pour le tactile qu'il était difficilement utilisable en desktop. W8.1 a un peu rattrapé le coup en permettant enfin de lancer les apps convergente en fenêtré au lieu de full screen seulement. Mais il y a quand même des points qui bloque encore (notamment la barre de gauche qui nécessite un mouvement pas très naturel pour être ouvert via la souris).
 
Canonical a eu le même problème avec les premières versions de unity 8 utilisable en version desktop (enfin, justement de n'était clairement pas utilisable en version desktop), mais c'était et c'est toujours du work in progress (il fallait récupérer l'iso ubuntu desktop next qui était plutôt caché pour tester, maintenant il faut juste installer le paquet de mir et d'unity 8). Actuellement unity 8 est plutôt bien utilisable en desktop et il va surement encore avoir pas mal de changement avant qu'il ne remplace unity 7.
En tout cas l'approche de Canonical pour proposer une convergence de l'UI me semble déjà mieux réussite que celle de Microsoft avec W8/W8.1.

Non, je confirme d'expérience qu'ils sont identiques, ce sont des App Bundle : https://en.wikipedia.org/wiki/Bundle_(OS_X)  
 
Tout ce qui est de bas niveau est identique côté système, depuis le début. Et les API pour les développeurs, hors UI, le sont aussi. iOS est souvent servi le premier quand il y a une rénovation des API mais elles sont portées l'année d'après au pire sur MacOS, de ce point de vue pour un développeur le seul problème c'est l'UI. AppKit (les API UI desktop) sont assez vielles (elles sont héritées de NextStep) et détestées par beaucoup de devs. UIKit (les API touch) sont par contre beaucoup plus modernes, moins lourdes. Beaucoup espèrent une rénovation d'AppKit ou une fusion. En interne, Apple utilise déjà des API d'UI unifiées, notamment pour Photos (leur app de gestion de photos) avec une API appelée UXKit. Pour l'instant Apple ne l'a pas publiée (beaucoup de repproches ont été faits au lancement de cette app sur sa "différence", trop marquée touch !).  
 

Avis totalement personnel, mais je pense que ça ressemble plus à une "bonne idée" qu'autre chose. Avoir une interface commune utilisable à la souris, et au touch, personne n'a trouvé de solution convaincante. Il est très difficile de contenter tout le monde et on est obligé de faire des sacrifices souvent côté desktop pour rendre le touch possible.  
 
Si Unity est "moins pire" que W8 dans l'idée, on ne peut pas faire comme si il le virage pris par l'interface n'était pas décrié par une bonne partie des utilisateurs des versions précédentes d'Ubuntu. Souvent c'est aussi de la peinture, genre le "Software Update" qui nous donne (façon Mac App Store) une liste des apps à mettre à jour mais qui repose toujours derrière sur apt (et heureusement disons). Mais l'interface est aussi ridiculement buguée, se rafraîchissant n'importe comment avec a peu près aucune indication de progression fiable ! Vu que j'imagine qu'elle lance apt en ligne de commande derrière on peut probablement le comprendre, mais personnellement je trouve que ça fait un peu tâche.  
 
Maintenant sur le fond je suis complètement d'accord avec l'objectif, mais personnellement, je crois beaucoup plus à une convergence avec des applis unifiées qui auraient tout de même deux UI distinctes, une spécifique touch, et une spécifique souris, sans tenter de vouloir les merger dans un truc qui sera mal accueilli comme étant une multitude de compromis.  
 
A noter pour finir pour ceux que ça intéresse que l'approche d'Apple sur la convergence passe pour l'instant par des applis qui restent séparées mais qui peuvent s'envoyer des données. Exemple typique, commencer à écrire un mail sur son iPhone, et le finir sur son Mac (une icône apparaît dans le dock pour récupérer automatiquement le mail qu'on a commencé à taper). Idem pour planifier un itinéraire sur son mac et l'envoyer vers l'iPhone, etc... Il y a aussi un clipboard unifié (assez sécurisé). Évidemment c'est un modèle limité dans son périmètre, mais qui répond partiellement aux frustrations d'avoir des ordinateurs, de poche ou pas, qui ne communiquent pas entre eux.

Merci pour ses détails techniques sur iOS / macOS !
 
Avoir un code UI pour chaque interface et garder en commun le reste de l'application me semble aussi un bon compromis. L'avantage étant qu'on peut faire un UI plus adapté. Le désavantage c'est qu'il y a deux UI à développer et maintenir.
Dans le cas d'une interface convergente qui gère les deux cas, il y a certains compromis à faire notamment sur l'espacement pour rendre l'interface utilisable avec les doigts et lisible sur un petit écran.
Approcher trop des boutons complique l'utilisation au tactile, un texte trop petit sera illisible sur un écran de portable. Et un grand texte n'est pas nécessaire sur une interface desktop, idem pour les boutons, on peut les placer à côté sans problème la souris étant très précise.  
 
La deuxième possibilité me parait plus simple à maintenir, mais la première me semble plus efficace en utilisation desktop.
 
Par contre concernant Ubuntu et la convergence, je parle d'Unity 8 qui pour l'instant est encore en développement (sauf sur la version mobile où il est déjà en prod). On ne connait pas encore l'impact qu'il aura sur les utilisateur d'Ubuntu lorsqu'il sera mit sur les versions de productions.
Ce qui a fait partir une bonne partie des utilisateurs d'Ubuntu, c'était le passage de Gnome 2 à Unity en 2011. Les premières versions d'Unity étaient surtout pensé pour les notebook et non pour la convergence mobile/desktop. De plus il souffrait de manque de possibilité de personnalisation (toujours le cas actuellement d'ailleurs) mais est également très lourd (en même temps quelle idée de mettre de la 3D partout ...) et comme cela ne suffit pas, il casse la plupart des habitudes d'utilisation par rapport à Gnome.
Je pense que c'est ça qui a fait partir les utilisateurs (et c'est ce qui a été principalement été reproché à Unity).
Pour avoir testé les versions de dev d'Unity 8, il ne modifie pas beaucoup les habitudes par rapport à Unity 7 (par contre je pense qu'il va avoir des régressions sur les thèmes et la personnalisation au début). On verra bien par la suite l'impact.
 
Personnellement le changement ne me dérange pas tellement (je peux passer d'un environnement de bureau Linux à un autre sans trop de souci, je switch régulièrement d'Ubuntu à Windows / autres distributions régulièrement sans que cela me dérange non plus), mais pour l'utilisateur moyen ça semble vraiment être un problème.

C'est aussi l'idée de la Convergence par Ubuntu, l'affichage des applis s'adapte suivant la taille de l'écran et les périphériques connectés

Les soc apple sont excellents. Dommage qu'ils ne les vendent pas aux autres constructeurs, j'aurais adoré avoir un mini pc avec ce soc

Ca se discute. Le reproche qu'on pouvait faire a UWP chez MS, ou a ce que tente Ubuntu, c'est qu'ils font des interfaces qui scalent en fonction de la taille des écrans (smartphone, tablette, notebook/desktop), pas une scission nette entre une version touch et souris.
 
Chez MS, c'était en grande partie parce qu'ils étaient aussi derrière l'idée des PC avec écrans tactiles (en plus de leurs rèves mobiles). Perso je ne suis toujours pas convaincu de touch + souris en simultanée dans une même interface parce que ca force trop de compromis (au minimum si on prend en compte la possibilité de touch, il faut que toutes les zones cliquables soient plus grandes, sinon c'est pas utilisable). J'ai toujours mal quand je vois des gens tenter de cliquer un lien minuscule dans Outlook avec leur doigt sur un notebook et s'y reprendre à trois fois. Mais bon, c'est un long débat.  
 
MS s'est pris une veste sur le mobile, mais à cause du fait qu'ils poussent aussi des notebook touch, ils se retrouvent obligés de continuer à avoir une interface principale adaptée un minimum au touch, alors que l'écrasante majorité des apps Windows reste du win32/.NET Forms qui ne sont pas du tout adaptés touch. Et contrairement à avant les devs ne suivent plus et restent sur les anciennes API.
 
Après peut être que ma vision de 8 et 10 est liée aux montagnes de problèmes qu'il nous cause pour faire des benchs (avec sa capacité a venir occuper un core sans prévenir pour faire des choses aussi cruciales qu'optimiser les apps .NET). A l'usage sur une grosse machine ca n'est pas forcément génant/visible mais sur des résultats de benchs ca se voit vite (voir littéralement pendant l'article sur le streaming ).

C'est ce que fait Windows Continuum: https://support.microsoft.com/en-us [...] -continuum
L'interface est vraiment celle de Windows 10 Desktop et de l'autre celle de Windows 10 Mobile.
Ce n'est pas juste un redimensionnement: la taskbar revient, la gestion du découpage de l'écran,...

cf message précédent pour les détails, pour moi ce qu'ils font est insuffisant/trop un compromis.
 
Je veux bien qu'on continue a en parler mais on est large dans le HS la )