ARM et Microsoft travaillent sur un Windows RT 64 bits

ARM et Microsoft travaillent sur un Windows RT 64 bits

Il manque la matière première : les puces

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

05/11/2012 4 minutes
59

ARM et Microsoft travaillent sur un Windows RT 64 bits

La société ARM, qui dessine l’architecture du même nom, a confirmé travailler avec Microsoft sur la mise au point d’un Windows RT 64 bits.

surface

 

La frontière des 4 Go de mémoire vive

Le fameux couple Wintel pourrait sérieusement être mis à mal durant les années qui viennent. L’architecture ARM, que l’on trouve au cœur de très nombreux smartphones et tablettes, a littéralement envahi le marché de la mobilité. Au point qu’un Windows classique lui est dédié, Windows RT, et que les tablettes l’exploitant sont plus nombreuses que leurs consoeurs Intel, en tout cas pour l’instant.

 

Les processeurs Intel gardent cependant un avantage de poids : la puissance. Inutile de comparer une puce ARM avec un Core i5 ou i7 (ou leurs équivalents chez AMD), les processeurs x86 sont capables de calculer bien plus rapidement grâce à des améliorations accumulées depuis des années. L’une d’entre elles, le 64 bits, est pourtant prévue pour les puces ARM dans le courant de l’année 2013, et Microsoft suit les travaux de près.

 

Un responsable de la société britannique, Ian Forsyth, a ainsi confirmé à PC World qu’un travail était bien en cours avec Microsoft pour la création d’une version 64 bits de Windows RT. Il s’agit d’une étape importante pour plusieurs raisons. D’une part, le 64 bits apporte un surplus de puissance de calcul dans la mesure un nombre plus important peut être traité au cours d’un même cycle. D’autre part, et c’est sans doute le plus important, le 64 bits casse la limite des 4 Go de mémoire vive pouvant être adressés.

Une bascule déjà en place pour le x86, en 2014 pour ARM

Un Windows RT 64 bits est donc logique puisque le 32 bits passera nécessairement la main de manière définitive pour le monde x86. On peut déjà observer que si une édition 32 bits de Windows 8 existe bien, elle ne sera surtout utilisée que dans les mises à jour des particuliers. En effet, tous les ordinateurs proposés jusqu’ici par les partenaires matériels sont équipées d’une édition 64 bits.

 

Pour autant, chez ARM, il faudra encore un peu de patience. La nouvelle version de l’architecture ARM en 64 bits ne sera finalisée que dans le courant de l’année prochaine. Les premières applications concrètes sont attendues pour 2014. On parle évidemment de smartphones et de tablettes, mais pas seulement : avec le 64 bits et la multiplication des cœurs d’exécution, le monde des serveurs se penchera plus sérieusement sur cette alternative. Une idée somme toute logique pour un parallélisme important, les puces ARM étant célèbres pour leur faible consommation et donc dégagement thermique. On sait également qu'AMD utilisera cette architecture pour certains de ses Opteron dès 2014 là encore.

 

Notez que même si ARM confirme travailler sur un Windows RT 64 bits, ce ne sera peut-être pas pour la génération en cours du système d'exploitation. En effet, s’il faut attendre 2014 pour les premières tablettes, il est possible que Microsoft veuille simplement attendre Windows 9. Il pourrait également s’agir de Blue dont les rumeurs indiquent qu’il s’agit d’une importante mise à jour pour Windows 8.

 

Enfin, qu’en est-il de la compatibilité logicielle ? Il est certain que les développeurs devront installer une mise à jour pour Visual Studio pour accéder à l’export « RT 64 bits » de leurs projets vers le Windows Store. Cependant, une tablette 64 bits pourra continuer à faire fonctionner l’ensemble des applications déjà disponibles dans la boutique. Les développeurs devront par contre réviser leur code pour tirer partie des nouvelles capacités des puces ARM en 2014.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

La frontière des 4 Go de mémoire vive

Fermer

Commentaires (59)


Cool, surtout que profitera aussi à Android/iOS - à condition pour Apple et Android de développer des versions 64bits de leurs OS bien sûr <img data-src=" />


Une question comme ça. Que vaudra un processeur ARM 64 bits par rapport à un processeur Intel en terme de performances / autonomie ?



Je veux dire, du côté d’Apple ces derniers temps on remarque que les processeurs ont pris de l’importance, et la firme a réaffirmé qu’elle avait de gros projets pour sa division semiconducteurs. Si on combine à ça les rumeurs sur un OSX ARM, et le fait qu’en 2014 le système sera arrivé au bout de sa numérotation (OSX 10.9 sortira surement en 2013…), on peut penser qu’en 2014 Apple fasse le grand saut ?


On ajoute à cela le travail d’AMD sur des puces ARM 64 bits pour serveur (Opteron) et en espérant une déclinaison grand public ça serait pas mal. Surtout que AMD a la capacité pour créer une alternative à Tegra à coût moindre.








John Shaft a écrit :



Cool, surtout que profitera aussi à Android/iOS - à condition pour Apple et Android de développer des versions 64bits de leurs OS bien sûr <img data-src=" />







Pour le kernel qu’utilise Android, pas de problème.



Pour les applications natives, si elles ne passent pas en 64 bits (honte au programmeur), ben l’ARM sait toujours exécuter le code 32.



Pour les applications java, c’est pas leur problème, c’est celui de la VM.



Ah ben voilà le nœud du portage: c’est la VM.

(au travail les gars)









John Shaft a écrit :



