iOS 10.1 (re)part en guerre contre les applications 32 bits

iOS 10.1 (re)part en guerre contre les applications 32 bits

Elles ralentissent tout ces vilaines

Avatar de l'auteur
Vincent Hermann

Publié dans

Société numérique

07/10/2016 3 minutes
60

iOS 10.1 (re)part en guerre contre les applications 32 bits

iOS favorise les applications 64 bits depuis plusieurs années maintenant. Les développeurs ont eu même l’obligation de s’y mettre, contraints par l’App Store. Dans iOS 10.1, actuellement en bêta, Apple prévient d’ailleurs l’utilisateur qu’une application, si elle est en 32 bits, peut ralentir son appareil.

La poussée du 64 bits date initialement de l’arrivée de l’iPhone 5s, qui était alors le premier appareil du constructeur à proposer un SoC adapté. Dès 2013, Apple a donc demandé à ce que les nouveaux binaires contiennent ce qu’il fallait pour les deux architectures, même si l’obligation n’était pas encore là.

Hail to the 64 bits

Les choses se sont durcies dans le courant de l’année dernière. Le 1er février, Apple a imposé le 64 bits pour toute nouvelle application proposée sur l’App Store. Le 1er juin, ce fut au tour de toutes les mises à jour pour les applications existantes, ce qui réclamait dans certains cas une quantité non négligeable de travail. Apple ne demandait cependant pas à ce que le code soit totalement optimisé, ce qui d’ailleurs dans de nombreux cas n’aurait eu aucun sens. Le 64 bits ne provoque en effet pas une hausse magique des performances dans tous les domaines.

Mais que se passe-t-il pour les applications qui n’ont jamais été mises à jour depuis l’été 2015 ? Elles sont toujours en 32 bits, et Apple leur fait désormais la chasse. Pendant la bêta d’iOS 10, lancer une telle application avertissait qu’elle n’était pas optimisée pour iOS 10 et qu’elle pouvait affecter les performances générales.

Cette application « risque de ralentir votre iPhone »

Dans la bêta actuelle d'iOS 10.1 ; un message apparaît par exemple au lancement de Peggle Classic. Il indique que le jeu « risque de ralentir votre iPhone » et que le « développeur de cette app doit la mettre à jour pour améliorer la compatibilité ». La fiche du jeu dans l’App Store affiche d'ailleurs un message de l’éditeur : le jeu est compatible avec les versions 5.1.1 à 7.1 d’iOS. Pourtant, le lancer sur iOS 10 ou 10.1 ne pose pas de problème particulier. L’avertissement est d’ailleurs très vague, l’utilisateur ne sachant pas vraiment ce qui l’attend.

Pourquoi alors donner un tel avertissement aux joueurs ? Sans doute pour qu’ils fassent remonter des requêtes auprès de l’éditeur concerné. Et « l’alerte » survient à un moment opportun, Apple ayant prévenu le mois dernier qu’un grand ménage allait démarrer sur l’Apple Store.

peggle app store 64 bits iphone ios

Le ménage de l'App Store commence

Le 7 septembre, la firme a en effet commencé un processus d’analyse de toutes les applications, afin de vérifier si tous les critères sont remplis. Parmi ces derniers se trouve justement le 64 bits. Les développeurs avertis ont 30 jours pour proposer une mise à jour, sans quoi l’application sera supprimée, jusqu’à ce qu’une nouvelle version soit soumise à approbation. La vérification ayant commencé il y a un mois tout juste, les premiers retraits devraient donc commencer aujourd’hui.

Notez que cette obligation stricte du 64 bits et le retrait des vieilles applications 32 bits ne signifie pas pour autant que le 32 bits lui-même va disparaître. Les développeurs qui souhaitent viser des appareils un peu anciens comme l’iPhone 5 n’ont pas le choix : ils doivent continuer à proposer des binaires universels supportant les deux architectures. 

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Hail to the 64 bits

Cette application « risque de ralentir votre iPhone »

Le ménage de l'App Store commence

Fermer

Commentaires (60)


Si seulement Google pouvait faire pareil…


Ça ne sent pas très bon pour mon vénérable iPhone 5 et iOS 11 tout ça..

