Kriska a écrit :



Oui tu vas pouvoir allouer plus de RAM et gérer donc plus d’onglet avec du flash ou autre.

Mais ça c’est la théorie, en pratique le soft va être plus lent car tous le code n’a pas besoin d’être en 64 bits (ex: un compteur du nombre d’onglets se contentera très bien du 32 bits. De plus, un process peut se forker par onglet et là encore, à moins d’utiliser 4G de RAM pour afficher une page web, il ne devrait pas y avoir de soucis.

 

Donc contrairement à ce qui a été dit au dessus, la plupart des développeurs compétents ne recommandent pas nécessairement le 64 bits pour toutes les applications (cf Visual Studio dernièrement), le 64 bits est surtout intéressant pour les systèmes. Donc à moins de réécrire ou de revalider plusieurs milliers de lignes de code pour passer seulement ce qu’il faut en 64 bits, le 32 bits restera toujours moins risquer et marchera très bien.







Hum, tu as déjà programmé pour une architecture 64 bits ? Déjà rien que pouvoir utiliser 4 registres pour les passages de paramètres de fonctions/méthodes au lieu de passer par la pile permet pas mal d’optimisations, ensuite tous les CPU x86_64 supportent le SSE2 ce qui permet d’optimiser encore plus les programmes au lieu de les compiler pour Pentium 2… voire 386 si on veut que ça passe vraiment partout (quitte à sacrifier des optimisations).



Ensuite ce dont tu parles est la place que va prendre un entier en mémoire, effectivement un entier 64 bits prend le double d’un entier 32 bits, c’est surprenant non ? :p Par contre, qu’est-ce qui t’obliges à utiliser des entiers 64 bits ? Tu peux très bien utiliser des entiers 8, 16 ou 32 bits en 64 bits. De plus, en 32 bits un entier 64 bits pourra être lu plus lentement qu’un entier 64 bits (ça dépend des optimisations du compilo), par contre en 64 bits les deux seront lus aussi rapidement.



Pour info, je suis un programmeur C++ et je compile tous mes programmes en 64 bits depuis au moins 2010. C’est vraiment pas la mer à boire de porter du code 32 bits en 64 bits, il suffit juste de prendre des bonnes habitudes (exemple : ne pas caster de pointeur dans un entier 32 bits…).

Kriska a écrit :



Pour info je suis un développeur kernel et système embarqués donc je connaîs pas trop mal la manière dont marche un compilo et justement, par défaut la plupart des dev utilisent int mavariable; en C/C++, hors le mot clé int ne garantis en rien la taille utilisée. Selon les architectures ça peut être un 32 ou un 64 bits voir un 16 bits sur les proc spécialisés.

Porter mes propres programmes de 32 vers 64 bits n’est pas la mort en effet mais qu’en est-il des projets sur lesquels je travaille et qui font plusieurs millions de lignes de codes.

Donc on est bien d’accords si la taille des variables étaient controllés comme en embarqué et qu’un minimum de best practices étaient utilisés sur les casts notamment et les alignements de structure par rapport au ligne de cache, que le code était bien modulaire pour faire une migration progressive, il n’y aurait pas de soucis mais prends un bon gros projet open source au pif et regarde la qualité du code. Les codes propriétaires étant souvent (mais pas toujours) encore pire.



 Pour info on peut faire du 32 bits et utiliser des optimations sans rester en 386, le SSE2 et 3 ayant été introduit dans la génération des pentium 4 donc il ne faut pas mélanger deux choses bien distinctes.







Pour ma part, dans pas mal de projets, soit on utilise les types standards uint32_t, uint64_t, int64_t, etc… soit des redéfinitions de ces types avec un autre nom mais pour être sûr qu’on connaisse la taille de cette variable surtout lorsque les données doivent être sérialisées.



Pour les optimisations, il est en effet possible d’utiliser certains jeux d’instructions conditionnellement à l’exécution (bon, par contre, faut passer par de l’ASM :p).



Sinon pour le portage de 32 à 64, je pense que je peux te dire que ce n’est pas tant la mort que ça :) Je bosse sur le MMORPG open-source Ryzom et je me suis chargé du portage en 64 bits et il y a effectivement plusieurs millions de lignes de code :https://bitbucket.org/ryzom/ryzomcore/commits/all



Le code du jeu a été libéré en 2010, il ne tournait que sous Windows en 32 bits, je me suis occupé du port Linux et 64 bits (Linux et Windows).