Cool, surtout que profitera aussi à Android/iOS - à condition pour Apple et Android de développer des versions 64bits de leurs OS bien sûr <img data-src=" />







Le contraire m’étonnerai. Ils sont tellement à ce tirer la bourre niveau stats que laisser le conçurent prendre de l’avance n’est pas envisageable.









levhieu a écrit :



(au travail les gars)







On serre les fesses et on espère que la transition soit plus rapide que sur les PC <img data-src=" />



” D’une part, le 64 bits apporte un surplus de puissance de calcul dans la mesure un nombre plus important peut être traité au cours d’un même cycle”



c’est pas faux. On connait quoi de cette architecture? il y a un nombre de registre plus grand? la taille des registre des doublées? (en générale, c’est la gestion des registres qui dans une architecture RISC fait la différence)



Perso, j’en ai rien à foutre de Windows RT sur ARM 64-bit (je me demande si linux/gcc ne sont pas déjà près depuis quelques mois, rien de plus normal), par contre, un petit topo sur les évolutions de cette architecture serait intéressant!








John Shaft a écrit :



Cool, surtout que profitera aussi à Android/iOS - à condition pour Apple et Android de développer des versions 64bits de leurs OS bien sûr <img data-src=" />





Bah pour des OS dérivés de Linux et BSD le passage au 64 bits devrait pas être trop lourd.





hopper28630 a écrit :



On ajoute à cela le travail d’AMD sur des puces ARM 64 bits pour serveur (Opteron) et en espérant une déclinaison grand public ça serait pas mal. Surtout que AMD a la capacité pour créer une alternative à Tegra à coût moindre.





Le propre d’AMD c’est surtout qu’il a racheté Seamicro qui faisait déjà dans les serveurs basse conso de ce type.

Après AMD a quand même du retard sur l’archi ARM vu qu’ils ont laché la mobilité y’a quelques années au niveau CPU et GPU ultra mobiles.









Aphelion a écrit :



Une question comme ça. Que vaudra un processeur ARM 64 bits par rapport à un processeur Intel en terme de performances / autonomie ?



Je veux dire, du côté d’Apple ces derniers temps on remarque que les processeurs ont pris de l’importance, et la firme a réaffirmé qu’elle avait de gros projets pour sa division semiconducteurs. Si on combine à ça les rumeurs sur un OSX ARM, et le fait qu’en 2014 le système sera arrivé au bout de sa numérotation (OSX 10.9 sortira surement en 2013…), on peut penser qu’en 2014 Apple fasse le grand saut ?







Personne n’a les arguments pour répondre:




  • L’architecture x86 est désavantagée par sa complexité intrinsèque qui nécessite plus de blocs hardware pour interpreter le flux d’instructions

  • Mais Intel a la meilleure technologiue de fonderie.



    Alors…









levhieu a écrit :



Personne n’a les arguments pour répondre:




  • L’architecture x86 est désavantagée par sa complexité intrinsèque qui nécessite plus de blocs hardware pour interpreter le flux d’instructions

  • Mais Intel a la meilleure technologiue de fonderie.



    Alors…





    et un budget R&D équivalent voir supérieur au CA annuel de certains de ces plus gros concurents aussi, ça aide bien. <img data-src=" />









knos a écrit :



Le contraire m’étonnerai. Ils sont tellement à ce tirer la bourre niveau stats que laisser le conçurent prendre de l’avance n’est pas envisageable.





Le prochain noyau Linux supportera cette architecture. Et le travail a été fait par les ingénieurs d’ARM directement. Du coup ça va laisser le temps a Android de préparer le reste de son OS pour supporter le 64bits . En deux ans ça doit etre largement faisable.







Aphelion a écrit :



Une question comme ça. Que vaudra un processeur ARM 64 bits par rapport à un processeur Intel en terme de performances / autonomie ?





Pour donner un ordre d’idée un proc ARM doit arriver au niveau d’un processeur ATOM niveau puissance, voir un peu mieux avec les dernières générations.

Niveau conso je pense qu’ARM est devant, c’est un de leur gros avantage sur Intel.









the_Grim_Reaper a écrit :



Bah pour des OS dérivés de Linux et BSD le passage au 64 bits devrait pas être trop lourd.







iOS j’sais pas, mais Android, c’est clair que le passage au x64 devrait être rapide quand on voit tout ce qu’ils ont pris de Linux <img data-src=" />



C’est du bon ! On commence enfin à avoir des architectures concurrentes en proco avec la montée en puissance des ARM. Depuis que Motorola a raté la montée en fréquence pendant la première moitié des années 2000 avec ses Power PC, ça nous manquait, une architecture alternative à l’omniprésence des x86 qui tienne la route !



Le tout x86 aurait-il vécu ? A suivre…








TheDidouille a écrit :



“ D’une part, le 64 bits apporte un surplus de puissance de calcul dans la mesure un nombre plus important peut être traité au cours d’un même cycle”



c’est pas faux. On connait quoi de cette architecture? il y a un nombre de registre plus grand? la taille des registre des doublées? (en générale, c’est la gestion des registres qui dans une architecture RISC fait la différence)



Perso, j’en ai rien à foutre de Windows RT sur ARM 64-bit (je me demande si linux/gcc ne sont pas déjà près depuis quelques mois, rien de plus normal), par contre, un petit topo sur les évolutions de cette architecture serait intéressant!







«31 General Purpose Registers accessible at all times»

et un registre zero.

Tous en 64 bits





