Visual Studio : faut-il envisager une version 64 bits ?
Cela pourrait-il vraiment fournir des gains de performance ?

Le , par dourouc05

14PARTAGES

7  0 
Aimeriez-vous avoir une version 64 bits de Visual Studio ?
Visual Studio est l’environnement de développement intégré proposé par Microsoft. Il gère une pléiade de langages, historiquement des langages natifs comme C++, mais aussi toute la pile .Net avec C#, VB.Net et d’autres, y compris pour le Web. Il est souvent cité en référence comme environnement de développement. À l’origine payantes, les éditions Express sont apparues en 2005 ; nettement moins limitées, les éditions Community sont beaucoup plus récentes.

Cependant, l’environnement est aussi connu pour ne pas toujours être extrêmement réactif, notamment dans le cas de projets de grande ampleur ou avec des extensions. Suite à un tweet de Gunnar Skogsholm, le débat sur une version 64 bits de Visual Studio est relancé : ainsi, l’environnement ne serait plus limité à quatre gigaoctets de mémoire vive, il pourrait exploiter toute la mémoire des machines actuelles, ce qui pourrait aider en performance. D’ailleurs, une série d’environnements de développement y sont déjà passés, comme Eclipse ou Android Studio — ces deux-là ayant la particularité d’être écrits en Java et de dépendre d’une JVM, les efforts de portage en 64 bits sont donc très limités.

Des raisons techniques

Rico Mariani, un ancien développeur de Visual Studio, maintenant passé dans l’équipe de Microsoft Edge (le nouveau navigateur de Microsoft), indique cependant que passer au 64 bits n’apportera pas grand-chose à l’EDI, cela risque même plus probablement de lui causer d’autres problèmes de performance. En effet, du côté technique, ces 64 bits correspondent à la taille d’une adresse en mémoire (ce qui permet d’indexer beaucoup plus de mémoire vive qu’en 32 bits) ; cette transition doublerait donc la taille de tous les pointeurs, ce qui a des impacts sur l’alignement en mémoire des structures de données, sur la densité des données stockées et donc la localité.

De manière générale, le code sera plus lourd, l’application occupera plus de place en mémoire en 64 bits plutôt qu’en 32 bits (dans un facteur qui dépend fortement de l’application considérée). Par conséquent, les caches du processeur seront moins bien utilisés, puisqu’ils n’ont pas soudainement augmenté en taille ; les registres disponibles seront certes plus grands et plus nombreux, mais ce facteur n’a de réel impact que sur le code effectuant des traitements lourds (comme du calcul scientifique ou de l’analyse de données) plutôt que des interfaces graphiques. Cette migration en 64 bits ne se justifie donc que s’il est nécessaire d’utiliser plus de mémoire que la partie accessible en 32 bits.

Une autre justification est moins attendue : en 64 bits, une fuite de mémoire ne fera pas planter l’application rapidement, puisqu’elle pourra consommer toute la mémoire de l’ordinateur, le ralentir à l’extrême et le rendre complètement inutilisable. Ce genre de justification est encore plus valable pour un navigateur qui autorise des extensions.

Utiliser plus de mémoire est une erreur de conception, pour Rico Mariani

D’ailleurs, même si cette mémoire supplémentaire était utile, il y a d’autres options pour rester en 32 bits, notamment une représentation plus efficace des données en mémoire. Pour gagner en performance, cette solution est bien évidemment meilleure que d’exploiter plus de mémoire. L’idée est donc de prévoir son code pour que seule une partie de la mémoire requise doive résider en mémoire vive, c’est-à-dire stocker la plupart des données dans un fichier et s’assurer d’en avoir besoin très peu souvent.

En effet, pour qu’une application puisse se mettre à grande échelle, ce genre de techniques est souvent requis. Pour un client, l’approche est très positive : il est possible de faire bien plus avec moins de ressources. Par exemple, en 1989, même avec 640 ko de mémoire vive, il restait possible d’exploiter sans problème de performance une base de données de 24 Mo, simplement en gardant un cache de 12 ko de données intéressantes pour accélérer les opérations de recherche et de lecture. À l’heure d’aujourd’hui, les échelles monteraient plutôt à quelques téraoctets de données au moins à traiter, mais le principe reste d’application. Le conseil de Rico Mariani est de considérer les données comme une base de données relationnelle (SQL), puis de la charger par tranches en mémoire, au lieu d’exploiter des représentations plus naturelles pour un programmeur à base de pointeurs.

Cette migration n’est de toute façon pas encore utile

Ces considérations techniques éloignent le débat des points réellement importants pour une application : être agréable à utiliser. Utiliser telle ou telle technologie n’a aucun impact sur ce critère premier ; en réalité, utiliser aussi peu de technologies différentes est probablement une bonne chose. De même, utiliser plus de mémoire n’a pas d’impact direct sur l’utilisabilité : moins de mémoire pour la même expérience devrait être l’objectif. En d’autres termes, une migration en 64 bits n’a pas de sens pour l’utilisateur de Visual Studio.

