Se connecter avec
S'enregistrer | Connectez-vous

Mozilla tue la version Windows 64 bits de Firefox

Par - Source: TheNextWeb | B 25 commentaires

FirefoxFirefox

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.

Afficher 25 commentaires.
Cette page n'accepte plus de commentaires
  • k4sh44 , 22 novembre 2012 14:00
    Pourquoi est-ce logique que la consommation du logiciel soit plus importante si le soft est 64 bits ?
    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...
  • delphi_jb , 22 novembre 2012 14:03
    k4sh44Pourquoi est-ce logique que la consommation du logiciel soit plus importante si le soft est 64 bits ?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...
  • snoopy_69 , 22 novembre 2012 14:20
    Un registre 64 bits prend la place de deux registres 32 bits. D'où un overhead de près de 100%. CQFD
  • dandu , 22 novembre 2012 14:34
    k4sh44Pourquoi est-ce logique que la consommation du logiciel soit plus importante si le soft est 64 bits ?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...


    Quand tu stockes des données dans des registres 64 bits, ça peut prendre plus de place dans certains cas
  • lainiwaku , 22 novembre 2012 14:40
    le fait que la version 64bit est plus lente, c'est surtout du fait qu'ils préfèrent travailler sur l'intégration de facebook plutot que l'optimisation du code pour 64bit

    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 . . .
  • adanorm2000 , 22 novembre 2012 14:44
    Concrètement, pour du C/C++, sur une archi x86, un Int (un chiffre entier positif ou négatif) est stocké sur 32bits, c'est a dire 4 octets. En 64 bits c'est 64bits justement, et donc 8 octets. Par contre ça n'affecte pas les types de caractères etc ...

    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 ....
  • Big Monstro , 22 novembre 2012 15:02
    @ lainiwaku > Même si je ne suis pas du tout un adepte de Facebook (loin de là !), je comprend le point de vue de Mozilla : une intégration de Facebook dans le navigateur apporte un bénéfice concret à beaucoup plus d'internautes qu'une version 64-bit de leur navigateur.

    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.
  • Yannick G , 22 novembre 2012 15:10
    Citation :
    Concrètement, pour du C/C++, sur une archi x86, un Int (un chiffre entier positif ou négatif) est stocké sur 32bits, c'est a dire 4 octets. En 64 bits c'est 64bits justement, et donc 8 octets. Par contre ça n'affecte pas les types de caractères etc ...


    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) :??: 
  • lolomatic , 22 novembre 2012 15:17
    Yannick GT'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)
  • adanorm2000 , 22 novembre 2012 15:22
    @Yannick G

    ç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 ^^
  • adanorm2000 , 22 novembre 2012 15:23
    Erratum, bug de l'an 2038
  • Robert Luisant , 22 novembre 2012 15:26
    J'utilise Waterfox et j'en suis très satifsfait. Je le trouve plus nerveux sur l'affichage des pages. Sans utiliser trop de plugin juste pour la navigation et le stream, ça patate, bien que sa consommation de ram soit élevée.

    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.
  • graal , 22 novembre 2012 15:30
    D'ici à 2038 ils ont le temps de mettre à jour leur type de variable ^^
  • Big Monstro , 22 novembre 2012 15:36
    @ graal > Windows 32-bit n'est pas affecté par ce problème de date. Rien ne t'empêches de définir l'horloge à une année beaucoup plus tardive sur un poste Windows XP 32-bit, le format de date n'impose pas une limitation à 2038.
  • lolomatic , 22 novembre 2012 15:39
    adanorm2000@Yannick Gç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 ^^


    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 ;) 
  • adanorm2000 , 22 novembre 2012 15:59
    C'est possible, j'ai jamais forcé mes types ^^
    Par contre le timestamp 32 bits t'es d'accord qui est sur 4 octets ? ça doit être une convention indéboulonnable ça.
  • jcproperty , 22 novembre 2012 16:20
    Waterfox ou Palemoon... pour l'instant pas de souci, et c'est plus rapide (surtout PaleMoon)
  • gedd , 22 novembre 2012 17:43
    64 bits signifie ... avec des pointeurs sur ... 64 bits, la taille des données n'a rien a voir (ou si peu).
    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....
  • inkizitor , 22 novembre 2012 18:15
    Enfin le 64bits s'est largement démocratisé tout de même... Que ce soit les jeux vidéos récents ou les applications pro, un ordinateur avec 4go de ram ne fais plus grand chose... Concrètement sur un mac comme sur un pc, rien que l'os prend 2go de ram à lui tout seul. Alors à moins de ne faire que du web et de la bureautique on peut s'en contenter mais heureusement on trouve du 64bits partout pour exploiter nos belles machines pleines de ram ^^ Reste que les tablettes sont en train de remplacer les ordinateurs fixes pour les futilités du quotidien.
  • magellan , 22 novembre 2012 18:32
    Citation :
    Enfin le 64bits s'est largement démocratisé tout de même... Que ce soit les jeux vidéos récents ou les applications pro, un ordinateur avec 4go de ram ne fais plus grand chose... Concrètement sur un mac comme sur un pc, rien que l'os prend 2go de ram à lui tout seul. Alors à moins de ne faire que du web et de la bureautique on peut s'en contenter mais heureusement on trouve du 64bits partout pour exploiter nos belles machines pleines de ram ^^ Reste que les tablettes sont en train de remplacer les ordinateurs fixes pour les futilités du quotidien.


    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.
Afficher plus de commentaires