Dommage, il fait toujours le job et me convient très bien !


Du concret pour affirmer qu’une application 32bits ralentit le phone ?


c’est n’importe quoi car un os en 64 bite signigie juste que l’os est capable de suporter plus de 3.2 gigo de memouare vive pour le reste rien ne change sans etre obliger de passer par des processeurs 32 bits qui suportent le protocole pae comme sous windouse








sans sucre a écrit :



c’est n’importe quoi car un os en 64 bite signigie juste que l’os est capable de suporter plus de 3.2 gigo de memouare vive pour le reste rien ne change sans etre obliger de passer par des processeurs 32 bits qui suportent le protocole pae comme sous windouse





Apprends à écrire et apprends l’informatique pour la même occasion&nbsp;<img data-src=" />









sans sucre a écrit :



c’est n’importe quoi car un os en 64 bite signigie juste que l’os est capable de suporter plus de 3.2 gigo de memouare vive pour le reste rien ne change sans etre obliger de passer par des processeurs 32 bits qui suportent le protocole pae comme sous windouse





32 bits&nbsp;= 4 GiO d’espace d’adressage.

Sinon, ta rédaction est … particulière … &nbsp;



Si seulement Microsoft pouvait faire pareil…








pyro-700 a écrit :



Si seulement Microsoft pouvait faire pareil…







Ils ont tenté il y a une paire d’années et les éditeurs n’ont jamais suivis



On connait bien l’apport (et inconvénients) du 64bits sur les processeur x86, mais qu’en est-il des SoC ARM ?

Je ne pense pas qu’Apple pousse le 64bits pour qu’AngryBirds puisse consommer plein de mémoire :)



Sur x86 le 64bits apporte biensûr le support de davantage de mémoire, mais aussi des registres supplémentaires.

Il y a un bénéfice sur des applications particulières (calculs, toussa toussa…), mais point de miracle. Certaines applis 32bits sont même plus rapides.



Bref, qqun saurait-il nous dire si le 64bits ARM apporte quelque chose de concret, qui plus est sur un smartphone ou tablette ? Et pour pousser plus loin, les SoC de chez Apple ?


La raison d’être du “64 bits” n’a jamais été de rendre les programmes plus rapide mais de dépasser la limitation à 4Go de l’espace d’adressage.



Il est évident que le fait de doubler la taille des pointeurs et de certaines données ne fait pas gagner en performances.


Si seulement Next INpact pouvait mettre à jour l’application iOS ça serait sympa ! Impossible d’éditer un commentaire, logout automatique et intempestif après un certain temps… il est temps !



<img data-src=" />


Il est question ici d’applications, c’est à dire de programmes qui sont relativement légers. Comprenez que ces programmes sont loin, très loin, super loin, à des millions d’années lumières de notre Terre, d’avoir besoin d’exploiter 4 Go de mémoire vive, voire plus. Vous allez me rétorquer que des applications de plus en plus lourdes et demandant, de facto, de plus en plus de ressources en mémoire vive, ont fait leur apparition ces derniers temps. Je pense notamment aux jeux vidéos pour smartphones et tablettes numériques. Mais quelle est la proportion de gens qui les utilisent ? Elle doit être infime, à mon avis.




Ensuite, et j'avoue ne pas m'y connaître en programmation informatique et c'est donc une simple déduction que je fais, écrire un programme en 32 bits doit être plus facile que d'écrire un programme en 64 bits. A fortiori, cela facilite sa maintenance (les mises à jour).      






C'est en 2003 que le premier processeur 64 bits s'adressant au grand public sort. Il s'agit de l'Athlon 64, d'AMD. 13 ans se sont écoulés depuis sa sortie. Force est de constater que les programmes 32 bits rayonnent toujours, que cela soit pour les PC ou pour les smartphones/tablettes numériques. Du côté d'Apple, je ne me prononcerais pas, ne sachant ce qu'il en est. Si le 32 bits n'est pas mort, c'est qu'il y a bien une raison, voire même plusieurs... Je ne pense pas que les concepteurs de programmes utilisent toujours le 32 bits parce qu'ils y tiennent comme à la prunelle de leurs yeux.

