Qualcomm a levé le voile hier sur son prochain SoC à destination de la mobilité. Le SnapDragon 835 doit, sur le papier, améliorer à la fois les performances ...
Lire la suite ...

   
De quelle émulation s'agit-il?

L'émulation x86/win32->ARM de Windows 10. Cf ici : http://www.hardware.fr/news/14873/ [...] intel.html

Il est possible que le soft d'émulation x86 de Microsoft exige de l'ARM plus généraliste pour que d'autres constructeurs puissent proposer leurs solution. Si il s'appuyait sur un soc trop personnalisé, cela aurait probablement posé des soucis de compatibilité/performances pour les autres

Du coup c'est une référence à la possibilité d'une architecture hybride x86/ARM?
 
Ce serait intéressant en effet, mais développer un cœur capable de gérer x86 et ARM serait contre productif. Reste la possibilité de faire cohabiter un cœur ARM et x86 sur la même puce mais ça doit être un vrai casse tête.

Non cf le lien. Windows 10 intégrera dans une prochaine update un émulateur logiciel x86 32 bits pour les CPU ARM.
 

L'architecture ARM permet l'interopérabilité du code, après il n'est pas impossible qu'il y ait des optimisations spécifiques aux Cortex. Mais de là a ce que cela ait obligé Qualcomm a abandonner son archi...  
 
Sachant que les Kryo "archi custom" des 820 n'étaient pas exceptionnels, l'option la plus probable est que Qualcomm ait simplement mis de côté son archi, soit temporairement le temps d'avoir un produit cette année et d'améliorer réellement son archi custom pour 2018, soit de manière plus prolongée. A suivre !

Non pas forcément des puces hybrides ARM/x86 mais un PC avec Windows 10 sous snapdragon 835.
Toutes les appli PC qui tourneraient sous Windows avec une puce ARM.
Au prix de quelques lenteurs dues à la surcouche d'émulation sans doute.

Je pense que c'est mis en avant sur un SoC haut de gamme pour qu'il y ait une performance à peu près convaincante et surtout éviter les téléphones trop "bas de gamme" : on court au massacre avec une RAM insuffisante, une mémoire flash très lente, le manque de fonctions sur la prise USB (USB OTG, USB 3.0, HDMI ou Displayport)
 
Autre aspect, chaque SoC est différent. Il y a plus de points communs entre un PC de 2009 et un PC de 2016 qu'entre deux SoC ARM de la même année mais de constructeurs voire de gamme différents. C'est le foutoir!
Un peu comme dans les années 80 : le même processeur était utilisé par les Amiga, Atari ST, Megadrive, Neo Geo, Macintosh mais il n'y a rien de très compatible là-dedans (à part un émulateur de Mac pour Atari ST)
 
Bon là, il y a bien plus de standards : USB, SD, eMMC, UFS, wifi etc. mais chaque SoC est comme un ordinateur différent, avec sa façon de booter et une collection de drivers spécifique. Donc Android est customisé pour chaque SoC et vous êtes coincé en Android 5.0 au lieu de 6.0, coincé en Android 6.0, en Android 4.4 etc., sauf si le fabricant du SoC et le fabricant du téléphone (ou une ROM communautaire) ont rendu possible la production d'une version d'Android plus récente.
 
Windows 10 version "desktop ARM" devrait donc pouvoir cibler un nombre plus ou moins large de SoCs, mais ça ne se fera pas tout seul, le jour où une chinoiserie en ARM aura ce qu'il faut (4Go de RAM, mémoire flash UFS rapide, etc.) pour pas un rond la compatibilité ne tombera pas du ciel.

On peut aussi imaginer du "bidouillage" : hacker un téléphone pour faire tourner Windows 10 mais la caméra ne marche pas, le GPS ne marche pas, ou pire (wifi, touchscreen).
Ca m'étonnerait un peu, ils ne devraient pas trop avoir de mal à verrouiller le Windows 10 ("whitelist" ).
C'est assez courant avec des images Android amateur, en développement, ou qui veulent refuser d'utiliser des drivers propriétaires.

