Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Visual Studio en 64 bits ?

Le , par dourouc05

19PARTAGES

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 Médinoc
Expert éminent sénior https://www.developpez.com
Le 06/06/2016 à 10:22
Apparemment, parce que bien que le billet sur le blog soit vieux, la réponse officielle de Microsoft sur UserVoice ne date que de quatre jours.
6  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 07/01/2016 à 18:06
Citation Envoyé par pcdwarf Voir le message
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 !
J'aime bien les gens qui commentent sans avoir lu la news
5  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 06/06/2016 à 11:24
Précisons que la chaîne de build (compilo, linker...) de Microsoft existe bien en version 64 bits depuis des années. C'est seulement l'IDE (front end graphique à MSBuild) qui est toujours en 32 bits.
4  0 
Avatar de bacelar
Expert éminent sénior https://www.developpez.com
Le 07/01/2016 à 12:06
@captaindidou et @pcdwarf, vous êtes des cadors.
Moi, ce genre de migration, cela n'a jamais été une formalité, jamais.
Je conçois que le développement critique sur satellites implique un cahier des charges, des outils, des spécifications, des méthodes, des librairies homologuées qui réduisent énormément l’occurrence des problèmes de migration, encore heureux (bien qu'avoir travail sur un système de firewall pour réseaux satellitaire militaire m'a montré qu'il faut pas être super-confiant).

Mais ici, on n'est loin, très loin de ce type de développement, avec du code hérité de Windows du début des années 80.

Une refonte, c'est pas gratuit, c'est pas de l'OpenSource avec des bénévole.
Et il faut donc faire un bilan avantage-inconvénient de la migration.

Tous les arguments sont, pour moi, valide.

Il n'y pas de changement de modèle mémoire, c'est toujours du flat, mais clairement, il faut bien plus de temps/mémoire pour arriver à remplir un espace d'adressage ~64 bit qu'un espace d'adressage 31bits (le 32ème, c'est réservé aux Kernel en mode standard).
La densité d'information est plus faible en 64bits qu'en 32bits, c'est "mécanique".
3  0 
Avatar de pcdwarf
Membre éclairé https://www.developpez.com
Le 07/01/2016 à 13:01
@bacelar
Je travaille essentiellement sur de l'embarqué, donc du code où les tailles de variables sont importantes, j'en fait beaucoup...
Simplement, je ne vois pas pourquoi une application haut niveau serait si impactée.
Soit il y a du typage à taille fixe du genre uint32_t et le changement d'architecture n'a pas d'influence.
Soit c'est des types variables genre "int" et "long" et dans ce cas, le passage de 32 à 64 a peu d'effet de bords (alors que dans le sens inverse, y'a quand même des risques de débordement)
Et pour ce qui est des tailles d'allocation, normalement, on emploie sizeof() et pas des constantes. (Mais je reconnais que des fois... hum...hum... ok....)

Par ailleurs, on parle de Microsoft là... et d'une évolution sur plusieurs années...
C'est pas une PME qui ne disposerait pas des ressources pour faire ce genre de portage.
Et puis pourquoi retarder... De toute façon ils finiront par y passer...

L'argument performance, par contre, ok, c'est (plus ou moins) recevable.
Mais bon... c'est pas non plus une grosse dégradation...
Et ca fait des années que tout le monde accepte des logiciels de plus en plus lourds sans même être surpris...
3  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 08/01/2016 à 17:17
Salut,

A vrai dire, je crois qu'il y a vraiment d'autres choses bien plus importantes à faire avant d'essayer de passer en 64 bits.

Après tout, la "version" d'un EDI ne fait que fournir les bases avec lesquelles l'EDI travaille et n'a aucun effet sur ses principaux éléments constitutifs (compilateur, éditeur de liens et débuggueur en tête) : si l'EDI est en 32 bits, mais que le compilateur est capable de fournir une version 64bits -- et surtout que le débuggeur sait travailler avec cette version -- hé bien soit: ce sera tout ce qui importe

Par contre, plutôt que de partir du principe que "bah, maintenant, on dispose de 32/64 Gb de RAM sur n'importe quel système récent", je crois qu'il y a énormément de travail à faire pour que l'EDI soit en mesure de ne pas "nécessiter plus de RAM que besoin".

Une fois que le dégraissage aura correctement été effectué pour que l'EDI (dans son ensemble, y compris les extensions) n'utilise que "le moins de mémoire possible", ou, si microsoft décide une jour (mais ce n'est surement pas pour demain, à mon sens) de ne plus autoriser que l'utilisation d'exécutables 64 bits sur les architectures 64 bits, alors, il sera peut être (plus que) temps d'envisager de faire passer visual studio sur 64 bits.

Entre temps, si certains concurrent ont pu faire des choix différents, c'est essentiellement grâce au nombre de gens suceptibles de participer à l'évolution (grâce à des licences plus permissives)... Hé bien, tans mieux pour eux
3  0 
Avatar de ChristianRoberge
Membre habitué https://www.developpez.com
Le 09/01/2016 à 15:26
J'utilise Visual Studio depuis ses débuts. Et de puis des années mes applications ("scientifiques" sont compilées en 64 bits... VS a évolué beaucoup depuis ses débuts et la dernière monture a encore fait de grands bonds en fonctionnalités. Mais aussi VS a encore des retards sur bien des fonctionnalités. Je crois qu'il est "préférable complète et augmente encore les fonctionnalités mais cela ne fera, hélas, que de retarder un version 64 bits qui aurait du être fait depuis des lustres. Est-ce que cela signifie que VS mourra en 32 bits et sera remplacé par un autre produit plus moderne et mieux conçu? Les prochaines années nous fourniront la réponse.
3  0 
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.
2  0 
Avatar de seb.49
Membre habitué https://www.developpez.com
Le 07/01/2016 à 14:24
rien que pour l'EDIT AND CONTINUE oui

2  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 08/01/2016 à 13:47
Citation Envoyé par pcdwarf Voir le message
@tomlev.
pris d'un doute, je viens de la relire,
et je trouve ta critique un peu courte.
tu peux affiner ?
Mon message a été édité pour retirer une partie de la citation, mais pas la bonne... J'ai modifié pour inclure la bonne partie de ton message.

L'article (et les billets de blog mentionnés) expliquent très bien pourquoi Visual Studio n'est pas passé en 64 bits. Et ce n'est pas un problème de portage, c'est juste que ce n'est pas pertinent, parce qu'un programme 64 bits est généralement plus lourd et plus lent par rapport à un programme 32 bits qui fait la même chose. Or VS est déjà bien assez lourd et lent comme ça...
2  0