Pure spéculation, mais Apple pourrait-il proposer dans un futur pas trop lointain un processeur 64bits uniquement ? Cela devrait faire baisser les coûts de fabrication de ces puces, ou au moins apporter un quelconque bénéfice dans je ne sais que domaine (conso ?).

Pour cela il faudrait une transition en douceur vers le tout-64bits, ce qui est visiblement en train de se passer. Et pour le coup ça ne serait pas déconnant.


Pourquoi ne pas utiliser la version mobile du site à la place ?








pyro-700 a écrit :



Si seulement Microsoft pouvait faire pareil…





Et pourquoi ?

Je maintiens/dev des applis 32 et 64 sous MS-DOS Windows 710.

S’ils arrêtent le 32, certaines applis sont mortes, hors VM.









sans sucre a écrit :



memouare windouse







<img data-src=" /><img data-src=" /><img data-src=" />



Depuis quand c’est nécessaire pour afficher un message anxiogène ?








Niktareum a écrit :



<img data-src=" /><img data-src=" /><img data-src=" />





Avant de voir ta réponse, j’avais un doute. Je pensais à une blague.



Mè en regardé le historia de without sucra je me suy dite quenon, çay pas zune putain de blaga.



Ce qui est certain, c’est que windouse a besoin de memouare pour mieux marchais.









grosbidule a écrit :



On connait bien l’apport (et inconvénients) du 64bits sur les processeur x86, mais qu’en est-il des SoC ARM ?



Je ne pense pas qu'Apple pousse le 64bits pour qu'AngryBirds puisse consommer plein de mémoire :)      






Sur x86 le 64bits apporte biensûr le support de davantage de mémoire, mais aussi des registres supplémentaires.      

Il y a un bénéfice sur des applications particulières (calculs, toussa toussa...), mais point de miracle. Certaines applis 32bits sont même plus rapides.






Bref, qqun saurait-il nous dire si le 64bits ARM apporte quelque chose de concret, qui plus est sur un smartphone ou tablette ? Et pour pousser plus loin, les SoC de chez Apple ?







Il y a aussi des registres supplémentaires sur ARMv8 comparé à ARMv7 et plus de trucs pour la vectorisation aussi il me semble donc mêmes avantages et inconvénients à passer au 64 bits sur ARM que sur x86.



Après concernant les SoC d’Apple, ils les designent eux-mêmes mais uniquement pour eux donc pas vraiment de documentation et de spécification détaillé publique. Mais ils présentent succinctement leur architecture et leur ajout par rapport aux autres SoC ARM plus classiques est qu’ils ont intégré un coprocesseur pour traiter les informations de tous les senseurs du device (et on sait bien qu’un circuit spécialisé sera toujours plus performant/économe (sauf si fait avec les pieds évidemment…) qu’un traitement fait logiciellement sur un processeur généraliste). Libérant donc le CPU principale de ces calculs mais surtout lui laissant plus de temps pour rester en sleep mode.



Tu serais pas motard toi?


Je pense qu’Apple aime l’uniformité dans son écosystème et doit chercher à se débarrasser du “legacy” qui est souvent coûteux en termes de maintenance.

Du côté des perfs, à mon avis c’est plus une question d’optimisation car le 32bits sur un OS 64bits implique quand même de porter des libs dédiées. Vouloir le dégager permet d’éviter de trimbaler la couche de compatibilité.



Ca sent le premier pas avant la suppression complète de la compatibilité d’ici quelques versions.




iOS 10.1 (re)part en guerre contre les applications 32 bits





C’est d’ailleurs pour cela que Apple a supprimé Dash(et le compte du développeur).



<img data-src=" />








pyro-700 a écrit :



Si seulement Microsoft pouvait faire pareil…







Ca va gueuler comme d’hab, quand leur message est basé sur du “concret”, par exemple l’utilisation de la batterie quand on est sur un navigateur, ça ne plait pas pour autant comme avec les recommandations pour edge quand chrome est lancé. <img data-src=" /><img data-src=" />



Et puis ce type d’avertissement basé sur des décisions principalement partiales (dif de perfs entre 32/64b pour Peegle???), il faut voir à ne pas en abuser.