On peut déjà observer que si une édition 32 bits de Windows 8 existe bien, elle ne sera surtout utilisée que dans les mises à jour des particuliers. En effet, tous les ordinateurs proposés jusqu’ici par les partenaires matériels sont équipées d’une édition 64 bits.



Il me semble que cela est faux : l’Atom Clover Trail ne supporte que le 32-bit, donc Windows 8 32-bit est de la partie sur toutes les tablettes Atom (qui de toute façon n’ont pas plus de 2 Go de RAM à l’heure actuelle).








John Shaft a écrit :



iOS j’sais pas, mais Android, c’est clair que le passage au x64 devrait être rapide quand on voit tout ce qu’ils ont pris de Linux <img data-src=" />





Bah OSX et iOS sont des dérivés de BSD.

OSX est déjà 64 bits donc ils ont fait une bonne partie du taf déjà chez Apple.



Après, le plus gros produit Apple à pour le moment 1Go de RAM en produit Mobile, ils ont encore de la marge <img data-src=" />

C’est pas comme Google pour lequel Android doit gérer 40 style de mobiles différents, chez Apple la liste est courte, ils essayent donc d’optimisé au plus juste.

je dis essayent parce que bon, les sorties de MAJ d’os chez eux sont pire que chez MS depuis 2-3 ans.









seb2411 a écrit :



Pour donner un ordre d’idée un proc ARM doit arriver au niveau d’un processeur ATOM niveau puissance, voir un peu mieux avec les dernières générations.

Niveau conso je pense qu’ARM est devant, c’est un de leur gros avantage sur Intel.







Ouais…Niveau performances, ce ne serait pas vraiment à la hauteur des puces Intel, mais niveau consommation d’énergie, ce serait bien mieux. Idéal donc pour un PC portable comme le Macbook Air.









Commentaire_supprime a écrit :



C’est du bon ! On commence enfin à avoir des architectures concurrentes en proco avec la montée en puissance des ARM. Depuis que Motorola a raté la montée en fréquence pendant la première moitié des années 2000 avec ses Power PC, ça nous manquait, une architecture alternative à l’omniprésence des x86 qui tienne la route !



Le tout x86 aurait-il vécu ? A suivre…





Y’a une alternative au X86 pour le 64 bits, mais comment dire, l’IA64 a eu du plomb dans l’aile avec les avancées x64 de l’IA32.

Au final les Itanium d’Intel pargent énormément avec les Xéon : socket, quad channel, …



Après pour ARM vs x86 y’a aussi une différrence, sur ARM beaucoup de calculs sont fait en soft alors que fait en hard sur du x86.

Plus ARM complexifie pour offrir de la performance, plus ça va consommer et ils se rapprocherons a terme du x86, en tous cas pour les version serveur c’est une certitude, pour les mobile ce sera plus long comme évolution, faudra voir comment ARM et Intel s’en tirent.





Pr. Thibault a écrit :



Il me semble que cela est faux : l’Atom Clover Trail ne supporte que le 32-bit, donc Windows 8 32-bit est de la partie sur toutes les tablettes Atom (qui de toute façon n’ont pas plus de 2 Go de RAM à l’heure actuelle).





Les nouveaux ATOM sont 64 bit il me semble, surtout qu’Intel en prévois pour des petits serveurs pour concurencer ARM justement.









seb2411 a écrit :



Pour donner un ordre d’idée un proc ARM doit arriver au niveau d’un processeur ATOM niveau puissance, voir un peu mieux avec les dernières générations.

Niveau conso je pense qu’ARM est devant, c’est un de leur gros avantage sur Intel.





Beaucoup d’affirmations qui ne reposent visiblement sur pas grand chose : personne n’a encore pu faire de bench objectif sur l’Atom Clover Trail puisque aucune machine équipée de ce CPU n’est actuellement en vente…



D’après les benchs d’Intel (pas ce qu’il y a de plus objectif donc) l’Atom Clover Trail dual-core est légèrement plus puissant que les CPU ARM quad-core les plus puissants. En ce qui concerne l’autonomie là encore il faudra vérifier, mais l’autonomie annoncée par les constructeurs pour les tablettes Atom est similaire à l’autonomie des tablettes ARM, pour des tablettes d’épaisseur et de poids très similaires. Reste à voir les prix, sur ce point les tablettes Atom sont globalement plus chères que les tablettes ARM, mais les prix de lancement de W8 ne sont pas très significatifs, attendons que tout cela se tasse, et on peut noter que Acer propose déjà une tablette Atom à 499€, soit le prix des tablettes Windows 8 ARM les moins chères.



On verra comment évolue Windows, mais à l’heure actuelle je pense que les logiciels desktop x86 ne sont pas là de disparaître au profit des apps Metro, donc pour l’instant Intel conserve un argument de poids avec son Atom compte tenu du nombre important de logiciels Windows qui ne peuvent pas tourner sur ARM.





D’autre part, et c’est sans doute le plus important, le 64 bits casse la limite des 4 Go de mémoire vive pouvant être adressés.



un windows RT a-t-il vraiment besoin de plus de 4Go de ram?








Pr. Thibault a écrit :



Beaucoup d’affirmations qui ne reposent visiblement sur pas grand chose : personne n’a encore pu faire de bench objectif sur l’Atom Clover Trail puisque aucune machine équipée de ce CPU n’est actuellement en vente…





Qui te parle de Clover Trail ?? <img data-src=" />



Sinon dans ce qu’on connait tu peux voir quelques tests ici, ca reste du phoronix (mais c’est déjà mieux que de reprendre la pub d’intel) et par forcement les dernières générations, mais au final on retombe bien sur des performances semblables.