De plus, elle coûte en temps de développement, qui pourrait être investi dans d’autres fonctionnalités. Notamment, les formats de fichiers binaires utilisent régulièrement des pointeurs, ce qui empêche une migration aisée entre 32 et 64 bits. Cette même évolution a longtemps été retardée par Firefox par manque de compatibilité avec un grand nombre de dépendances externes en 64 bits  : il est difficile de ne pas effectuer une migration complète, c’est-à-dire seulement les quelques parties qui en bénéficieraient.

Depuis 2008, Visual Studio permet la création d’extensions chargées en dehors du processus principal de l’EDI, c’est-à-dire dans un processus séparé, avec un espace mémoire séparé. Ces extensions peuvent être réalisées de diverses manières : par exemple, le cœur de Visual Studio est assez léger, beaucoup de fonctionnalités sont proposées en extensions (comme les solutions), dont un nombre grandissant est écrit en C#, avec une exécution dans une machine virtuelle. Il est aussi possible de compiler ces extensions en 64 bits si nécessaire… et le fait est que très peu d’extensions le font, parce que ce changement ne leur est pas utile. Par contre, Resharper C++, une extension de JetBrains pour Visual Studio, à l’origine du retour de cette controverse, ne profite pas de cette possibilité et a des difficultés à gérer de grandes quantités de code.

Et Rico Mariani de conclure en disant qu’avoir un système d’exploitation 64 bits est extrêmement utile — ce qui n’est pas le cas de la majorité des applications.

Et vous ?
Aimeriez-vous une version 64 bits de Visual Studio ? Pour quelles raisons ?
Qu'en pensez-vous en comparaison de la politique de l'App Store d'Apple, qui est de n'autoriser que des applications 64 bits, ou d'Office, qui conseille toujours d'utiliser la version 32 bits, à moins d'avoir des besoins spécifiques ?

Sources : Revisiting 64-bit-ness in Visual Studio and elsewhere, 64-bit Visual Studio — the « pro 64″ argument, Visual Studio: Why is there no 64 bit version? (yet).

Voir aussi

Forum EDI
Ce contenu a été publié dans C++ par dourouc05.

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Nerothos
Membre régulier https://www.developpez.com
Le 05/01/2016 à 10:55
Aimeriez-vous une version 64 bits de Visual Studio ? Pour quelles raisons ?
Oui, si cela a réellement un intérêt.

qu'en pensez-vous en comparaison de la politique de l'App Store d'Apple, qui est de n'autoriser que des applications 64 bits, ou d'Office, qui conseille toujours d'utiliser la version 32 bits, à moins d'avoir des besoins spécifiques ?
Si ces politiques sont orientées optimisations alors pourquoi forcément vouloir les contrer? À moins que l'enjeu du passage soit plus impactant que les performances uniquement, autant utiliser les versions recommandées.
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 05/01/2016 à 11:17
J'ai lu le billet de Rico Mariani il y a quelques jours, et ses arguments me semblent convaincants (d'autant plus qu'il est bien placé pour savoir de quoi il parle). Une version x64 n'apporterait pas grand-chose, et rendrait Visual Studio encore plus gourmand en mémoire. J'ai souvent 2 voire 3 instances de VS ouvertes sur de grosses solutions, et chacune occupe entre 500Mo et 1Go de RAM. Je n'ai aucune envie que ça prenne encore plus, surtout si ça n'améliore pas les perfs (et d'après le billet, ça pourrait au contraire rendre l'application plus lente...)
Avatar de 23JFK
Membre expérimenté https://www.developpez.com
Le 05/01/2016 à 13:38
Enfin! Je commençais à en avoir marre de cette fuite en avant des ingénieurs consistant à allouer des quantités astronomiques de mémoire de travail pour rien.
Avatar de bacelar
Expert éminent sénior https://www.developpez.com
Le 05/01/2016 à 14:43
de mémoire de travail pour rien.
C'est pas pour rien, c'est pour gagner du temps pour faire autre chose de plus valorisant que de l'économie de RAM qui ne vaut plus grand chose.
Avatar de 23JFK
Membre expérimenté https://www.developpez.com
Le 05/01/2016 à 15:30
Citation Envoyé par bacelar Voir le message
C'est pas pour rien, c'est pour gagner du temps pour faire autre chose de plus valorisant que de l'économie de RAM qui ne vaut plus grand chose.
Il s'agit là d'un idéal théorique qui ne résiste pas à la réalité qui est qu'une machine à toujours une quantité de RAM finie. La pratique montre qu'une allocation excessive de mémoire est généralement le symptôme d'un programme mal conçu et incidemment sous-performant, le cas extrême étant la suite de mémoire qui va inévitablement conduire à un crash plus ou moins conséquent du programme lui même, voir du système dans son intégralité.
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 05/01/2016 à 15:39
Citation Envoyé par 23JFK Voir le message
Il s'agit là d'un idéal théorique qui ne résiste pas à la réalité qui est qu'une machine à toujours une quantité de RAM finie. La pratique montre qu'une allocation excessive de mémoire est généralement le symptôme d'un programme mal conçu et incidemment sous-performant, le cas extrême étant la suite de mémoire qui va inévitablement conduire à un crash plus ou moins conséquent du programme lui même, voir du système dans son intégralité.
Après pour Visual studio, c'est pas non plus le genre de programme facile à optimiser ...