kade a écrit :



Et pourquoi ?

Je maintiens/dev des applis 32 et 64 sous MS-DOS Windows 710.

S’ils arrêtent le 32, certaines applis sont mortes, hors VM.





Certains souhaitent la disparition de WOW64 pour réduire l’espace disque nécessaire au système.

Microsoft propose déjà pour les éditions Server Core une installation optionnelle de WOW64. Le faire aussi pour les éditions grand public résoudrait la question, en laissant le choix à l’utilisateur.



apple prépare clairrement un passage tout 64 bits et commence par bouter hors d’iOS le 32 bits.



quant à MS, s’il passe tout 64bitzs, les gens gueuleront parceque l’application de généalogie de tonton jackie ne marchera plus.



Sans compter les app professionnels.



MS devrait plutot lancer un ultimatum de 5 ans (on va dire) et virer de force le 32 bits au bout de cet ultimatum


<img data-src=" /> <img data-src=" /> <img data-src=" /> <img data-src=" /> <img data-src=" />



plus de WOW64, je signe direct !








vampire7 a écrit :



Certains souhaitent la disparition de WOW64 pour réduire l’espace disque nécessaire au système.

Microsoft propose déjà pour les éditions Server Core une installation optionnelle de WOW64. Le faire aussi pour les éditions grand public résoudrait la question, en laissant le choix à l’utilisateur.





Non mais OSEF de l’espace disque, honnêtement.

De toute façon je ne parle pas de mes configs perso, mais des infras entreprises. Des L4G anciens 32 bits font parfaitement le taf en faisant appel aux API/shell 32.

Après pour ce qui est “récent” OK, on dev en 64, c’est pas un PB. Je ne suis pas dans le JV mais l’info de gestion, mais quand même…




VisualStudio est en 32bit, à mon avis dans 3 ans ça y est tjrs …


Pourquoi ont-ils crée une application ? Force est de constater que la version mobile est mieux que l’application mais quand même !



<img data-src=" />








tifounon a écrit :



apple prépare clairrement un passage tout 64 bits et commence par bouter hors d’iOS le 32 bits.



quant à MS, s’il passe tout 64bitzs, les gens gueuleront parceque l’application de généalogie de tonton jackie ne marchera plus.



Sans compter les app professionnels.



MS devrait plutot lancer un ultimatum de 5 ans (on va dire) et virer de force le 32 bits au bout de cet ultimatum





A te lire, si, toutes plates-formes confondues, les programmes 32 bits restent encore majoritaires, c’est donc pour un souci de compatibilité. Je dois en conclure que beaucoup d’utilisateurs, particuliers comme professionnels, disposent encore de systèmes d’exploitation (Windows la plupart du temps) 32 bits.



Effectivement, un programme 64 bits ne peut pas fonctionner sur un OS 32 bits. L’inverse, par contre, est possible. Pourtant, sur PC, de plus en plus de particuliers ont une version de Windows en 64 bits. Certains (beaucoup ?) ne le savent même pas d’ailleurs et continuent de télécharger et d’installer les versions 32 bits de leurs programmes, quand les versions 64 bits sont proposées. Je ne vais pas leur en vouloir : tout le monde n’a pas mes connaissances même si il ne faut pas avoir fait Saint-Cyr pour le savoir.



Concernant les professionnels, plus long à évoluer que les particuliers compte tenu de l’investissement que demande le changement d’un parc informatique, il n’y a pas à être étonné qu’ils utilisent encore et toujours majoritairement le 32 bits.



Cependant, et je sais que cela grincer des dents quand je l’écris, Microsoft ne peut pas abandonner ceux qui ont toujours une architecture 32 bits. Cela explique pourquoi Windows 10 est proposé en version 32

bits. J’ai lu maintes fois que Windows 10 ne serait proposé qu’en version 64 bits, mais je savais pertinemment que cela ne serait pas le cas : cela serait contre-productif pour Microsoft. Quand aux créateurs de programmes, ils ne peuvent pas non plus décemment laisser tomber le 32 bits. Tant que les architectures 32 bits seront encore utilisées, que cela soit encore le cas dans 5, 10, 15, 20 ans ou au-delà, l’OS de Microsoft et les logiciels continueront à avoir leurs versions 32 bits.