http://www.phoronix.com/scan.php?page=article&item=calxeda_ecx1000_atom&…



http://www.phoronix.com/scan.php?page=article&item=gentoo_arm_x32&num=1









Pr. Thibault a écrit :



Il me semble que cela est faux : l’Atom Clover Trail ne supporte que le 32-bit, donc Windows 8 32-bit est de la partie sur toutes les tablettes Atom (qui de toute façon n’ont pas plus de 2 Go de RAM à l’heure actuelle).







Voilà pourquoi je parle d’ordinateurs <img data-src=" />









psikobare a écrit :



un windows RT a-t-il vraiment besoin de plus de 4Go de ram?







Quand je vois que pour certaines applications sur téléphone (Android), il y a des soucis de performance avec comme facteur limitant: la RAM de 2Go …









the_Grim_Reaper a écrit :





Après pour ARM vs x86 y’a aussi une différrence, sur ARM beaucoup de calculs sont fait en soft alors que fait en hard sur du x86.









J’aimerais bien savoir ce que signifie cette phrase









psikobare a écrit :



un windows RT a-t-il vraiment besoin de plus de 4Go de ram?





à une époque on disait : a-t-on vraiment besoin d’un disque dur de plus de 20Go ?









the_Grim_Reaper a écrit :



Les nouveaux ATOM sont 64 bit il me semble, surtout qu’Intel en prévois pour des petits serveurs pour concurencer ARM justement.





J’ai un ION de 1ère génération dans mon HTPC, avec un atom 330, 64 bits inside.



Mais effectivement y’a eu des Atom 32 bits y’a 3 ans.









levhieu a écrit :



«31 General Purpose Registers accessible at all times»

et un registre zero.

Tous en 64 bits







il suffisait de le dire! “les opérations sur les double et les long (long long chez ms) seront plus rapide” si c’est la seule différence, on est encore capable de comprendre.



Maintenant, dire que les perfo seront meilleurs parce qu’on fait plus vite des calcules sur les double et les long, dans la vie de tous les jours, en doublant la taille des pointeurs mémoire, c’est une autre histoire.









levhieu a écrit :



Quand je vois que pour certaines applications sur téléphone (Android), il y a des soucis de performance avec comme facteur limitant: la RAM de 2Go …







j’en connais pas des applications android qui demandent tant de RAM… tu as une source?









levhieu a écrit :



J’aimerais bien savoir ce que signifie cette phrase





Neon est un jeu d’instruction optionnel chez ARM par exemple.

Dans le monde x86 tu as les jeux d’isntruction MMX, SSE, AVX, x87, …



Chaque jeu d’instruction nécessite des transistors, qui dit plus de transistor dit augmentation du dégagement termique dans certaines conditions mais traitements plus rapide de certaines taches.

Pour faire donc simple, ARM n’a que peut de jeu d’instruction cablés en dur, du coup, faible dégagement thermique mais perf en retrait sur certaines taches.

A contrario, x86 dégagement thermique plus important mais tachés réalisées plus vites.

La ARM va rajouter un jeu d’instruction pour gérer le 64bit en dur, donc dégagement thermique en hausse <img data-src=" />





levhieu a écrit :



Quand je vois que pour certaines applications sur téléphone (Android), il y a des soucis de performance avec comme facteur limitant: la RAM de 2Go …





Mauvais codage des appli / VM Java ? <img data-src=" />





JCLB a écrit :



J’ai un ION de 1ère génération dans mon HTPC, avec un atom 330, 64 bits inside.



Mais effectivement y’a eu des Atom 32 bits y’a 3 ans.





Bien pour ça que je parle des nouveaux.

Sinon on peu aussi reparler des processeurs 8 bits et 16 bits hein <img data-src=" />









levhieu a écrit :



Personne n’a les arguments pour répondre:




  • L’architecture x86 est désavantagée par sa complexité intrinsèque qui nécessite plus de blocs hardware pour interpreter le flux d’instructions





    argument à double tranchant, et formulation bizarre.. en x86 plus d’instructions sont géres nativement par le processeur qu’avec ARM. Ca c’est objectif. Ensuite ARM dit qu’Intel perd le plus souvent de l’énergie à faire tourner des blocs inutiles (décodage d’instructions pas souvent utilisées), tandis qu’Intel dit que ça leur permet de gagner en perf. Les deux affirmations sont commerciales, on peut trouver des contre-exemples (Medfield qui ne consomme pas plus que les ARM équivalents, le nouveau Samsung A15 est plus rapide que les dual-core Atom équivalents par exemple)









FrenchPig a écrit :



à une époque on disait : a-t-on vraiment besoin d’un disque dur de plus de 20Go ?





ouai, c’est cool, on peut balancer des tas de généralités comme ça



concrètement, à quoi ça va aider 68 Go de ram sur un tablette arm?





levhieu a écrit :



Quand je vois que pour certaines applications sur téléphone (Android), il y a des soucis de performance avec comme facteur limitant: la RAM de 2Go …





ouai, mais là on parle de machine java, consommer de la ram, c’est un peu le cœur de métier









levhieu a écrit :



Quand je vois que pour certaines applications sur téléphone (Android), il y a des soucis de performance avec comme facteur limitant: la RAM de 2Go …





il ne doit pas y en avoir beaucoup.. Tu as des sources ?

ou alors sur tablette, avec les nouvelles résolutions en 2560, ça prend forcément de la place.









psikobare a écrit :



ouai, c’est cool, on peut balancer des tas de généralités comme ça