PS : en revanche, traditionnellement un driver Windows est compatible à long terme sans besoin d'être réécrit tous les six mois, donc un SoC compatible Windows pourrait rester compatible Windows pendant longtemps.
Avec le système Linux/Android, il y a bien plus de liberté et de marge de manoeuvre pour les fabricants (mais in fine, pas tellement pour les utilisateurs) sauf qu'un driver pour linux 3.10 ne marchera sur linux 4.4 et ainsi de suite. Avec un "vrai" linux pour PC, serveur etc. les drivers sont libres et mis à jours en continu (dans le noyau linux "mainline" ), ou bien propriétaires (nvidia, etc.) et mis à jour pour chaque version.

Oui j'ai bien compris, du coup en quoi le choix de l'architecture qu'a fait Qualcomm a un impact?
Il sont obligé de rester sur du ARM ou il perdent le cœur de leur marché. Du coup sur un cœur ARM il n'y a pas grand chose qui permette d'optimiser réellement l'exécution du code x86, peut être un "compilateur" JIT, mais ça reste du soft.
 

 
le refresh rate variable a d'abord été inventé pour économiser du courant ; transmettre des millions de pixels 60 fois par seconde a un coût élevé.
 
ensuite, vu que le matériel supporte ce qu'il faut, et que l'équivalent existe déjà sous Windows pour les gamers, ça fait une "feature" pour être bien vu .

 
Ce sont surtout des raisons historiques dues aux écrans à tube cathodique.
CF cet article (page 2) de HFR : http://www.hardware.fr/articles/91 [...] blank.html

 
En fait, je n'ai aucune idée si c'est déjà supporté depuis des années par les téléphones et tablettes ou non.

Il faut un support de toute la chaine en fait, de l'OS à l'écran. C'est assez compliqué a implémenter en pratique parce que l'OS doit deviner ce que l'appli nécessite vraiment, dans un monde ou les applis sont plus ou moins animées.  
 
Sous iOS il y a déjà du refresh rate variable géré depuis un moment. La plus vielle implémentation causait des bugs avec certains jeux ou l'on se retrouvait parfois en 40 Hz au lieu de 60 Hz sans prévenir quand un évênement système intervenait. Ca a été corrigé (iOS 9.1 de tête ?) mais c'est comme ca que l'on a pu voir qu'ils changeaient la fréquence. Il y a une deuxième implémentation de refresh rate variable sur les iPad Pro qui a une meilleure granularité mais je n'ai pas testé en pratique jusqu'ou ca descendait.  
 