Enfin, je dispose également d’un smartphone sous Android 6.0. Celui-ci est en version 32 bits. Si, demain, Google, dans son Play Store, impose aux concepteurs d’applications le 64 bits, je serais bien embêté… De plus, je rappelle que les mises à jour d’Android sont au bon vouloir des constructeurs. La plupart ne proposeront aucune mise à jour d’Android en version 64 bits, sous entendu que l’architecture du smartphone permet le support du 64 bits. Il faudra racheter un smartphone pour en profiter… Excusez-moi du peu, mais je serais donc baisé, comme tant d’autres. Et j’achèterais un stock supplémentaire de vaseline car certains créateurs d’applications ne se gêneront pas d’imposer aux utilisateurs de repasser à la caisse pour avoir leurs applications en version 64 bits. Ah parce que oui, vous me pardonnerez, mais j’ai acheté plusieurs applications.



N’oubliez pas que l’écosystème “Android” est bien plus complexe et fragmenté que l’écosystème “iOS”.









Romaindu83 a écrit :



Ensuite, et j’avoue ne pas m’y connaître en programmation informatique et c’est donc une simple déduction que je fais, écrire un programme en 32 bits doit être plus facile que d’écrire un programme en 64 bits. A fortiori, cela facilite sa maintenance (les mises à jour).





Ce n’est pas plus compliqué de produire du code 64 bits ou 32 bits. En tout cas en tant que développeur C#, je produis exactement le même code quelque soit le type de binaire. Ce qui change, c’est le “build” (la compilation) du binaire (sous VS, il suffit de définir l’architecture cible).









Mesc@lito a écrit :



Ce n’est pas plus compliqué de produire du code 64 bits ou 32 bits. En tout cas en tant que développeur C#, je produis exactement le même code quelque soit le type de binaire. Ce qui change, c’est le “build” (la compilation) du binaire (sous VS, il suffit de définir l’architecture cible).





Pour une appli Phone, ce qui doit être (un peu) plus compliqué c’est la packaging de l’appli. Je suppose compiler les deux versions,&nbsp; écrire un manifest, zipper le tout, faire le double de tests.



Même avec un langage plus bas niveau (C/C++), tu peux coder une appli qui compile sur toute plateforme (OS ou hardware)









fofo9012 a écrit :



Pour une appli Phone, ce qui doit être (un peu) plus compliqué c’est la packaging de l’appli. Je suppose compiler les deux versions, écrire un manifest, zipper le tout, faire le double de tests.







En fait sur iOS le process est automatisé: tu précises les architectures que tu veux pour ton programme/framework, tu lances le build et le logiciel d’édition (Xcode) fait toutes les manips nécessaires.



Toutes les architectures de l’appli sont mises dans un meme dossier et téléversées (j’aime ce mot) sur itunesconnect en attente de la demande de publication ou de testflight (mais oui, les tests doivent tourner pour les deux archi).







Mesc@lito a écrit :



Ce n’est pas plus compliqué de produire du code 64 bits ou 32 bits.







Quand t’as besoin de faire de l’assembleur pour accélérer un truc (genre un changement de colorspace pour une frame vidéo) ça devient vite chiant d’avoir deux archi.

Mais la plupart du temps, t’as effectivement pas besoin de penser à l’architecture pour laquelle tu es en train de construire en obj-C/swift.



Alors là, aucune idée, peut-être pour faire comme beaucoup de sites web et avoir une visibilité sur les appstores… et accessoirement augmenter le nombre d’apps (inutiles) dispos sur ceux-ci. J’dis ça en tant qu’utilisateur aigri de WP/WM <img data-src=" />








tifounon a écrit :



apple prépare clairrement un passage tout 64 bits et commence par bouter hors d’iOS le 32 bits.







Je pense pas qu’ils “commencent” par là. Ils ont déjà plus ou moins dégagé le 32 bits reliquat de l’époque Lion pour le hardware PC (et tu fais engueuler quand t’as une application du system preferences qui est en 32b), et ils ont fait quasiment la même chose en se débarassant des iPhones 4S et des anciens iPad (les derniers trucs armv7) pour iOS10.