concrètement, à quoi ça va aider 68 Go de ram sur un tablette arm?



ouai, mais là on parle de machine java, consommer de la ram, c’est un peu le cœur de métier









Il t’as pourtant donné la bonne réponse, il n’y a pas longtemps on disait que 8 Go sur un pc ne servaient à rien, on disait que le full HD ne servait à rien, on disait que 1 To de disque dur ne se remplirait jamais etc etc etc



Donc oui bientôt 4 Go de ram et plus seront indispensable sur tablette mais clairement pas pour tout de suite. Mais c’est de cela qu’on parle ici préparer l’avenir.









Pr. Thibault a écrit :



Beaucoup d’affirmations qui ne reposent visiblement sur pas grand chose : personne n’a encore pu faire de bench objectif sur l’Atom Clover Trail puisque aucune machine équipée de ce CPU n’est actuellement en vente…



D’après les benchs d’Intel (pas ce qu’il y a de plus objectif donc) l’Atom Clover Trail dual-core est légèrement plus puissant que les CPU ARM quad-core les plus puissants. En ce qui concerne l’autonomie là encore il faudra vérifier, mais l’autonomie annoncée par les constructeurs pour les tablettes Atom est similaire à l’autonomie des tablettes ARM, pour des tablettes d’épaisseur et de poids très similaires. Reste à voir les prix, sur ce point les tablettes Atom sont globalement plus chères que les tablettes ARM, mais les prix de lancement de W8 ne sont pas très significatifs, attendons que tout cela se tasse, et on peut noter que Acer propose déjà une tablette Atom à 499€, soit le prix des tablettes Windows 8 ARM les moins chères.



On verra comment évolue Windows, mais à l’heure actuelle je pense que les logiciels desktop x86 ne sont pas là de disparaître au profit des apps Metro, donc pour l’instant Intel conserve un argument de poids avec son Atom compte tenu du nombre important de logiciels Windows qui ne peuvent pas tourner sur ARM.





pas mal de benchs disponibles maintenant, notamment chez phoronix ou anandtech.

En gros,

dual core A9 &lt; quad core A9 =&lt; dual core A9’ (Apple A6,..) &lt; Atom dual Core &lt; dual core A15

je fais vite :-)

Dans le bas de gamme, Intel n’a plus d’avantage de performance, consommation ou prix, c’est un peu la rançon d’avoir une architecture qui n’a pas évolué depuis 4-5 ans.. (Atom)









psikobare a écrit :



ouai, c’est cool, on peut balancer des tas de généralités comme ça



concrètement, à quoi ça va aider 68 Go de ram sur un tablette arm?



ouai, mais là on parle de machine java, consommer de la ram, c’est un peu le cœur de métier





au hasard, avec la nouvelle mode du 2560x1600 sur du 10”, pour gérer les images ça peut aider <img data-src=" />









brokensoul a écrit :



pas mal de benchs disponibles maintenant, notamment chez phoronix ou anandtech.

En gros,

dual core A9 &lt; quad core A9 =&lt; dual core A9’ (Apple A6,..) &lt; Atom dual Core &lt; dual core A15

je fais vite :-)

Dans le bas de gamme, Intel n’a plus d’avantage de performance, consommation ou prix, c’est un peu la rançon d’avoir une architecture qui n’a pas évolué depuis 4-5 ans.. (Atom)





Tu as des tests avec le A15 vs Atom ? Je suis curieux de voir









Earnur a écrit :



Il t’as pourtant donné la bonne réponse, il n’y a pas longtemps on disait que 8 Go sur un pc ne servaient à rien





je le dit toujours



ça ne sert que dans des cas spécifique, des grosses applis pro, pas le genre de truc que tu va mettre sur une tablette





jb18v a écrit :



au hasard, avec la nouvelle mode du 2560x1600 sur du 10”, pour gérer les images ça peut aider <img data-src=" />





çàd? tu vas pas faire de la retouche d’image sur une tablette, et t’as pas besoin de 30Go de ram pour afficher du quadHD, d’autant que pour le coup, c’est préférablement géré par la ram du GPU



En ce qui concerne la taille mémoire, l’important je pense n’est pas de dire de toute façon plus de 2Go est inutile, tu trouvera toujours une appli qui pourra le nécessiter ou en tirer avantage, l’important c’est de faire que ce soit possible.









levhieu a écrit :



Quand je vois que pour certaines applications sur téléphone (Android), il y a des soucis de performance avec comme facteur limitant: la RAM de 2Go …











the_Grim_Reaper a écrit :





Mauvais codage des appli / VM Java ? <img data-src=" />



[quote:4331205:brokensoul]

il ne doit pas y en avoir beaucoup.. Tu as des sources ?

ou alors sur tablette, avec les nouvelles résolutions en 2560, ça prend forcément de la place.







J’aurais pas dû dire applications mais utilisations.

Bien sûr ce n’est pas une seule application qui pose problème.

Mais c’est l’utilisation conjointe de plusieurs applications dans quelques cas que je ne peux pas me permettre de décrire.



NB: Android s’en sort bien, si on oublie les performances.

Manque de RAM =&gt; oom killer

Applications bien faites =&gt; pas de perte de données

L’nconvénient pour le client qui passe d’une application à une autre, c’est la succession de redémarrages.









psikobare a écrit :



je le dit toujours



ça ne sert que dans des cas spécifique, des grosses applis pro, pas le genre de truc que tu va mettre sur une tablette



