Si le 64 bits a été adopté rapidement pour les applications dans le monde UNIX (Linux ou Mac OS X), ce n'est pas le cas sous Windows : les applications 32 bits sont encore très nombreuses, et le passage au 64 bits est souvent problématique.
Mozilla abandonne Firefox 64 bits
Le cas de Mozilla Firefox est emblématique : alors que Firefox existe en 64 bits sous Linux et Mac OS X, le navigateur reste en 32 bits sous Windows. Et la version 64 bits, en développement depuis des années, est abandonnée. Les raisons sont multiples, mais les deux principales sont une compatibilité très moyenne avec les plug-ins au niveau du 64 bits et une consommation mémoire plus élevée dans la version 64 bits du logiciel (ce qui est logique).
Rappelons qu'il n'existe que deux navigateurs 64 bits sous Windows : Internet Explorer et Opera. Chrome n'existe pas en x86-64 et Safari a visiblement été abandonné par Apple.
Ce n'est pas un problème pour les utilisateurs, ou tout du moins pas réellement : cette version 64 bits n'a jamais été « publique » et les avantages du 64 bits ne sont pas cruciaux avec un navigateur. De plus, l'absence de plug-ins est un problème dans un usage courant.
Rappelons tout de même que si Windows 8 existe encore en version 32 bits — certains processeurs actuels sont encore parfois 32 bits, comme les Atom —, la version 64 bits est tout de même la plus utilisée.
64 bits permettent d'adresser plus de 4Go de RAM mais ça ne doit pas vouloir dire pour autant qu'un soft va bouffer plus de RAM sous prétexte qu'il peut adresser toute la RAM physique dispo? Si ?
En tout cas FF s'est améliorée niveau gestion de la RAM mais c'est pas encore ça. Impossible de récupérer toute la RAM consommé par l'ouverture d'un nouvel onglet/site. 6, 7 onglets d'ouverts et 300Mo de bouffé.
C'est pas critique non plus j'ai 8Go à la maison et 4 au taf mais bon...
j'imagine plus de consommation due au adressage mémoire qui sont, comme tu l'a dis, plus long...
Quand tu stockes des données dans des registres 64 bits, ça peut prendre plus de place dans certains cas
perso je crois que je vais passe chrome parce que firefox ses temps si :
-non support du h264
-arret définitif du developement des version 64bit
-préfère se concentrer sur l'ajout de facebook dans le navigateur . . .
Je ne suis vraiment pas fan des mesures prises par la fondation Mozilla depuis quelques temps. Numéro de version chromiesques, dictature de la publication rapide. On enchaine des versions qui n'apporte pas grand chose ...
Pourquoi lâcher FF 64 bits maintenant alors que de plus en plus c'est la plateforme de référence ? Oui il y a des contraintes, mais il y a aussi des avantages ....
FireFox est un logiciel qui a réussi (= qui est devenu populaire) parce que les développeurs ont compris les attentes du grand public et s'efforcent de répondre à leurs besoins. Ce qui est assez rare dans le monde libre, où la plupart des logiciels sont essentiellement utilisés que par des passionnés de l'informatique.
T'es sur ? Parce qu'il me semblait qu'en 64 bits, un int était codé sur 4 octets (comme en 32 bits en fait) et un long (ou un long long) était codé sur 8 octets en 64 bits (alors qu'en 32 bits, un long est codé sur 4 octets et un long long sur 8 octets)
C'est tout à fait ça ! Je confirme
Enfin, avec GCC du moins (Win ou GNU/Linux)
ça doit surement varier d'un langage de programmation à l'autre. Mais pour le C au minimum j'en suis sur. Linux est coté en C, et la version 32 sera victime du bug de l'an 2032, la le temps en compté en secondes depuis le 1er janvier 1970 et est stocké dans un simple int et qu'en 2032 a un moment ça fera 2^32 secondes depuis cette date, et donc l'heure va se reseter.
La solution étant de passer en Linux 64 bits, ce qui donne beaucoup de temps de tranquillité.
Beaucoup de langages pas trop proche du matériels conservent des tailles de variables identiques entre les plateformes. En C/C++ c'est un petit casse tête pour les programmeurs ^^
Le fait qu'il ne marche pas avec certain scripts pour firefox a du bon, cela m'as permis d’éviter un hack d'un de mes comptes de jeu.
Absolument pas.
Je maintiens qu'en C/C++, avec GNU/GCC sous GNU/Linux (ou même Windows), un int compilé pour un 64bits fait bien 32 bits !!! C'est le long (long int) qui fait 32 en version 32bits et 64 en version 64 bits.
Le long long (long long int) fait 64 bits sur un host 32 ou 64 !
En revanche, sur certains compilos, le int fait 16 bits sur un host 16 bits et 32 sur un host 32.
Le test se fait en 3min chrono avec les printf/sizeof qui vont bien.
C'est pas pour rien qu'on utilise au final des typedef ou define de partout pour être sûr qu'on utilise bien des 16, 32 ou 64
Par contre le timestamp 32 bits t'es d'accord qui est sur 4 octets ? ça doit être une convention indéboulonnable ça.
Heureusement d'ailleurs ...
La surconsommation est due a la taille des pointeurs et au système de gestion de la mémoire, lui même lié a la taille des pointeurs. A partir du moment ou on passe en 64 teubs on a une consommation supplémentaire de mémoire c'est vrai pour toute les applis.
Je me rappelle quand tous les fans d'AMD disaient fièrement : "AMD est le premier à proposer des processeur 64 bits", je me disais comme un certain nombre de personne :"oui mais en fait ça sert à rien actuellement". On remarque que bien des années plus tard c'est encore vrai (a peu de chose près)
Bien sur il y a la limite des 4 Go sur 32 bits (sachant qu'on est au dela des 32 bits pour les adresses sur les processeur 32, voir doc intel & AMD) , mais bon vu le nombre de personne ayant un besoin réel de plus de 4Go de mémoire....
Oui... et non. Ce qui s'est démocratisé ce sont les architectures, mais l'immense majorité des logiciels n'ont aucun besoin d'un adressage 64 bits à isofonctionnalités. En plus, les OS tiennent compte des programmes compilés en 32 bits et les font fonctionner de manière totalement transparente; De fait: ne pas croire que le passage ) 64 bits -côté OS- pousse tout le monde à développer en 64 bits... surtout s'il y a à gérer la rétrocompatibilité logicielle sur les OS 32 bits.