Clairement, ils vont retirer l’iPhone 5 (dernier iPhone 32 bits) de iOS 11, et avec ce qui est expliqué dans la news il n’y aura plus d’appli non compatible 64 bits à partir de iOS 11.



Ca permettra peut-être de réduire le poids d’iOS, et surtout il n’y aura plus qu’une branche de code à maintenir.



Ensuite ils feront la même chose avec macOS je pense. Tout leur écosystème sera 64 bits. De l’homogénéité à la Apple en somme.



En parallèle je vois bien le MacBook 2017 ou 2018 remplacer son CPU Intel par un A11X ou A12X, quand on voit les perfs du A10 Fusion ça fait sens. Il sera encore plus simple de faire des applis iOS/macOS (ARM).

Sur ce MacBook, je ne vois que des avantages à passer sur ARM. Le CPU Intel est à la rue.



Dans quelques années le 32 bits aura complètement disparu du monde Apple.



Pour la watch la v1 était 32 bits, je ne sais pas ce qu’il en est de la v2.








Thanat0s a écrit :



En parallèle je vois bien le MacBook 2017 ou 2018 remplacer son CPU Intel par un A11X ou A12X, quand on voit les perfs du A10 Fusion ça fait sens. Il sera encore plus simple de faire des applis iOS/macOS (ARM).

Sur ce MacBook, je ne vois que des avantages à passer sur ARM. Le CPU Intel est à la rue.



Je suis pas convaincu que pour faire de la PAO par exemple, tu t’en sortes mieux, ou même aussi bien avec un ARM actuel<img data-src=" />



Bonne technique marketing pour accélérer le renouvellement des vieux iphone…


D’après les autres fabricants, c’est plus efficace de ne plus mettre à jour l’OS sur les modèles qui dépassent les 2-3 ans <img data-src=" />








Firefly’ a écrit :



VisualStudio est en 32bit, à mon avis dans 3 ans ça y est tjrs …





L’équipe en charge du dev de VisualStudio avait expliqué pourquoi passer en 64bits était contre-productif : pas plus rapide et conso mémoire augmentée, sachant que la prise en charge de “gros projets” (cad mettant à mal les limitations mémoire du 32bits) serait réglée dans une future version, dont on aperçoit les prémisses dans la dernière preview de VisualStudio (qui déporte des fonctionnalités gourmandes en RAM vers des process séparés).

Donc si VisualStudio est un jour porté en 64bits, ce ne sera pas pour des raisons techniques, mais sans doute à cause des commerciaux (plus y’a de bits…).

&nbsp;

Le 32bits sur PC ce ‘est pas un mal. Mais à lire certaines réactions on se croirait à l’époque du Megadrive, où l’on confondait nombre de bits avec puissance :p



En fait sur mobile il y a un petit intérêt au 64 bits plus important que la gestion de l’adressage mémoire.&nbsp;

Apple pousse le 64 bits car l’architecture étant légèrement différente il permet une économie d’énergie, surtout qu’Apple doit maintenant concentrer ses efforts sur le compilateur que pour les applications 64 bits et a du arrêter toutes améliorations pour la generation des binaires 32 bits.



Apres en dehors de ca, il n’y a pas d’autres intérêts au 64 bits qui fait meme que les applications consomme un peu plus de mémoire (selon le code l’augmentation de la consommation peux être non négligeable malgré le fait que l’application n’est pas besoin de pouvoir utiliser plus de 4 Go de RAM).



Et je ne crois pas que ca puisse impacter l’OS, ce message est tourne comme ca afin que les utilisateurs se plaignent aux développeurs qui ne suivent pas les recommandations qu’Apple leur soumet déjà par email. Les développeurs (y compris moi généralement), ne vont pas investir du temps de travail pour une tache n’ayant aucun impact sur le fonctionnement de l’application ou sa generation de revenues.