çàd? tu vas pas faire de la retouche d’image sur une tablette, et t’as pas besoin de 30Go de ram pour afficher du quadHD, d’autant que pour le coup, c’est préférablement géré par la ram du GPU







Je ne suis pas tout a fait d’accord .



Sans utiliser de grosses applis pro, le simple fait d’avoir plus de 4Go est super pratiquer pour faire tourner une VM a l’aise, et dans ce cas 16 ou 8 Go sont bien pratique a avoir.









levhieu a écrit :



Une question parce que j’avais pas compris la phrase.











the_Grim_Reaper a écrit :



Neon est un jeu d’instruction optionnel chez ARM par exemple.

Dans le monde x86 tu as les jeux d’isntruction MMX, SSE, AVX, x87, …









OK, ça me suffit pour comprendre ce que tu voulais dire

<img data-src=" />









TheDidouille a écrit :



il suffisait de le dire! “les opérations sur les double et les long (long long chez ms) seront plus rapide” si c’est la seule différence, on est encore capable de comprendre.



Maintenant, dire que les perfo seront meilleurs parce qu’on fait plus vite des calcules sur les double et les long, dans la vie de tous les jours, en doublant la taille des pointeurs mémoire, c’est une autre histoire.







Non, il y a plein d’autres changements, mais je répondais à une question précise dans ta phrase (nombre et taille des registres)









levhieu a écrit :



complexité intrinsèque









brokensoul a écrit :



argument à double tranchant, et formulation bizarre.. en x86 plus d’instructions sont géres nativement par le processeur qu’avec ARM. Ca c’est objectif. Ensuite ARM dit qu’Intel perd le plus souvent de l’énergie à faire tourner des blocs inutiles (décodage d’instructions pas souvent utilisées), tandis qu’Intel dit que ça leur permet de gagner en perf. Les deux affirmations sont commerciales, on peut trouver des contre-exemples (Medfield qui ne consomme pas plus que les ARM équivalents, le nouveau Samsung A15 est plus rapide que les dual-core Atom équivalents par exemple)







La complexité dont je parle, c’est celle du format des instructions x86.

Avant même de commencer à exécuter une instructions, le CPU doit:




  • Chercher les préfixes

  • Trouver la taille de l’instruction.

    Tout ça pour en pratique tomber le plus souvent sur les mêmes cas.



    Après, en 32 bits le peu de registres entrainait des aller-retrour avec le cache en plus grand nombre que sur un ARM (à condition que le compilateur pour ce dernier ne soit pas à la ramasse, ce qui n’est pas toujours évident).

    Normalement ça c’est du passé en x86-64 (toujours la même réserve sur le compilateur).



    Donc de la consommation en plus, mais comme c’est sur un CPU fabriqué dans les meilleures fonderies, on ne connait pas le résultat final tant qu’on n’a pas mesuré.









FelX a écrit :



Je ne suis pas tout a fait d’accord .



Sans utiliser de grosses applis pro, le simple fait d’avoir plus de 4Go est super pratiquer pour faire tourner une VM a l’aise, et dans ce cas 16 ou 8 Go sont bien pratique a avoir.





de toute façon tout ce que je voulais pointer, c’est que vincent nous vend la suppression de la limite de ram comme la grosse raison pour avoir de l’ARM 64bit



ça me semble juste très prématuré









psikobare a écrit :



de toute façon tout ce que je voulais pointer, c’est que vincent nous vend la suppression de la limite de ram comme la grosse raison pour avoir de l’ARM 64bit



ça me semble juste très prématuré





prématuré je suis pas sur, rien que dans le monde des serveurs ils commencent a en parler pour un horizon pas si lointain d’un an ou deux il me semble, et pour un serveur, 4Go de RAM c’est …. minuscule je trouve dans le cas ou il gère une grosse base de donnée, un serveur web etc…









levhieu a écrit :



J’aurais pas dû dire applications mais utilisations.

Bien sûr ce n’est pas une seule application qui pose problème.

Mais c’est l’utilisation conjointe de plusieurs applications dans quelques cas que je ne peux pas me permettre de décrire.



NB: Android s’en sort bien, si on oublie les performances.

Manque de RAM =&gt; oom killer

Applications bien faites =&gt; pas de perte de données

L’nconvénient pour le client qui passe d’une application à une autre, c’est la succession de redémarrages.





Toujours utiliser le bon mot, des fois c’est dangereux de ce tromper <img data-src=" />



Pas trouvé oom killer sur android, ca existe bien sous linux par contre.





FelX a écrit :



Je ne suis pas tout a fait d’accord .



Sans utiliser de grosses applis pro, le simple fait d’avoir plus de 4Go est super pratiquer pour faire tourner une VM a l’aise, et dans ce cas 16 ou 8 Go sont bien pratique a avoir.





Tu connais beaucoup de monde pou qui utiliser des VM n’est pas une utilisation Pro ?

désolé, mais la c’était trop facile <img data-src=" />





levhieu a écrit :



OK, ça me suffit pour comprendre ce que tu voulais dire

<img data-src=" />





<img data-src=" />

J’ai préféré développé au cas zouuuu <img data-src=" />





FelX a écrit :



prématuré je suis pas sur, rien que dans le monde des serveurs ils commencent a en parler pour un horizon pas si lointain d’un an ou deux il me semble, et pour un serveur, 4Go de RAM c’est …. minuscule je trouve dans le cas ou il gère une grosse base de donnée, un serveur web etc…





Heu, ne pas oublié que les serveur ARM sont dans des fermes avec des lames hein, dans un premier temps ça peut suffire cette limite.