Dans les API Android un écran peut gérer plusieurs modes avec des taux de rafraichissement différents, mais je ne sais pas si l'OS switch tout seul d'un mode à l'autre ou si c'est juste aux devs de le faire (ce qui réduit l'intérêt).

Bientôt un snapdragon dans nos desktop au lieu d'un Intel ?

Je vois des gens parler de mettre un soc de téléphone/tablette dans un pc fixe, alors là j'ai une question : Si on peut comparer l'un avec l'autre, ça donne quoi niveau puissance, un soc comme ça?
 
Non parce que du arm pour un ordi de bureau, je veux bien, mais sur un fixe on s'en tamponne de la consommation (à ce point là, je veux dire, entre un proc à 50 et à 300w, ok, mais là, qui va changer pour passer de 60w à ... je sais même pas), donc si ça a la puissance d'un p4...  
 
Parce que j'ai eu une surface rt avec un tegra 3, ben à 3 pages word d'ouvertes, ou quelques onglets web, ça crashait.  
 
Alors je ne dis pas mais à moins qu'ils aient fait d'énormes progrès, c'est pas parce qu'on va pouvoir en mettre dans nos pc fixes parce que windows normal fonctionnera qu'on va le faire, si ça marche avec windows 10 mais que ça a la puissance pour windows 95...  windows 8.1 en mobile, il n'y avait pas de quoi se réjouir, et c'était il y a quoi, 4 ou 5 ans?

Tout est une question de TDP. Un SoC de téléphone/tablette c'est 2.5/5W environ. Mettre une puce 5W dans un PC Desktop ça n'a évidemment aucun intérêt.  
 
Ces puces de Qualcomm devraient plutôt se retrouver dans des tablettes ou des ultra portables.
 
Maintenant on peut aussi utiliser l'archi ARM pour faire des puces qui auraient un TDP plus elevé, et donc des performances significativement plus hautes. Ca commence à arriver côté serveur (parce que marché plus porteur). Microsoft a ouvert la porte avec Windows 10 et il faudra voir ou cela ira.  
 
Après sur la question de la performance, le problème c'est que l'on ne sait pas vraiment quels Cortex sont utilisés par Qualcomm et quelles modifications, si il y en a, ont été faites et quel est leur impact. En général les Cortex ne sont pas considérés comme particulièrement exceptionnels, il y a quelques chiffres ici sur les différentes versions : http://www.hardware.fr/news/14645/ [...] i-g71.html
 
Sur le potentiel brut des architectures par contre, on en a largement parlé dans d'autres threads mais l'archi custom ARM d'Apple est à TDP égal "autour" d'un Skylake version Core M. Les Cortex sont par contre plutôt derrière (mais tout dépend des versions utilisés). En général les Cortex ont des performances sur un thread plus faibles.

On peut aussi y voir la volonté de se concentrer sur ses points fort, et de prendre le reste sur étagère.

 
ok. Bon ben ils n'ont plus qu'à faire une carte mère en en mettant une dizaine dessus alors. Ils en font bien en pro, des cartes bi-proc ou plus, avec les xeon, non?  
 
une carte mère avec 4 ou 5 cpu dessus, ça économiserait le chauffage.

C'est beaucoup plus simple de monter les fréquences et le nombre de coeur pour utiliser le TDP, cf le 24 coeurs de Qualcomm pour serveur, cf ici : http://www.hardware.fr/news/14377/ [...] lcomm.html
 
Le lien parle également de la question de la standardisation, par exemple sequence de boot etc sur lequel il y a des avancées justement pour créer un écosystème d'abord côté serveur une fois de plus.

 
Un peu, car les Atom sont sur desktop et n'en sont pas loin.
Un SoC devrait largement dépasser les 5W en tournant à fond en continu, également. Pas de surchauffe ou de vidage de batterie duquel s'inquiéter.
 
Un intérêt aussi, tourner 24/7 ou aux heures de bureau : soit que ça coûte cher dans le tiers-monde, qu'ERDF et compagnie vont nous faire payer de plus en plus, qu'on est sur batterie/panneau solaire, ou dans un poulailler call center avec 40 postes, etc.
Après, on a aussi un peu de x86 pour ça.

Non, le principe d'un TDP c'est qu'il s'agit d'un seuil maximal et donc qu'on ne le dépasse pas. Je sais qu'Intel a fait n'importe quoi avec la notion de TDP, notamment avec les Core M, mais tout de même !
 
En pratique pour les SoC ARM Apple, ils sont autour de ces TDP et ne throttlent pas vraiment sur les dernières gen en charge continue.

Ce que je voulais dire c'est vu la montée en puissance du snapdragon par rapport aux CPU Intel, on pourrait d'ici quelques années avoir du snapdragon plus rapide que l'Intel à 1500 euros ..

C'est clairement difficile d'extrapoler. Mais on sait qu'il y a des recettes qui théoriquement sont ouvertes :
- Augmenter la fréquence (avec un palier sur la conso)
- Augmenter la mémoire cache (facile, ca coute juste du die)
- Augmenter le nombre de coeurs (limite plus facile pour ARM avec des cores plus petits)
- Jouer sur le prix (avantage massif de ce côté pour les fabless qui peuvent faire très mal aux marges installées)
 
Avec en préalable une archi très saine qui dispose d'une excellente IPC en basse conso et d'une gestion de la mémoire qui n'est pas hérité d'un contrôleur de disquette 5"1/4, il y a moyen probablement d'être très compétitif avec des TDP hauts, et assez facilement. Je ne suis pas convaincu que les Cortex (au moins les A57, on a pas forcément encore vu réellement ou sont les A72/73) répondent à ce critère par contre (la seule archi ARM qui répond aujourd'hui c'est, on va me dire que je fais une fixation, celle d'Apple).    
 
Il va être très intéressant de voir ce qui se passe côté serveur dans les 3 prochaines années. Même des Cortex, par paquet de 48, peuvent trouver une niche avec un prix dérangeant. Le système de marges d'un MediaTek, appliqué au serveur (avec une surmarge pour le plaisir), serait un cauchemar indescriptible pour le leader actuel du marché des serveurs. Le challenge est surtout sur ce qui est autour (standardiser les OS, la séquence de boot, la gestion des périphs externes) mais ARM tente de travailler sur la question (voir lien sur le 24C Qualcomm plus haut dans le thread).  
 
Le problème sera l'exécution pour les sociétés qui vont se lancer sur le marché, et là Qualcomm n'est pas forcément très bon. Il y a d'autres acteurs mais c'est encore flou. Broadcom avait une puce très prometteuse, mais il y a des rumeurs comme quoi ils auraient décidé de ne pas y aller. Il y a aussi des plus petits comme Cavium ( http://www.cavium.com/ThunderX_ARM_Processors.html ) qui ont une carte a jouer, mais est-ce qu'ils pourront avoir un impact sur le marché si Qualcomm se rate ?  
 
L'exécution, plus que les perfs, fera ou défera la menace sur le marché serveur. Bref, à suivre !

S'ils tiennent leur annonce de +27% de performance par rapport au 820 en isoprocess, ça mettrait le 835 aux alentours de Nehalem en single thread. C'est déjà pas mal, même si loin de ce que fait Apple (qui n'a pas la même problématique).

C'est pour ca que j'ai dit que le préalable était une archi saine avec un contrôleur mémoire performant (donc pas un Cortex). Ces deux choses réunies, monter en fréquence, augmenter les caches et le nombre de coeur permettrait d'avoir un produit très compétitif assez facilement.  
 
Ca n'est pas une priorité parce que les marges y sont moins généreuses que côté serveur, c'est pour cela que tout le monde part de ce côté.  
 

Intel peut baisser les prix bien sur, mais toute l'entreprise repose sur sa structure de marge particulière. Si elle est remise en cause, cela remet tout en cause, et en premier lieu son nombre important d'employés (autour de 100 000).
 
ARM commoditise l'IP, une petite société avec peu d'employés peut faire fabriquer pour un prix dérisoire des puces (voir le thread ou on a parlé du prix des wafers). C'est un changement complet de paradigme et on a vu qu'Intel sur le mobile, au delà des performances/watts basses de ses puces x86, n'a pas pu être compétitif sur les prix. Sur le marché mobile la commoditisation a été tellement violente que de nombreux acteurs ont jeté l'éponge.  
 

 
Le cout de l'émulation dépend de la distance entre les archis. Itanium était très loin de tout. x86 et armv8 sont assez proches donc le surcout d'un émulateur sera loin de 3/4x. Dosbox est hors cadre, on ne parle pas de la même chose.

L'emulation n'est que pour du X86 on est pas encore rendu au X86_64

Oui hâte de voir comment c'est implémenté et les perfs de cet ému

Vu que les cores Apples sont performants à cours terme les Mac ( Pro et Book ) pourrait tourner sous ARMs ...

Avec l'émulation sous Windows tout est en place maintenant donc oui ils pourraient. Mais je serais surpris que ça se fasse avant l'intégration du SVE. D'un autre côté un passage sous ARM signifierait la fin des Hackintosh, donc s'ils pouvaient ne pas le faire...
 
Concernant l'émulateur, Apple avaient obtenu des performances très acceptables avec Rosetta, même si cette fois c'est dans l'autre sens je doute qu'on soit à moins de 50% d'efficacité.
 

Trop gros, passera pas.

J'en vois rever du ARM dans les serveurs, avec 24C ou plus... Xeon 24C/48T existe deja, et en multi-socket aussi.
ref: http://ark.intel.com/products/93790
 
Quand au prix du 24C ARM, pas convaincu qu'il sera si bas que ca. Surtout si il faut "plein de cache et un meilleur controlleur RAM pour augmenter les performances". Et en fait il faut le comparer a un Intel 12C/24T genre http://ark.intel.com/products/93798
 
A terme peut-etre, et en commencant par le bas du marche (genre PC de bureautique).
 
Pour les PC de jeux, je doute que ce sera pour tout de suite.
 
Maintenant je ne demande qu'a etre surpris. Esperons Ryzen relativement bon et relativement pas cher, par exemple
 
Cote ARM, mon experience c'est Rpi 1B et 3, et c'est qd meme 15W pour le second, avec des performances anemiques.
 
Sur phone, j'ai un octo-core Qualcomm recent, et parfois je me demande ce qu'il fout...

15W sur le Rpi3 c'est une mesure ou la spec 5V 3A pour alimenter des périph USB? Certes le Rpi3 est raté, mais au boot carte nue il doit plutôt consommer dans les 3.5W (ce qui est déjà beaucoup). Pour les perfs, 4 A53, pas de miracle.

 
en idle ca consomme moins. Mais quand tu le fais travailler un peu, il y arrive vite a ses 15W... a part un clavier/souris et une clef USB, il n'y a pas grand chose de connecter. A oui le wifi...
 
1Go de RAM, c'est assez limite aussi.

15W avec si peu, ça me semble bizarre, c'est bien plus que tout ce qu'on peut lire sur la toile (je n'ai pas de Rpi3 pour mesurer). Faille du wattmètre sur les faibles consommations (par ex PM230), modèle défectueux?
Sinon oui le rapport prestations/prix du Rpi3 est faible, un odroid c2 par exemple en offre plus.

Ha oui là c'est gros...  
Pour être sérieux, le business Mac reste plus gros que l'iPad :  

 

C'est pas dit que ça soit moins efficace. PowerPC et x86 étaient plus éloignés que x86 et armv8. Sur l'ordre des données (https://fr.wikipedia.org/wiki/Endianness), le PowerPC était (principalement) big-endian (dans le bon sens) alors que x86 est little-endian. armv8 peut passer rapidement d'un sens à l'autre.
 

Personne ne "rêve", plusieurs acteurs, dont Qualcomm, vont tenter de se positionner sur ce marché dans les prochains mois. C'est factuel. Qu'il y ait des Xeon avec autant de coeurs n'a strictement rien à voir avec la question, c'est même totalement à côté. La réalité est qu'aujourd'hui il n'y a aucune concurrence sur le marché serveur. Intel possède plus de 95% du marché.  
 
Personne ne dit comme plusieurs aiment le caricaturer qu'Intel va disparaitre demain. Juste que pour la première fois depuis plusieurs années sur le marché du serveur, Intel va avoir de nouveau de la compétition (avec les entrants ARM, et aussi le retour d'AMD qui va tenter aussi de se repositionner sur le serveur x86 avec Zen). Le positionnement de ces nouveaux produits pourra, ou non, en fonction de l'exécution, apporter une concurrence plus ou moins importante à Intel sur le marché serveur.  
 
Et sinon oui, l'avantage de la structure de cout "IP commoditisé + fabless + fab externe" est réel, parce qu'il ouvre la porte à de multiples entrants (les fabless) pour un cout minime. L'histoire des semi l'a largement montré. Intel a d'autres avantages, à eux de les exploiter.  
 
L'arrivée d'un début de concurrence - là ou il n'y en avait plus - fait qu'il est difficile de penser que strictement rien ne va changer sur le marché serveur ces deux prochaines années.

ARMv8-A est très bien conçue, mais on va forcément perdre de la performance dans la traduction des instructions non? Tu penses qu'on perdrait juste en latence mais pas en débit? Voire même qu'ARMv8-A serait tellement supérieure qu'elle "exécuterait" le code x86 avec plus d'efficacité qu'un core x86?
 

Seulement sur les data, les instructions sont uniquement little-endian (ce qui tombe bien ici).

Faut arrêter d'être dans la caricature systématique sur tout les sujets, le Mac reste un énorme business pour Apple, c'est leur seconde plus grosse source de revenus en hardware.  
 
Qu'il y ait des interrogations ou des produits en retard n'a pas grand chose à voir. Le retard récent du refresh des Macbook Pro est en grande partie de la faute d'Intel qui n'a pas livré ses GT4e à ses clients, et qui les a même tout simplement abandonnés pour les générations mobiles à venir : http://www.hardware.fr/news/14785/ [...] -2018.html
 
La question GPU intégré est un vrai problème pour Intel et il y a eu un ratage majeur non expliqué encore sur Haswell et Skylake mobile.

Tu peux utiliser la quasi totalité d'un CPU x86 et ajouter un décodeur ARM en parallèle du décodeur x86, ça n'a effectivement pas grand intérêt, mais ça ne complique pas vraiment le binz...
 
Par contre, M$ prépare le terrain pour une transition vers l'ISA ARM, qu'elle ait lieu ou pas, et ça c'est un signe.

Allons.
 
L'article de Gurman chez Bloomberg ( là https://www.bloomberg.com/news/arti [...] -loyalists )
n'apporte que peu d'informations et se contredit. La seule vrai information est qu'Apple a eu un problème avec le développement de nouvelles batteries qui aurait raté :  
 

 
La manière dont l'argument est présenté est légèrement orientée, si effectivement Apple n'investissait pas, pourquoi investir dans le développement de nouvelles batteries pour ces laptops, et pas uniquement pour les smartphones ? Ne pas retarder plus le lancement et lancer avec un design alternatif est une décision de business qui fait penser à l'archi Cortex utilisée par Qualcomm pour le Snapdragon 835, histoire de ne pas être totalement hors sujet.  
 
Il y a des passages croustillants aussi comme :
 

 
On pourrait croire que c'est récent quand on lit ça, sauf que les équipes software ont été fusionnées en 2012 après le départ de Scott Forstall.  
 
L'article tente de surfer sur les mécontentements autour des derniers Macbook Pro et le fait que certains produits n'ont pas été mis à jour depuis longtemps comme le Mac Pro. Au mieux les anecdotes comme sur les batteries montrent surtout des ratages de développement et d’exécution auxquels il faut ajouter celui des GT4e d'Intel, plus qu'une volonté d'arrêter de produire des Macs.

 
 
En entreprise t as plusieurs milliers d ordinateur sur plusieurs site tu multiplie plusieurs milliers par la console de l ordi, de l ecran... Qui tourne quasi 8/10h par jour tout economie multiplier par plusieurs milliers ça fait une belle reduc sur la facture energetique
 
Idem le principal de l applicatif en entreprise c est de l extranet qui passe par navigateur web
Par contre t as toujours en entreprise 2-3 softs dinnosaure plus maintenu par l editeur, quans l editeur n a pas disparu
Pour un navigateur web pas besoin d un x86 un arm suffit
Et pour les vieux soft que t es encore obligé de maintenir tant que pas remplacé, bah ici on parle pas de jeu video
Donc de l emulation meme si moins perf que le jeu d instruction physique natif pour ce genre de soft, ça n impact que peu les performance
 
De toute facon le maillon faible en entreprise c est en premier l infra, en second les serveurs
Le pc sff de l utilisateur final c est rien
Et sur celui ci un ssd est souvent bien plus efficace qu avoir un i7 x86 pour les appli installé en local