Imposer le 64-bits aux applications permet à Apple de ne plus avoir de couche de compatibilité pour applications 32-bits. Cette couche sert d’intermédiaire, et ralentit effectivement l’application, certes, de manière habituellement négligeable. Mais c’est aussi une couche qui réclame un effort supplémentaire de maintenance à Apple. Et, côté appareil, réclame aussi de l’espace de bande passante (lors des mises-à-jour) et de stockage (sur l’appareil).



Rappelons qu’Apple est passée à l’architecture exclusivement 64 bits pour ses ordinateurs voici plusieurs années. Et ceci a permis de réduire la taille de l’OS et d’en améliorer les performances. Et cela a coûté l’abandon des API les plus anciennes, et l’incompatibilité avec les applications basées dessus.&nbsp;Quant à Windows ou Linux, à part sur des plateformes embarquées, il est exceptionnel de trouver un processeur non compatible 64 bits. D’après l’enquête sur le matériel et les logiciels Steam de septembre 2016, moins de 10 % des joueurs disposent d’un OS 32-bits.



Pour en revenir au mobile et à iOS, rappelons que le principal reproche fait par les développeurs d’applications Android est la fragmentation du marché. Au contraire, iOS est apprécié pour sa cohérence. Il est donc logique et pertinent pour Apple de conserver cette homogénéité, voire de la renforcer.


Ah je sais bien hein, jamais eut de problème à cause de ça, mais c’était pour répondre à Tifounon, vs est aussi en wpf, donc on sait que la techno restera supporté un moment :p


Oulah, si Microsoft avait fait cela pour éradiquer les applis 32 bits les plus rependues sur sont système….. que d’histoires !

Blague à part, il est logique que chaque éditeur de systèmes souhaite simplifier les gestion des applis avec un seul jeu de micro code



&nbsp;


Rigole pas, me semble qu’on peut encore faire tourner des applications 16 bits sous Windows <img data-src=" />


Vrai mais Juste les systèmes 32 bits <img data-src=" />&nbsp;qui eux aussi sont en fin de vie…..

Microsoft avait même du réintégrer par&nbsp;défaut le lecteur de disquettes quand Apple supprime des jacks sans que personne ne bouge…..



&nbsp;








sr17 a écrit :



La raison d’être du “64 bits” n’a jamais été de rendre les programmes plus rapide mais de dépasser la limitation à 4Go de l’espace d’adressage.



Il est évident que le fait de doubler la taille des pointeurs et de certaines données ne fait pas gagner en performances.





Ce qui est bien c’est que même l’iPhone 7 Plus n’a “que” 3 Go de RAM… donc pour le moment l’intérêt du 64 bits sur iOS est purement marketing, à moins de miner du bitcoin sur son iPhone…









ndjpoye a écrit :



Je suis pas convaincu que pour faire de la PAO par exemple, tu t’en sortes mieux, ou même aussi bien avec un ARM actuel<img data-src=" />





Clairement !

J’aimerai bien voir la “gueule” de l’ARM en import de photos de dizaines de Mo depuis LightRoom ou Photoshop 64 bits pour rigoler un peu <img data-src=" /><img data-src=" />



Etre “en guerre contre les applications 32 bits” est purement marketing, à moins d’avoir grandement diminué la vitesse des processeurs (je n’y crois pas, et surtout le fait d’être passé de mono core en multi core, ce qui me fait rire)



<img data-src=" />


Oui mais quand tu fais un kernel, c’est plus facile si tu as beaucoup de bits de poids forts disponible dans les adresses pour séparer les divers espaces d’adressage (data/code user, data/code kernel, mémoire partagée et fichiers mappés, I/O), encore plus si tu veux jouer à ne pas toujours envoyer les mêmes espaces dans les même intervalles d’adresse.

Donc la limite de facilité pour le 32b est bien avant 4GB


32 ou 64 that is the question. Pour ma part, j’essaie d’installer les programmes en 64bits quand ils sont disponibles. Mais dans l’affaire, 2 problèmes sont posés.

Le 1er, quand un éditeur fait les 2, le programme d’installation t’installe d’office le x86 (32bits). Donc ballot pour lui d’avoir développé 2 versions et ne pas tester ton OS pour installer le bon.