the_Grim_Reaper a écrit :



Tu connais beaucoup de monde pou qui utiliser des VM n’est pas une utilisation Pro ?

désolé, mais la c’était trop facile <img data-src=" />







Ok, la VM c’est pas courant chez le perso lambda, mais bon il y a quand même pas mal de geeks qui s’amusent avec des VM chez eux, sinon pour un particulier, je pense comme ça au gens qui s’amusent a lancer pleins d’applis en même temps (et j’en connais pas mal :p ), style office+ browser+lecteur média etc, et au bout d’un moment 2go c’est vite rempli. 4Go ça va encore, mais pour combien de temps? Ok il y a du swap au besoin, mais niveau perf….









FelX a écrit :



Ok, la VM c’est pas courant chez le perso lambda, mais bon il y a quand même pas mal de geeks qui s’amusent avec des VM chez eux, sinon pour un particulier, je pense comme ça au gens qui s’amusent a lancer pleins d’applis en même temps (et j’en connais pas mal :p ), style office+ browser+lecteur média etc, et au bout d’un moment 2go c’est vite rempli. 4Go ça va encore, mais pour combien de temps? Ok il y a du swap au besoin, mais niveau perf….





Bah ouai… <img data-src=" />

Heu pour lancer un browser office (pas toute la suite de toutes façons, et un lecteur média avec 2Go sans virus ça fonctionne très bien.

Le problème c’est pas la RAM c’est l’utilisation qui en est fait (fuites mémoire des navigateurs, viros, trojan, et autres malwear), les films en FHD sur un écran HDready, etc…









the_Grim_Reaper a écrit :





Pas trouvé oom killer sur android, ca existe bien sous linux par contre.









Ben y’en a un aussi sur android, pas sûr qu’il s’appelle comme ça.



L’idée de base d’android c’est:




  1. On garde le processus même quand l’application passe en background

    Comme ça, si l’utilisateur revient dessus le tél. est réactif

  2. En cas de ressource insuffisante, on virera quand même du monde,

    ça fera perdre du temps en cas de redémarrage,

    mais une application bien écrite doit tenir compte de cette possibilité









levhieu a écrit :



La complexité dont je parle, c’est celle du format des instructions x86.

Avant même de commencer à exécuter une instructions, le CPU doit:




  • Chercher les préfixes

  • Trouver la taille de l’instruction.

    Tout ça pour en pratique tomber le plus souvent sur les mêmes cas.



    Après, en 32 bits le peu de registres entrainait des aller-retrour avec le cache en plus grand nombre que sur un ARM (à condition que le compilateur pour ce dernier ne soit pas à la ramasse, ce qui n’est pas toujours évident).

    Normalement ça c’est du passé en x86-64 (toujours la même réserve sur le compilateur).



    Donc de la consommation en plus, mais comme c’est sur un CPU fabriqué dans les meilleures fonderies, on ne connait pas le résultat final tant qu’on n’a pas mesuré.





    D’accord sur le début, pas sur la fin : je ne vois pas pourquoi plus d’insctructions = forcément plus de consommation, pas de lien logique (sinon on aurait dû rester à un microproc à 10 instructions, tu remarqueras que personne ne le fait…).

    Plus d’instructions, ça peut aussi vouloir dire moins de consommation si le compilateur sait taper sur les bonnes, il faut ensuite choisir le curseur. Rajouter un bloc qui traite en natif certaines opérations typiques de cryptographie pour un processeur qui en fera des caisses, plutôt que de les casser en plein de sous-unités (=cycles d’horloges en plus pour faire la même chose), ça peut facilement être rentable énergétiquement, pour prendre un contre-exemple facile à ton commentaire.



    Les architectures RISC (dont fait partie ARM) ont initalement parié sur un nombre réduit d’instructions (le R de Risc…), en considérant que le x86 en avait trop pour un usage courant, ce qui ne les empêche pas d’en rajouter à chaque nouvelle itération, à la Intel (donc plus d’instructions != plus de consommation.., ou en tous les cas pas pour tout le monde)









brokensoul a écrit :



D’accord sur le début, pas sur la fin : je ne vois pas pourquoi plus d’insctructions = forcément plus de consommation, pas de lien logique (sinon on aurait dû rester à un microproc à 10 instructions, tu remarqueras que personne ne le fait…).

Plus d’instructions, ça peut aussi vouloir dire moins de consommation si le compilateur sait taper sur les bonnes, il faut ensuite choisir le curseur. Rajouter un bloc qui traite en natif certaines opérations typiques de cryptographie pour un processeur qui en fera des caisses, plutôt que de les casser en plein de sous-unités (=cycles d’horloges en plus pour faire la même chose), ça peut facilement être rentable énergétiquement, pour prendre un contre-exemple facile à ton commentaire.



Les architectures RISC (dont fait partie ARM) ont initalement parié sur un nombre réduit d’instructions (le R de Risc…), en considérant que le x86 en avait trop pour un usage courant, ce qui ne les empêche pas d’en rajouter à chaque nouvelle itération, à la Intel (donc plus d’instructions != plus de consommation.., ou en tous les cas pas pour tout le monde)







Mais où j’ai dit «plus d’instructions» ?



Je ne place pas dans le débat RISC/CISC en nombre d’instructions reconnues, je signale que le jeux d’instructions x86 (du fait de la compatibilité avec un passé lointain) impose qu’un certains nombre d’opérations soient réalisées par le HW avant même de s’attaquer au cœur du travail de processeur qui est l’exécution d’une instruction.









Pr. Thibault a écrit :



Il me semble que cela est faux : l’Atom Clover Trail ne supporte que le 32-bit, donc Windows 8 32-bit est de la partie sur toutes les tablettes Atom (qui de toute façon n’ont pas plus de 2 Go de RAM à l’heure actuelle).





Pour être plus clair : Clover Trail supporte le x86_64, c’est juste que Windows 8 64 ne supporte pas Clover Trail (ref).









Pr. Thibault a écrit :



Beaucoup d’affirmations qui ne reposent visiblement sur pas grand chose : personne n’a encore pu faire de bench objectif sur l’Atom Clover Trail puisque aucune machine équipée de ce CPU n’est actuellement en vente…



D’après les benchs d’Intel (pas ce qu’il y a de plus objectif donc) l’Atom Clover Trail dual-core est légèrement plus puissant que les CPU ARM quad-core les plus puissants.



Oui, il va falloir attendre parce qu’Intel est très connu pour foirer ses benchmarks comparatifs (foirer étant le mot gentil pour truander).



Sinon il existe déjà un point de comparaison de l’A9 et de Swift vs Medield 2 GHz.

A6 vs Medfield 2GHz

Cortex-A9 vs Medfield 2GHz

Ca vaut ce que ça vaut, mais à mon sens ça donne un indice sur ce que vaut le coeur Atom du Clover Trail : poubelle.









Vincent_H a écrit :



Voilà pourquoi je parle d’ordinateurs <img data-src=" />





Ouais après qu’est ce qu’un ordinateur ? ^^ Un Asus Vivo Tab ou un Samsung Smart PC avec leur dock-clavier capables de faire tourner les logiciels x86 ne sont-ils pas des ordis ? ;) Même pour les tablettes RT, Ballmer parle de “PC” du fait qu’elles sont équipées d’Office et qu’on puisse leur ajouter un clavier.