C'était le plus gros logiciel de Microsoft (déjà à l'époque de Vista en terme de ligne de code il faisait plus que Windows et office réunis).

Il sont entrain de tout décomplexifier/externaliser pour ensuite s'en débarrasser (ça arrivera pas surement pas avant plusieurs années).

Je pense que des projets comme VS code,etc sont des sortes de 'petits' tests afin de choisir un axe qui conviendra pour le futur.
Avatar de TiranusKBX
Expert confirmé https://www.developpez.com
Le 05/01/2016 à 17:34
Je pense que la version X64 seras intéressante le jours ou VS seras dégraissé/réécris
Avatar de Daniel Laügt
Futur Membre du Club https://www.developpez.com
Le 05/01/2016 à 21:33
Concernant le langage C++, on peut définir des fichiers .natvis ayant des règles de visualisation pour les types que nous créons, afin de facilement voir le contenu des variables en phase de débogage. Le format .natvis (xml) est souvent suffisant pour la plupart des types créés. Cependant pour des types plus compliqués, il est nécessaire d'utiliser le mot-clé LegacyAddin et d'écrire une dll afin d'afficher son contenu.

Par exemple, j'ai un type Money qui représente un floating point de très grande précision sans aucun problème d'arrondi (contrairement au type 'double' encodé en base 2 avec IEEE). Pour cela, je déclare:
Code : Sélectionner tout
1
2
3
<Type Name="Money"> 
    <DisplayString LegacyAddin="NatvisMoney.dll" Export="AddIn_Money"></DisplayString> 
</Type>
Je développe, compile, debug et teste tous mes programmes en 64 bits.
Le problème est que la visualisation dans le débugger fonctionne seulement si la dll (NatvisMoney.dll) est compilée en 32 bits.

Du coup, si un Visual Studio en 64 bits peut résoudre ce problème alors je dis youpi
Avatar de captaindidou
Inactif https://www.developpez.com
Le 06/01/2016 à 10:59
La version 64 bits d'un produit s'accompagne d'une légère perte de performance sur processeur intel. C'est ce que l'on constate. Est-ce toujours le cas avec la dernière génération de proc et d'os ?

La question à ce poser est : est-ce que VS a besoin de plus de 4 Go ou pas ?

Quoiqu'il en soit, la compilation en 64 bits et la requalification est une formalité dont j'ai connu l'expérience sur un système logiciel bien plus gros que VS : le système de contrôle mission d'une famille de satellites. Donc, pourquoi s'abstenir

De plus, elle coûte en temps de développement, qui pourrait être investi dans d’autres fonctionnalités. Notamment, les formats de fichiers binaires utilisent régulièrement des pointeurs, ce qui empêche une migration aisée entre 32 et 64 bits.
Des formats binaires qui stockeraient les valeurs de pointeurs ... ne peuvent être que des fichiers temporaires de session. De toute façon, ce serait une bien drôle d'idée pour le moins. C'est, donc, d'après moi, un prétexte qui ne reflète pas la réalité. C'est, à mon avis, invraisemblable.

en 64 bits, une fuite de mémoire ne fera pas planter l’application rapidement, puisqu’elle pourra consommer toute la mémoire de l’ordinateur, le ralentir à l’extrême et le rendre complètement inutilisable.
Affirmation qui mériterait d'être justifiée car le mode 64 bit ne se distingue du mode protégé que par l'abandon de la segmentation.

Or, les systèmes d'exploitation Windows, Linux ... à part OS/2 si ma mémoire est bonne exploitent un modèle flat du mode protégé. Autrement dit, un modèle où les processus partage un même segment, donc pas de séparation des processus par segmentation, la protection mémoire s'établissant au niveau des répertoires de pages.

La segmentation du mode protégé d'intel avec notamment ses 4 niveaux de privilège fait figure d'exception dans l'informatique. C'est pourquoi, ceux parmi les systèmes d'exploitation qui ont vocation à être multi-plateforme n'ont pas retenu son exploitation.

Donc, aucune différence entre le mode 32 bit et 64 bit. C'est encore d'après moi, une contre-vérité.
Avatar de pcdwarf
Membre éclairé https://www.developpez.com
Le 07/01/2016 à 11:31
Comme je travaille presque exclusivement sous linux, ça fait 6ans que je n'ai pas employé visualstudio et je débarque un peu.

Cependant. MS n'est toujours pas passé en 64 bits depuis tout ce temps ?
Et apparemment il y a des problèmes de portage ?
WTF !

Qu'il soit difficile (même très difficile) de porter des truc proche du hard comme des drivers, je peux comprendre.
Mais, visualstudio, c'est un soft qui travaille à haut niveau....
Il ne suffit pas de recompiler le truc pour la nouvelle architecture ???
<troll mode on>
===>>> C'est si mal fait que ça ?
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web