Le 2eme, c’est quand tu as un programme en 32, le programme doit passer par un “convertisseur” donc perte de temps. En 1 cycle d’horloge, au lieu de traiter 1 instruction il doit faire 2 cycle pour traiter la même information.

La différence est flagrante avec libre office au lancement, vraiment plus rapide en 64 qu’en 32.

Voilà, mais le problème N°1 c’est l’installation de la version qui doit tester l’OS pour installer la bonne version.


Qué convertisseur ?

Les CPUs ARMv8 (64b) sont capables directement d’exécuter le code ARMv7 (32b), tout comme les cpus x86_64 sont capables de traiter directement d’exécuter le code x86 (implicitement: 32b).



Seule condition: Insérer au bon moment le changement de mode du processeur.



Dans le cas de Libre Office, et en supposant qu’il s’agisse d’un x86 sur x86_64, la différence de performance est fort probablement plutôt due à un avantage intrinsèque de la nouvelle archi. par rapport à l’ancienne:

Plus de registres, tout bon pour le compilateur qui gènère moins d’accès mémoire pour faire la même chose.



&nbsp;Ce n’est qu’ensuite qu’il faut se demander si la présence d’une masse d’appels systèmes dans le code déclencherait effectivement un tel nombre de changements de mode du CPU que la somme des délais en deviendrait perceptible.



Et in ultimo, la question de la taille mémoire adressable, parce que là on parle de logiciel de bureautique, pas de base de données (quoique…)


Non, c’est bien 3,2 Go d’adressables, 4 Go visibles ceci dit.


Oui, si ton Windows est en 32bits, sinon c’est impossible. J’ai pu installer et exécuter un vieil Access 2.0 (16bits) sur un Windows 7 32bits comme ça :p.








levhieu a écrit :



Seule condition: Insérer au bon moment le changement de mode du processeur.





Comme tu dis changement de mode donc perte de temps entre un OS qui tourne en tache de fond en x64 et un programme qui fait des aller retour en x32.

Tout en x64 bits, évite cela.

La barrière des 3,4Go, comment l’OS en x64 gère si tu as 8Go? Seul les 3,4Go sont accessibles pour les programmes en x32?



La perte de temps est toujours là, mais n’est perceptible que si les changements de contexte sont «trop» nombreux: caqs du programme qui effectue surtout des appels systèmes. Dans le cas d’une phase initiale (avec comme seul affichage un splash-screen optionnel), il est tout à fait possible qu’un programme soit en train de calculer sa cuisine interne sans trop d’interaction avec l’OS. Ça dépend du programme, donc selon les cas il y a ralentissement perceptible ou pas.



Sinon, effectivement un processus 32b qui tourne sur un OS 64b n’a pas accès à autant de mémoire virtuelle que les «natifs». Mais ce n’est pas grave, puisque justement il ne compte pas dessus.


Pour la mémoire, il faut bien distinguer mémoire virtuelle (dite VM) et mémoire physique (la RAM).



Les processus 32b ont accès à moins de VM que les processus 64b, mais l’OS envoie cette VM où ça lui chante en RAM (la chanson effective dépend de l’OS, bien sûr). Donc l’augmentation de la taille de la RAM peut bénéficier à tous les processus, dès lors que l’OS a les capacités d’en tenir compte.



D’ailleurs, ça fait longtemps que le PAE permet aux x86 d’atteindre plus de 4GB et que les OS, même en mode 32b, en tiennent compte.


Allez, soyons précischipoteurs:



Un mot de 32b permet d’exprimer 4G valeurs d’adresses.



&nbsp;Mais, en fonction:

&nbsp;1/ de limitations physiques du CPU

&nbsp;2/ de limitations physiques de la carte mère

&nbsp;3/ de limitations&nbsp; logicielles de l’OS

toutes ces valeurs de sont pas utilisables.

&nbsp;


Exact. C’est pour ça qu’on arrondit (pour faire simple) la valeur à 4 Go, mais en pratique, ce n’est jamais le cas.



Par contre, aucun intérêt à passer au 128bits car la mémoire adressable en 64bits est si grande que nous ne sommes pas prêts à atteindre la limite.


désole j’etais sous moble