the_Grim_Reaper a écrit :



Les nouveaux ATOM sont 64 bit il me semble, surtout qu’Intel en prévois pour des petits serveurs pour concurencer ARM justement.





D’après ce que j’ai lu ils supportent effectivement le 64-bit mais comme les drivers pour le mode Always Connected (nouveau power state de Windows 8) ne sont dispo que pour Windows 32-bit le CPU est référencé par Intel sur son site que comme supportant le 32-bit et les constructeurs utilisant cet Atom Clover Trail n’utilisent pour le moment que Windows 8 32-bit.



Source : anandtech “Connected standby is only currently supported by 32-bit Windows 8, so although Clovertrail supports x86-64 the platform will launch as 32-bit only”









Pr. Thibault a écrit :



D’après ce que j’ai lu ils supportent effectivement le 64-bit mais comme les drivers pour le mode Always Connected (nouveau power state de Windows 8) ne sont dispo que pour Windows 32-bit le CPU est référencé par Intel sur son site que comme supportant le 32-bit et les constructeurs utilisant cet Atom Clover Trail n’utilisent pour le moment que Windows 8 32-bit.





Marrant ça, je suis quasi sûr qu’il y a quelques jours le site d’Intel disait 64-bit pour le Z2760. Soit j’ai des hallu, soit ils ont changé ça.



Mais je doute du coup de ce que raconte Anand, parce qu’en général sur ARK c’est correct. Et sympa la limite à 2 Go de RAM, toujours fans de la segmentation chez Intel <img data-src=" />



(Page Intel Z2760)









ldesnogu a écrit :



Oui, il va falloir attendre parce qu’Intel est très connu pour foirer ses benchmarks comparatifs (foirer étant le mot gentil pour truander).



Sinon il existe déjà un point de comparaison de l’A9 et de Swift vs Medield 2 GHz.

A6 vs Medfield 2GHz

Cortex-A9 vs Medfield 2GHz

Ca vaut ce que ça vaut, mais à mon sens ça donne un indice sur ce que vaut le coeur Atom du Clover Trail : poubelle.







Tu n’as pas du utiliser un Medfield pour dire cela.









Pr. Thibault a écrit :



D’après ce que j’ai lu ils supportent effectivement le 64-bit mais comme les drivers pour le mode Always Connected (nouveau power state de Windows 8) ne sont dispo que pour Windows 32-bit le CPU est référencé par Intel sur son site que comme supportant le 32-bit et les constructeurs utilisant cet Atom Clover Trail n’utilisent pour le moment que Windows 8 32-bit.



Source : anandtech “Connected standby is only currently supported by 32-bit Windows 8, so although Clovertrail supports x86-64 the platform will launch as 32-bit only”





Ce qui n’enlève rien au fait que le CPU est 64bits, même si les l’OS et le drivers qui va bien pour une fonction particulière ne l’utilisent pas.

De toutes façons Intel se bougera le jour où ce type de machines aura besoin de plus de 4Go de mémoire volatile, donc ils ont encore 1 ou 2 ans sans problème.









Skeeder a écrit :



Tu n’as pas du utiliser un Medfield pour dire cela.





Non et c’est vrai que tout le monde en dit du bien. Mais moi je parle de perfs brutes, c’est ce qui m’interesse, avis perso en somme et motive par mon boulot :)









ldesnogu a écrit :



Non et c’est vrai que tout le monde en dit du bien. Mais moi je parle de perfs brutes, c’est ce qui m’interesse, avis perso en somme et motive par mon boulot :)







J’imagine, mais force est de constater que sur des Benchmarks un peu moins “perf brute”, le Medfield s’en sort très très bien, surtout sous ICS. Mais on avait déjà eu cette discution.